Although they did not cave on the Ternary Operator. About which a certain contingent (myself included) is vocally unhappy.
Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready.
https://wiki.mozilla.org/Oxidation
they are continuing the work to replace the least performant/secure components in Rust when it's easily possible to switch them out
Code written for Rust 1.0 will most probably still work perfectly fine today.
Language safe-guarding, maybe.
Imagine having your production code hostage to your relationship with the language authors...
Go leadership makes me feel like the language is safe and reliable.
The Elm leadership, as described by OP, just triggers my "its a sect" alarm
Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :)
It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.
It looks like an open source project. I don't get your point.
I mean in normal communities it's OK to fork to experiment/support your use case but still participate in the mainstream community.
There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers.
There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden.
Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.
Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc.
And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”
Can you put your finger on each of those and why you think they exist? The only one that makes sense to me is the last one if that means, that people can use hacks and use private apis they were never supposed to use?
Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything.
However, the leadership style is also what keeps me from recommending Elm to anyone wanting to create a project that cannot be simply rewritten in case Elm does a change that doesn't work for you. I wouldn't use Elm at work, since it would be a very high-risk situation. (In fact, I was faced with that decision and decided against Elm.) If you face a blocker, you're screwed.
A version of Elm that is being developed in the open, where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits? Yep, I would love such a thing, and I'd happily contribute.
Until that happens, I'll happily use Elm for small, personal low-risk projects. I do hope that the situation will improve once the "big rewrite" with a WASM backend is done.