What a great little machine.

Would be great if this could finally put the nail into Windows. It's about time.

I disagree. I'd like to see Windows reduce in market share, but still remain a strong competitor to macOS and Linux.

There's a lot of cross pollination of ideas that comes from OS diversity and a greater resilience to cybersecurity threats, as it is unlikely for any one vulnerability to affect 3 different operating systems at the same time.

People using Windows generally are not actively choosing between windows and macos, it’s assigned to them or they have software that only runs on windows.

I'm only familiar with Angular so far, but looking for a more enjoyable framework for personal projects. I'm having a hard time deciding between Vue and Svelte. Vue seems to be better supported by component vendors (PrimeVue, DevExtreme), but Svelte looks better from a framework perspective itself.

As someone who struggles with a terrible Java codebase and contemplates switching - what are F#s drawbacks?

Mostly the sames as the pros. It's primarily a functional language which dramatically cuts down on the number of folks willing to use it. Those that do adopt it have to learn new ways to accomplish things in new ways. Since the community is so much smaller, the support and libraries also suffer. Since the community support isn't there, the tooling also doesn't get nearly as much attention as what folks are used to from C# and Java especially. It's also quite difficult to hire developers for which means it rarely sees adoption for general use.

I'm currently a Java developer working on a large code base. This is where Java's object oriented nature really shows its weaknesses. Reading other people's code becomes a huge pain, since everything is mutable and you can never be sure what state your program is in after a function call. Even C++ is better in that regard, at least you can pass values by copy or const reference. Gleam looks really nice at first glance. The problem of course is, as long as there is no industry support, it doesn't make sense to invest into it. It may be ok for small side projects, but I wouldn't dare starting a major application in something like that. Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.

> everything is mutable

That’s the real problem, not OOP. There is a functional-ish OOP style where most objects are immutable. Classes are used to capture invariants (in the sense of https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), or for local-only mutations (like building a collection in a local scope, which is passed on as immutable after building).

The defining characteristics of OOP are encapsulation and subtyping, not mutability.

And Java doesn’t properly support immutability :(

Encapsulation is a whole other issue, to which the ‘solution’ is almost always more encapsulation. The nice thing about immutability is that it is not really compatible with how we do encapsulation, so if you are strict about immutability then you are suddenly free from the whole quagmire as a side-effect.

I disagree on both accounts. It’s not difficult to code truly immutable classes in Java. And encapsulation is beneficial regardless of mutability.

There's a difference between something being possible vs supported. In C/C++ you can have a type, and a const version of that type. In Java you can't define a class and automatically be able make a reference to a const object of that class. You can make a final reference, but that only means you're always referencing the same (mutable) object. You could you use final fields for the entire object, but then you have to make another type for the mutable kind, or builders to go from one to an other. Another example is Unmodifiable collections, which are only views on modifiable ones, so you can't be sure it's not modified. A language that supported immutability would come with some of these batteries included.

There are places to use encapsulation with mutability, such as simulations, but having hidden mutable states is not desirable property when constructing rapidly changing applications.

I do my best to keep things sane when working with a Java or Ruby or what have you codebase, but I don't pretend it's something it's not. Just do the best that the codebase and organization can tolerate.

Right, you can’t turn a mutable object into an immutable object when other references to the mutable interface already exists. Const as in C/C++ is certainly a useful feature that Java lacks, but it’s quite a leap from that to claiming that Java doesn’t support true immutability. I develop Java applications with immutability as the default, and it works quite well. The lack of the abive-mentioned feature is not a critical obstacle.

Regarding your point about collection views, const references are often also just views on mutable objects, and this poses no particular difficulty. And you can implement truly immutable collections in Java if you really insist on it.

It’s difficult in the sense that somebody consuming your class will sooner or later start relying on reflection to do something with it they shouldn’t (because they can), and then when you make a change in the future it will cause breakage downstream. Records solved this for some cases at least.

More important imo is that the standard collection classes can’t even be set to immutable with the final keyword. Sure you can use something else, but professionally you are going to have to deal with them most of the time still.

Yeah they seem to be trying to force the conversation into encapsulation == mutability when that flatly is just not true. There are tons of immutable objects that benefit from encapsulation and there is plenty of internal immutable state that you would want to encapsulate and not just give out.

OOP is encapsulation, inheritance, and polymorphism. Polymorphism maps to behaviour which is type-based, but usually also based on the objects internal/mutable state. This is no surprise since OOP came out of Simula for doing simulations.

Referring to my GP comment, subtyping subsumes inheritance and polymorphism. It is orthogonal to mutability. As an illustrative example, the Java Collection Framework makes significant use of inheritance and polymorphism, but could as well be reduced to immutable collections.

I really disagree. You don’t need polymorphism or inheritance. The core of OOP is objects and encapsulation. Putting behaviour next to the data. It has nothing to do with mutability.

Regarding your first point, OOP without subtyping has typically been referred to as object-based rather than object-oriented.

Sure, I just think that’s being pedantic.

I think it’s an important distinction, in particular since a significant number of people opine that subtyping is harmful, but encapsulation is not.

I don’t particularly think subtyping is harmful. It can be misused, but everything in programming can be misused.

> Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.

I agree that it's always a little risky to bet on a young language. But I think Gleam is doing a good job of positioning itself as a smaller risk by sitting on the tried-and-true BEAM virtual machine and Javascript runtimes. If worst comes to worst you could export your compiled Gleam as Erlang or JS and it's quite readable.

And Gleam's FFI with Erlang, Elixir and Javascript is pretty good. I don't think it will take long for a wide variety of packages from those platforms to become available on the Gleam package manager. Doing your own FFI is hardly intimidating - it's essentially just writing type definitions for the functions you need.

Another factor giving me hope is that the language appears to be mostly 'done'. The author has carefully considered a minimal feature set and appears to be sticking to it, making it one of the simplest (typed) languages I've ever used syntax-wise. I think this bodes well for future growth, stability and maintainability.

When writing aviation software, there is a process you need to follow, DO-178C. So even if you produce bugs, they should be caught in later stages.

Everything needs to go through a risk assessment phase.

The fact that they were determining that one AOA sensor would be enough for such a critical system is what needs to be examined.

And people involved with this decision need to be put into jail.

I think there are lots of us having the same questions. I'm at a point in my life where I just can't stand it anymore (after 25 years). I'm thinking about doing something completely different for a while, even if it pays a whole lot less, hoping that this somehow rekindles the fire for software development...

But you also need the GUI part. Flutter seems to be the main competitor here. What's the current situation with Kotlin? Is there a decent Compose for Web yet?

With browser dom support and CSS, that would be doable. Compose web is in alpha currently; it renders to a canvas.

Well, I guess now it's a good time for developers to come up with their own ideas instead of working on somebody else's.

There is no reason to panic.

In my opinion, that is due to Qt being such a complete and well documented framework.

After a separation from my long term girlfriend, I started playing Tennis. I love it. Spent a few bucks on a coach. Best decision ever. If you are not self disciplined enough, get someone who motivates you.