This is exactly what OSS is all about. Take a code base and develop it into different directions. Both code and organization. And "natural selection" will have some forks die and others strife.
I'm all for the diversity that emerges when you have different libraries and tools that take on the flavor of each group that builds them. But at least establish a common language in which to build that diverse ecosystem.
It's easy when a project is new to adopt one variant and be happy in your little variant bubble, but when that project turns out to live for a while and inevitably has to start working with other projects or tools that rely on one of the other variants - you've got a headache, and life gets hard (and you'll probably start wishing people had just standardized things in the first place!)
There’s a fresh new level of hell I hope I don’t get sent to for my sins when my time is up.
For those too young to remember Fortran: Markdown is just as bad. HN supports an extremely limited subset, Reddit another, Stackoverflow, Github and Gitlab each have their own flavors as well, and MediaWiki also has elements that IIRC came from Markdown. And that's just the biggest platforms and doesn't count the myriad of libraries and bindings with their unique subset/superset and edge cases.
That is, the latter needs to balance the needs of a much, much wider array of customers (all rust compiler users) versus the former with a more specific target user base.
This introduces different requirements. Changes are far, far more likely to be permanent for example. Which means that the discussion around decisions needs to be different.
A thing does not need to be enterprise level to be useful or even very useful.
Heard it all a thousand times already.
I would argue the requirement is that each compiler is a stable project. But one language can have multiple compilers that aren't 100% compatible and implement slightly different subsets of the language (as long as there's a common subset libraries can choose to stick to)
Hopefully not for long:
https://github.com/ferrocene/specification
https://ferrous-systems.com/blog/the-ferrocene-language-spec...
Hopefully Ferrocene can lead to Rust itself being standardized.
To me, it seems inevitable that there will be multiple implementations of Rust, especially if Rust continues to be more widely adopted and used in new domains.
I would also not be surprised if Rust were to adopt optional language extensions for specialized use cases, similar to Ada's language annexes:
http://www.ada-auth.org/standards/22rm/html/RM-1-1-2.html
Why? Because the Rust implementation you use for video game programming does not need all of the same features as the Rust implementation that you use for safety-critical embedded systems (for example: railroad control software).
It is not a specification that standardizes rust or prescribes any behavior to the compiler. It's a specification that describes certain aspects of the behavior of the existing rust compiler. It's neither comprehensive nor is intended to be. It follows the changes in the compiler. If there's a mismatch between compiler behavior or the spec, the spec is considered faulty. It is also not sufficient to write a new compiler based on the spec.
As such, Ferrocene is not an effort to standardize rust. We consider the Ferrocene project a certified downstream of the rust project. Any push to standardize rust would need to come from the rust project itself. We have not intention to create any such standard.
That said, there is some interest in building a specification for the rust language in the project itself - here's the relevant RFC https://github.com/rust-lang/rfcs/pull/3355
(1) I am one of the managing directors of Ferrous
OSS is all about forking.
My company works with a very very niche TypeScript fork as well. Everyone should be free to work and contribute in the way he prefers for whatever reasons.
Besides, a number of forks have had a positive effect on the original project: Emacs, GCC, GNU libc, Vim, probably more.
GCC had a standard to live up to (and it extended that standard in plenty of ways), the others aren't languages per se and do not and never did have the mission to appeal to the people that write non-sexy system software for a living. They value stability and a lack of drama in the suppliers of their tools above all else because any kind of fragmentation has the potential to cause them to have to (much) more work and they usually already have plenty of that.
Which, to me, makes it seem that "hey, don't fork the community" is kinda brutally missing the point at hand, or at least feels aimed in the wrong direction.
Competition if anything breeds more innovation.
I wish someone came up, e.g., with an Elm fork.
All this drama and the fork likely seem extremely important to the parties involved but everyone else just wishes they would get along.
As a working dev I want one Rust.
...You know?
I think it's an important aspect of free software that it can be forked. That doesn't me we need to celebrate all forks. Some are great. Some cause more harm than good. But most are simply irrelevant. This one appears to be in that last category.
Who told you that? Weird choice of words.
In 99% of cases having one project however bad it is, means less confusion and more stability than several (It's funny and scary how this is exactly the one and only argument for dictatorship).
For the good of the project long term, evolution through selection might be best. But it's certainly not best for the short to medium term if talent is split, and it's not great for users to have to wonder which fork to use.
That slogan was used in the summer of 1957 when the Chinese intelligentsia were invited to criticise the political system then obtaining in Communist China.
The full quotation, taken from a speech of Mao's in Peking in February 1957, is:
"Letting a hundred flowers blossom and a hundred schools of thought contend is the policy for promoting progress in the arts and the sciences and a flourishing socialist culture in our land."
- It was a trap
- Mao didn't expect serious criticism, was surprised, and lashed out
It has inspired other posts, for example (2)
As a hobby Lisper I learned about Peter Seibel as the author of Practical Common Lisp.
(1) https://gigamonkeys.com/flowers/ (2) https://medium.com/@danonrockstar/let-a-thousand-flowers-blo...
I believe they’re hugely responsible for most of the adoption of Rust and have no doubt they’d see continued success anywhere they choose.
But they quite dislike this fork, don’t they?
Based on Ashley’s comments, I think the HN community has really overreacted to this story and treated it as something much bigger than it is. Im not sure there’s anyone at all notable involved with the “crab” fork.
I haven’t looked into it much though, someone may correct me. Overall though, I’m not sure this is worthy of our attention.
HN teapot tempest = something Official Folks better heed, or pay the price for... problem is, this strike is damaging the company, and management thinks it's no big deal...