> Open source is all about collaboration and this code redundancy is a historic accident.
I totally, 100% disagree. Software monocultures are extremely harmful: implementation bugs get baked in as standard features, innovation stagnate without competition and single providers get oversized power. The best case-study here is when Internet Explorer was dominant: you think that was good for the web? Software is like everything else: diversity and having a large "gene pool" is incredibly healthy.
> Would rust or go benefit from totally redundant implementations?
Of course they would, that would be awesome! Look at Python, it's been very good for the language to have a large variety of backends (Jython, PyPy, IronPython, etc.) in addition to the standard distribution. Of course none of them are as popular, but the fact that they exist is a sign of a healthy language.
I wouldn't even pick Python, but the JVM, where there are multiple very successful options and several businesses built on top of "totally redundant implementations."
Actually GraalVM isn't that recent, its history goes back to MaximeVM, initially released in 2005, so GraalVM has 15 years of research work put into it.
J9 is used a lot with IBM customers (banks + other finance on WebSphere aka Websfear). I'm not going to defend Java here, but Java/JVM might very well be the last flagship of a huge language + API + testsuite with multiple interworking implementations. If you don't like that, then there will be only proprietary single-vendor languages going forward.
> Now take half rustc devs and move them to another redundant compiler implementation. You've slowed down progress far too much, criminally even I would say.
This assumes most of development time is spent writing the actual code.
The counter argument is, that most of the time spent on such advanced projects is figuring out which path to take. Perhaps writing four or five different implementing of weighting the discovered pros and cons.
Having multiple javascript engines arguably allows exploring the design space much more efficiently than having all devs working on the same codebase.
> This assumes most of development time is spent writing the actual code.
The counter argument is, that most of the time spent on such advanced projects is figuring out which path to take.
is a great wording of the problem. Added to my favorite comments.
> nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it.
But writing a design document may not be enough to determine if it's a good idea. Sometimes you need to try something to find out.
I think you're missing my point. If you have multiple implementations, you can be trying out implementations of different paths concurrently. If you only have one implementation, that's very hard to do.
I'm not saying that's what will happen, just that the point about multiple paths works better with different teams on different code bases.
. If you have multiple implementations, you can be trying out implementations of different paths concurrently. and so can you with git branches.
The difference is that with multiple implementations, the team will most of the time not be aware of what is tried by the team from the other implementation (and conversely) leading to an inefficient overlap of what has been tried on the design space as I explained in another comment.
If both teams worked on the same project, through the same documentation and communication channel, they would-be far more aware of what has been tried and I don't see the issue with git branches.
Different git branches don't allow the features to be vetted by users. At least not by many users. It's going to be much harder to get users to use different builds of Chrome than it is to have different (or even the same) people using Chrome and Firefox.
Also, what management team is going to ask their developers to work on two conflicting features in parallel? It's a people matter as much as it is a technical one.
FWIW, Rustc not having multiple implementations is exactly the reason why I'm not looking into it for serious projects (1). OTOH, JavaScript being ubiquitous is the reason I can spend time on projects with a certain depth and commitment (though JavaScript ES6+ isn't nearly as ubiquitous as it was until ES5, with only two major implementations left), knowing that a multi-year development effort isn't torpedoed by language churn.
1) and I personally don't believe in a "one language to rule them all" behemoth but rather in small, focused languages and tools in a polyglot/Unix fashion
The multiple implementation story of Rust isn't as great as some older languages, but it's getting there.
There are at least two e2e implementations of Rust:
- rustc, the reference implementation.
- mrustc, an alternative written in C++ [1].
There are also multiple implementations Rust's IR (MIR):
- rustc compiles MIR to LLVM.
- A backend that compiles MIR to Cranelift [2].
- Miri, a MIR interpreter used for dynamic analysis [3].
mrustc doesn't perform the borrow check, so it can't prevent you from triggering UB like rustc. But you can use rustc for the borrow check and mrustc for codegen.
Could you explain what benefits the existence of an additional implementation would give a user? I use rustc. Now whether mrustc exists or not, how does it affect me? FWIW, mrustc does exist, so I'm wondering in what way I've benefited.
> language churn
Rust is stable. If there are breaking changes, they are explicitly opt-in. If you're concerned about future changes, you could go ahead and use a specific version of the compiler for years.
I believe Rust is fine, but it's not stable in relation to "multi-year development effort" (as in, didn't even exist), and has had inevitable churn during its forming years. Thing is, a programming language is a means to an end; choosing Rust you're tied to its success and need to take decisions early on in your project (for example, wrt target platforms) when that's something you'd rather postpone until you absolutely have to, which you can do with C and C++. Plus, I've seen languages that tried to be too clever which not only results in you fighting the compiler but also potentially causing generational churn. Like, a fresh generation of developers might hate having to deal with your super-intensive language, wanting to do its own thing instead. Basically, using <rustc-or-whatever-lang> might just suck in another way.
> Like, a fresh generation of developers might hate having to deal with your super-intensive language, wanting to do its own thing instead.
I suspect it's more likely that a fresh generation of developers will hate having to deal with C++! It's all very well if you have 10 years of experience, and you're used to it's quirks. But it's a lot to learn if you're new to it. Rust is significantly easier.
Forget Rust, the language. What's the blocker in using rustc 1.44 for your "multi-year development effort"? It's a binary on your hard drive, it won't change. Similar with any library you're depending on. The specific versions you're depending on will be available in perpetuity.
There's a very good argument for separate teams working on the same problem being able to produce novel solutions that bundling everyone together in one team wouldn't produce. Too many cooks comes to mind.
Humanity would also be way more efficient if we all lived in identical houses, wore identical clothes, ate identical meals, and worked identical jobs. Look at all the redundant work we do with different industries, restaurants, clothing, architecture, families, and identities!
Unfortunately, I don't think the bugfix is scheduled to land until Singularity 1.0.0 RC 1.
Mostly the same. An accident for a licensing philosophy difference.
Wow LLVM brought modularity but I bet that if 5% of the human resources that got into llvm got into modularising GCC the issue would have been fixed.
GCC nowadays is getting modular.
After all this years GCC is still faster on average and llvm is getting slower after each release or at best do not progress.
I'm fairly certain a good chunk of gcc improvements wouldn't have happened without clang existing and showing that it can be done better and that people care.
Yeah, this is an attitude I come across at work a lot. A lot of pointless work is justified as "unifying" several projects. Of course, a nod to the xkcd on Standards [1].
This is why we end up with monocultures (eg in agriculture), which all works great... until it doesn't (RIP Cavendish; say hello to Gros Michel).
Even in a large organization multiple projects that ostensibly do the same thing can be good. They can have different strengths and weaknesses and work from different design decisions and philosophies. Then the "market" (often the rest of the company) can decide which to use. This often produces much better results than simply anointing a winner.
Anointing winners rewards politics rather than the technical.
Of course this can go too far but so can anything. There can be too many competing products. That tends to highlight a problem with your organization's incentives structure (eg heaping rewards on new projects rather than maintaining things). Competition can also be toxic.
You may think it's a waste to have both clang and gcc. I couldn't disagree more. I think the existence of clang has inarguably made gcc better. Would gcc have gotten more modular in the absence of clang? Maybe... but maybe not.
I'll leave you with this quote:
"A foolish consistency is the hobgoblin of simple minds."
There is far more web content than there are native computer programs. Making that content renderer agnostic will become harder the more entrenched the Blink monopoly becomes and websites start relying on blink specific bugs. One day even blink devs themselves can't change their own code any more because it'll break the content out there otherwise.
> One day even blink devs themselves can't change their own code any more because it'll break the content out there otherwise
One day? That's already a problem. There are cases where Blink's behavior is clearly incorrect, but there is great resistance to fixing it, because there's existing content that (accidentally) depends on the broken behavior.
Is it not also a fallacy to fail to fully consider alternative explanations (see: fallacy fallacy, argument by dismissal)? Most engineers are fully comfortable with being corrected in cases of objective fact. What you're doing here is not that, it's instead insisting that any analysis other than your own is mushy-brained nonsense with a near-total lack of social niceties.
Consider the alternative explanation that people don't like the way you're aggressively presenting your ideas and failing to (at least outwardly) seriously consider the ideas of others in kind.
Have you considered that most of the people who point out logical fallacies incorrectly come off as incredibly rude and overbearing and this has nothing to do with Hacker News's "echo chamber"?
You appear to currently be at the level of "rationalist" mindset where you understand some ways in which people's reasoning is not ideal, and you haven't yet understood and accepted that "rationalism is by definition choosing approaches that win", and that being obnoxious tends to lose. Don't deliberately choose approaches that lose. (That's quite separate from things like "there is value in defaulting to treating people decently".)
You can point out a problem or fallacy without reveling in abrasiveness. Consider how good the brain is at pattern matching, what patterns people will match your comments to, and how you could more successfully convince others compared to your current strategy. Before assuming that you're just better than everyone downvoting you, carefully consider the accuracy of your priors, and the biases that make people generally tend to give more weight to their own beliefs. Consider how rarely people actually change their minds; seriously consider what it would take to convince you that a different approach would be more successful. Consider what failure modes you could fall into if you assume that you couldn't possibly be wrong in your approach to interaction with others. Consider whether, in the course of making rationality a sacred value (not by any means a bad thing), you have also come to treat "disregarding feelings and empathy" as a sacred value, rather than valuing empathy as a critical input.
If you want the world to be more rational, you are not only not convincing people, you are actively harming that cause through the example you're setting; you're giving people associations and exemplars for "rationalist" that will make people want nothing to do with it. If you think that people shouldn't care about feelings and should be pleased to get your feedback, then 1) you're committing the is-ought fallacy by not recognizing how the world actually works and acting accordingly, and 2) you should question your "ought", and what a world where people don't value empathy looks like.
(Lest this be misinterpreted: Choosing to value empathy does not mean choosing not to value truth, or to value it less.)
I've been where you seem to be. I've lived the is-ought fallacy, on multiple topics. It took me a long time (and various helpful writings) to learn to question some of my assumptions and hypotheses, test them, and improve my worldview. (One of the first ones I took a while to learn was "yes, how you dress matters, people will judge you accordingly, stop resenting it, accept it and use it to your advantage".)
I think as technologists we generally vastly underestimate squishy problems like jealousy, pride, leadership, organization, collaboration, and psychological safety.
I see your argument as akin to "communism would work if..." Or "command economy is more efficient when...". But human nature matters, and humans prefer to pick tribes, rebel against the status quo, etc. You need to fix that problem (hell you'll need to convince people it is a problem) before you can even dream of fixing this particular issue in software development.
