yogthos

gonna have to smuggle them through Mexico 🤣

:)

Actually, they acknowledge in the first instance that the carrier was being attacked and was taking evasive maneuvers that caused the jet to become loose. The second one doesn't mention it explicitly. However, here's another article talking about casualties on the 7th https://theintercept.com/2025/05/07/navy-jet-truman-red-sea-yemen-houthis/

Trump made the announcement on Tuesday, and the second F18 was lost on Wednesday https://abcnews.go.com/International/2nd-navy-fighter-jet-truman-aircraft-carrier-lost/story?id=121542299

They built their own HarmonyOS which was originally based on Android but now its become its own thing and no longer compatible with Android.

https://consumer.huawei.com/en/harmonyos/

the core of it is open source https://www.openharmony.cn/mainPlay

What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.

Of course they do, it's silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I've used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.

Meanwhile, I'd argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.

My experience is that immutability plays a far bigger role than static typing. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that's by far the best approach towards ensuring correctness that I've seen.

Again, that's my experience working with many different languages for over two decades now. I'm not suggesting other people can't have their own preferences.

That's not what I'm saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.

I agree, the language alone isn't a silver bullet. I'm not suggesting that it is. You still have to implement good workflow, do testing, code reviews, architecture design, and so on. All these things are language agnostic. What the language can do is reduce friction in your workflow, and nudge design in the right direction by making it easier to do the right thing. I largely see it as a quality of life improvement.

Also, I'm not saying that patterns like adapters don't have their uses or that you might not use a similar approach in a functional language. My point was that these types of patterns tend to be more pervasive in mainstream languages.

Static typing itself is a trade off as well. It introduces mental overhead because you are restricted to a set of statements that can be expressed using a particular type system, and this can lead to code that's written for the benefit of the type checker rather than a human reading it. Everything is a trade off in practice.

Finally, the choice of language ultimately depends on a particular team. Different people think in different ways, and have different experience. The best language is the one that majority of the team is comfortable using. Hence, I'm speaking here from my personal perspective of the way I enjoy doing development. This will necessarily vary from person to person.

It's the American way.

He's making it up, and there have already been more attacks since he made the announcement.

This is absolutely true, however I don’t particularly value this feature because most engineers typically already cannot separate concerns very well in industry so IMO if I had this I would not want people to use it. Very much a “it works ship it” trap.

That's been the opposite of my experience using Clojure professionally. You're actually far more likely to refactor and clean things up when you have a fast feedback loop. Once you've figured out a solution, it's very easy to break things up, and refactor, then just run the code again and make sure it still works. The more barriers you have there the more likely you are to just leave the code as is once you get it working.

This is where you lose me, you still have wrappers and adapters, they’re just not classes.

A good explanation of the problem here https://www.youtube.com/watch?v=aSEQfqNYNAc

When you're dealing with types or classes they exist within the context they're defined in. Whenever you go from one context to another, you have to effectively copy the data to a new container to use it. With Clojure, you have a single set of common data structures that are used throughout the language. Any data you get from a library or a component in an application can be used directly without any additional ceremony.

Yeah you can definitely have this kind of stuff in other languages.

It's not even remotely comparable. Outside Lisps, I have not seen any environment where you can start up your app, connect the editor to it, and then develop new code in the context of a running application. I also find that language design very much impacts conventions and architecture. Clojure's focus on immutability naturally leads to code that's largely referentially transparent and where you can reason about parts of the application in isolation without having to consider side effects and global state. Meanwhile, focus on plain data avoids a lot of the complexity you see in OOP languages. Each object is basically a state machine with an ad hoc API on top of it. You end up having to deal with graph of these opaque stateful entities, which is incredibly difficult to reason about. On the other hand, data is inert and transparent. When you pass data around, you can always simply look at the input/output data and know what the function is doing. Transforming data also becomes trivial since you just use the same functions regardless of what data structure you're operating on, this avoids many patterns like wrappers and adapters that you see in OO style. My experience with Clojure is that its semantics naturally lead to lean systems that are expressed in terms of data transformation pipelines.

Again, this is my personal experience. Obviously, plenty of people are working with mainstream languages and they're fine with that. Personally, I just couldn't go back to that now.