So yes, I am also skeptical. I think these companies are more intoncartelizing and colluding via propaganda than delivering stuff. They do deliver some, but very far from their promises.

These companies dangerously mimic behaviors I usually attribute to politicians.

Ss for AI slop. There is lots, but I do not think Linus will tolerate a heavy quality degradation and policies will be set up to strike a good balance.

Every day I want to keep tech more fenced and far from me and only use it for what I need.

Indeed I got it wrong bc I translated from spanish and it seems to be a false friend. The word I meant is "malleable".

This is a strong reason, but then why in other areas they consider it over C++ for greenfield but it hardly happens in games?

Compared to what? I see ASP.NET Core and Quarkus very competitive. The virtual threads in Java are great, paired with structured concurrency IMHO.

If I have to go microservice or API, I would choose FastAPI for fastest delivery and if I have to rewrite, Go, unless it is massive scale and scaling horizontally becomes a headache I would not consider Rust/C++ for this.

All the backend, etc. for the company I have been working for is C++ for the fast parts but all tools around are Python (with NiceGUI and Flask mostly).

I think the combination is quite powerful, btw.

If you have to iterate a lot the shape of your code... no, it is not any good at this...

> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.

Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...

Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.

Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.

I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).

Rust is absolute performance, similar to C++. Go is deliver fast and get a very good performance to effort ratio.

Because of coding agents? :D

I see it more as a piece of software being feasible to be maintained over time: if it is only me, it is more likely to end up dying soon, if it attracts adoption, it just gets better, more battle-tested, etc. independently of the economic factor.

Related: how do you think you can attract more people, by setting a restrictive copyleft that some people will use in their spare time or by attracting even corporations with money that will end up committing to a repo that is used in half of the world?

Note that I am talking about adoption bc thanks to adoption things just do not get rotten. If you make a piece of software and set a license that noone wants to touch, you will see it stall and die in front of your face.

Do not take me wrong, I mean, I think it is fair to contribute back, collaborating, sponsoring and so on. But it is a fact of life that if you make certain choices you make adoption more difficult with all the consequences it entails.

I do know what the original spirit of such licenses is. I was talking about real side-effects these choices have.

This is two-sided: making a kind of license mandatory also shrinks adoption if it is more restrictive. So, even if I acknowledge there is truth in your side of the story, there is also another at the other side, as usual.

How many people use GPL-licensed software as opposed to MIT licensed?