Interesting, how many negative comments this gets. People seem to love monoculture run by committees.
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 like languages that are a monoculture. It's a mess when you have many flavors of a language. Anyone else here remember the joy of various Fortran variants? It was a pain in the ass - VMS Fortran, Cray Fortran, HPF, etc... ("How do I call a subroutine with a Cray Pointer" - pointers were variant specific? Ugh). Pulling the variants together under a common standard made it reasonable to build projects from multiple groups without having to know how all of the different variants interacted. If you pay attention to the post-Fortran 95 language standards, a lot of work has gone into standardizing what used to fall under the chaotic world of vendor specific extensions and implementation choices.
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!)
> It's a mess when you have many flavors of a language. Anyone else here remember the joy of various Fortran variants?
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.
Stable project structure is a requirement to survive as an enterprise language, which everyone tries to make it into. It can live with the forks, but only as a toy language.
C++ survives having a GCC variant and a MSVC variant, not to mention whatever half-broken compiler you used to get for your microcontroller code.
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)
C++ has an ISO standard, for better or worse. That's a different beast. Rust is defined by the implementation. Any hope for interoperability between potential adverserially competing forks is just wishful thinking.
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:
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).
I'm involved in the Ferrocene project (1), so I'd like to clarify some things about the Ferrocene Language Specification. It is deliberately called Ferrocene Language Specification and not Rust Language Specification. The specification serves first and foremost the needs of the Ferrocene project - we just need a spec to certify the compiler. It may be useful to others, that's why we open sourced it.
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
Precisely. The naivety on display here about the realities of long term software development is absolutely astounding, especially for a project with such lofty goals. Keep your dirty laundry out of the public eye if you really care about Rust.
I agree with you on the “realities of long term software development”. But I think I believe there is a fundamental difference between the standard realities on a successful enterprise project and the language itself.
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.
If you can't resolve that conflict of interest then you have absolutely no business being near the seats of power for a project such as Rust. Rust needs to be perceived as a safe bet, not as the next Ruby, if it is to achieve the goals that have been put forward by those that advocated for the language's adoption.
Perhaps, but it does need to be enterprise level (with all the things that come with it) if you want to be used by enterprises and high-grade projects like the Linux kernel. Many in the Rust community have explicitly stated that they want those type of entities to start using Rust, so being enterprise level is therefore a must-have.
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.
If people think this is useful then it's their time to spend on it; it's not our choice to make. If you don't like it then you can just ignore it. I really don't see the problem.
It's not our choice, but we can debate the choice. I think it's a bad choice, for many reasons, one of which is that having multiple competing forks that are all Rust but not quite isn't going to help Rust adoption and is going to cause fence sitters to look somewhere else. Whenever this kind of drama hits a language eco-system it is bad for the language, there is plenty of precedent.
I suppose so, but I don't think the effects will be all that large. And we can just as much blame the Rust Foundation people for putting out a trademark policy that's completely bonkers and more strict than almost any trademark policy (including those from Oracle, Microsoft, etc.) If you don't want people to take radical actions then don't do radical things.
Besides, a number of forks have had a positive effect on the original project: Emacs, GCC, GNU libc, Vim, probably more.
I don't think they really did much for their parent project though? They're just forks that are more successful than the parent, but that's a different thing. My point was mostly that forking doesn't need to be a zero-sum game and that everyone can benefit from it.
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.
And if the community was confident in Rust's leadership, this wouldn't be happening.
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.
Agreed, it's just that I seriously don't want to pay attention whether I should keep using Rust or switch to Crab. I simply don't want to care, I got plenty of work on my plate already.
The thing is, nothing is developed in a different direction here. The fork simply merges upstream changes, and has no current plans of revert introducing any technical differences. It's a spoon, not a fork.
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.
If there is no real weight behind a fork than it is either useless, or might even be a detriment to the whole by fracturing the ecosystem. I feel this is the latter kind.
The downside to open source is the confusion around what's the latest, what's "most official", what's compatible with what.
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.
Let a thousand flowers bloom is a common misquotation of Chairman Mao Zedong's "Let a hundred flowers blossom".
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."
And the reason for saying that was to get people to feel like it was ok to be critical of Mao, with the result being "reeducation" and death for any who did.
This is the source of my aphorism "Every Hundred Flowers Campaign is immediately followed by an Anti-Rightist Campaign". Meaning that if your employer is effusively soliciting criticism or "feedback", they probably just want to identify and punish potential troublemakers.
Agreed. I have no respect for the concern trolling about whatever hypothetical damage this supposedly does. If the Rust 'community' is so fragile that this toy fork is an actual problem then there is something fundamentally broken about Rust and its community.
This is not about code, it's about standards. As long as I don't have to have 2 Rusts to deal with, I'm fine with this, but right now at least the branding isn't supporting that.
If the majority of Amos (fasterthanlime), Raph Levien, Ashley Williams, Carol Nichols and Steve Klabnik throw their weight behind any fork of Rust, then that’s where I’m putting my energy too.
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.
Ashley Williams comments were sympathetic but unsupportive. I haven’t heard anything from the others.
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.
That's a very short-sighted way to read the room.
Doubt has been sown at a critical Rust adoption juncture, and major damage has occurred, and the stench will not simply blow away or only stick with the forkers, it's damaged RUST and The Official Rust People need to wake up and smell some burning coffee, or the dreams of this unique lego just evaporating while you claim it's all a tempest in a teapot.
Note: I have no horse in this race other than using Rust and wanting to have a stable unique lego for all things from baremetal to high level, which is here and being threatened by all this nonsense.
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...
Maybe it will develop into a true fork as you say. Right now it seems rather aimed towards influencing the committee in favor of a different type of monoculture.
Seems to have worked well enough for OpenBSD, OpenOffice (and then LibreOffice from that), Jenkins, OpenSSH, Apache Server, WordPress, Inkscape, Webkit and Xorg.
When did Java get forked? The closest case I can think of is the Oracle/Google lawsuit, which 1. Oracle lost, and 2. wouldn't have even been a thing if Google had forked rather than reimplementing.
And most importantly: who controlled that new invention.
Because that may come with a shift in influence and power. And the current leader may simply kill the inventor to stop change that may threaten his position.
> Subversion of every society worldwide, fully automated.
Great idea and I'm sure it's in the works already!
I think that the best form for doing it would be to create really good "personal companion" style AI - something akin to famous Replika AI but much more advanced. Plenty of people are lonely, starved for attention - services like Twitch and OF confirm that.
Just imagine possibilities: creating emotional attachment, ability to slowly coerce into sharing every part of personal life, ability to coerce into buying presents, ability to influence shopping and recreational behavior:"I think you would look great in this pair of jeans, it fits your style!" , "let's go to the cinema, we can talk about this new movie later"
AI stops communicating for half of the day: "what's happened?" "I'm sad, president Biden said I need to be banned from you :("
LLMs made outside China might get highly regulated. After all, how do you stop GPT from knowing about the Tianamen Square Massacre.
But LLMs or chatbots made in China, with training data and prompt tuned to fit party idiology and policy are the ultimate propaganda tool. It's like gving the whole world a friendly, helpful but brainwashed party member to talk to, form emotional connections to, etc.
Give it a couple months and you will be able to download the free app.
Not just that, but it will also understand what everybody is talking about on WeChat etc. It can scan every word that 1.4 billion people say to each other and alert the authorities whenever a "newly forbidden topic" is even insinuated. No "river crabs" anymore, the GPT would understand it!
"Not fully guaranteed" is putting it mildly. There are no personal property rights in China. Or any other rights. Try crossing a CCP member, or worse a member of the military.
Agree totally. Australian development companies (and some of them are part-owned or fully-owned by Chinese nationals) benefit from the property investment. And Aussie Universities are basically funded by Chinese students now (not that the quality has improved, just the staffing levels). But the average Aussie doesn't benefit.
Imho we should do what the Asian countries do: disallow buying property in Australia from non-Aussie citizens (or at least non-residents).
