I never heard of another rust compiler other than the official from rust-lang.org, but I am just a newbie.
Is there another toolkit?
2 Likes
The only other implementation I know of is mrustc.
I think the big thing stopping alternate implementations is having some sort of ISO standard that other implementations could check their compilers against. That said, the language is still evolving, with game changers like compile-time function evaluation (const functions) and async/await not even in stable yet. I imagine having multiple implementations or an internationally recognised standard could slow down the language's evolution and hinder productivity.
6 Likes
Thank you, Michael.
People,
Rust advocates want it to be considered as an alternative for well established languages like C, C++, Java, Python, Ruby, etc, but we should understand that all those languages have multiple compilers.
Generally speaking, companies refuses to adopt single supplier solutions.
For a company to bet the future of a product on a new technology it is very important to know that at any time one is able to pick tools from a second supplier if the need arises.
Just to give an example, currently I help to maintain an application composed by half a million lines of C code, accumulated along 35 years. In that time span we changed compilers several times, because it was strictly necessary. We used Lattice C, Aztec C, several versions of Borland C, from Turbo C onwards, and GCC nowadays.
Being tied to a single compiler, Rust poses a unacceptable risk. For the language to be taken as a serious contender for big projects an alternative toolkit is a must.
For starters a language specification document would help.
Thanks
It seems noteworthy to me that you stopped changing compilers upon reaching one that's open source.
Can you elaborate on the nature of the risk? I agree that one vendor would be a risk, but given than rustc can be forked at any point, I don't see the same lockin potential. (Note that this even happened with GCC, see GNU Compiler Collection - Wikipedia)
(Of course, if the underlying sentiment is "Rust isn't mature enough yet for us to be willing to bet on it for something that needs to last another 35 years given that we're unwilling to maintain the toolchain", then I can't disagree with that. Given the usual survivorship estimate, it's completely possible that rust could disappear within another 9 years.)
13 Likes
While single-supplier solutions may be considered a problem for material goods, I find it surprisingly easy to find well-known counter-examples of single-supplier, or quasi-single-supplier software solutions that became very popular among companies.
Consider...
- Java, which you quoted
- Microsoft Windows and C#
- Anything made by Apple
- Adobe Flash, back in the day
Although attempts were made to produce alternative implementations of all of these, for a large fraction of their existence none of them reached anywhere near the degree of maturity where it wouldn't be a complete catastrophe that would likely result in ecosystem extinction if the main software editor went bust. And yet these technologies became popular nonetheless. Some of them still are essentially single-supplier (e.g. Windows) and still enjoy major industry success.
So it seems that when evaluating the future longevity of technologies, companies are not exactly looking for implementation redundancy, but more for something that looks too big to fail. Implementation redundancy is one way to give this impression, but it is not the only one, and not necessarily the best (as it results in enormous effort duplication, behavioral divergences across implementations, and significant inertia against change).
15 Likes
This seems dubious to me. Python and Ruby are not ISO-standardized, yet they have multiple implementations. Most C and C++ implementations arose before standardization, which is actually a large part of why so many parts of the standard are undefined.
5 Likes
I was coming in here to say this. In addition to the fact that many popular languages only have one complete implementation, consider that there is a difference between an alternative compiler that exists and alternative compiler that is a realistic option for production.
What's the realistic production alternative to javac or the HotSpot vm? While (I assume) there are other compilers, which of them are production-ready?
C# - what's the production alternative to Roslyn? Even Mono has adopted Rosyln now.
Swift, Obj-C - Not only are there no production alternatives to Apple's compilers, but there are no supplemental implementations that I am aware of at all.
Go - It's Google or bust.
Actually when I run down the list, I see C, C++, Python, and ECMAScript as outliers that have multiple production compilers.
What's the advantage of having multiple compiler options, anyway? You only get to use one at a time. It seems to me that it's better to have one compiler that works really well than two compilers that both work ok.
6 Likes
Not anymore, GCC also contains a go compiler.
One point is that having multiple implementations really helps to nail down the line between specification and implementation details, and before that can happen, creates more pressure to have a specification in the first place.
1 Like
Scott, we didn't stop exchanging C compilers. We plan to do it again. For example, our application became big enough that GCC is taking too long to compile. We have 9 developers, each one building the software several times a day. Our installation packages imply compiling the same source code again and again, using slight variations to adjust the application for different uses. So, slow builds cost a lot o money to us. For our use case, execution speed is not that important, faster compile times are. GCC doesn't fit the bill anymore. Things change. But hey, we employ a language that has several toolkits available, so we can experiment and eventually pick one.
Imagine I like to contribute to open source projects and I really love C and want to help to improve a C toolkit. Suppose I see the GCC source code and judge that too difficult for me to grasp. Then I download the LCC project and find that easy to understand and improve upon, so I do it. The result is a gain for the C language, because a C compiler was improved someway. If C had only GCC as a compiler, then I couldn't help and no gain would be possible.
That are just two examples to show that freedom of choice is important.
No doubt the current approach of having no language specification for Rust and just evolving the single compiler as fast as possible has its advantages, but I think people should be aware that it has its disadvantages as well. Things that we programmers could consider minor nuisances can mean a big NO for business oriented minds.
I understand your arguments, guys, but it doesn't matter the slightest that "I" understand it.
Hadrien,
Java ecosystem benefited a great deal from having multiple compilers available. From the top of my head: Borland provided its own Java compiler back in the days of Borland C++ 5 (brought native code generation), Symantech's Café (brought the first Java IDE), IBM's jikes (brought lightning fast build speeds, much faster than Sun's javac), Microsoft's Java compiler (brought seamless Windows integration), and GCC.
Thanks for your time, my friends.
2 Likes
There are people looking at adding a cranelift backend to Rust to make compilation faster at the cost of runtime. Would you consider that a separate toolkit? If not, what's the advantage of having people rewrite a parser just to change the backend?
If Integer32 maintained their own fork of the rust compiler, would it be a separate toolkit?
I don't think that actually follows. There are at least dozens, probably hundreds or more, of toy C compilers. Improving them is largely irrelevant to the C language, because there's nothing they're better at than other compilers. (Well, when it comes to being C compilers. They obviously are useful as learning aides for people taking compiler classes, but that doesn't help the C language in particular.)
3 Likes
While I don't want to say that it's a bad idea to have multiple implementations, or a language standard, I have to call out dubious claims like this:
Generally speaking, companies refuses to adopt single supplier solutions.
This is pretty far from the truth. Wildly far. While Python has multiple implementations, non-CPython implementations are a statistically insignificant blip in the ecosystem. I guarantee you that most companies that use Python don't use or care about PyPy, JPython, IronPython, etc, and would be happy to continue using it even if they didn't exist. And Python is a huge fraction of the software industry right now. As much as I think those implementations are great to have, they are niche.
9 Likes
First of all, this is just not true. Companies would like to be able to shop-around, sure, but many many things in business come from one vendor/supplier and even when they don't the vendor-locking is so strong that once you start using something it practically becomes on-supplier thing anyway. In SW notable examples include: AWS, Oracle, Windows, iPhone, and so on.
Second of all there is potentially unlimited amount of suppliers of Rust compiler. Anyone can fork and become a new Rust compiler supplier. Sign a 10 year contract with me for $10M/year and I'll be happy to supply your with Rust compiler. Hell, I'll throw in phone support during business hours and so other sweat things.
So it's all non-argument, sorry. It applies logic suitable for propriety products, to an free Open Source project.
5 Likes
That's interesting to me; in that case, why are you using C in the first place?
2 Likes
BatmanAoD,
we choose C for this product because despite generating big and slow executables, it was safer and more productive than the alternative, Assembly language.
Dear friends,
I did my best to expose my concerns. I don't need to convince anyone. I understand your views are different from mine. Maybe you are right and being tied to a single compiler is not an issue as important as I think it is. Time will tell. I wish you the best.
Thanks.
7 Likes
In any case, many thanks for being so civil in spite of our disagreements 
4 Likes
Agreed, thanks for your civility!
I think it's a good idea to have one compiler framework, and do Darwinism on compiler components rather than on the entire compiler. E.g., it's a waste to throw out a perfectly great parser when all you wanted is to upgrade the logic solver. Every ocean that doesn't need to be boiled diverts the available energy into more productive channels.
If this issue is stopping you from adopting Rust, though, it's good for the lang team to know about it. Thanks for posting.
4 Likes
Hopefully one day Rust compiler switch to the LLVM implementation in Rust itself:
3 Likes
Generally speaking, companies refuses to adopt single supplier solutions.
Disagree. Vendor lock-in is well known negative effect, so reality is such that generally speaking this statement is not true.
Counterargument 1: JVM. There is spec and alternative implementations, but it is a failure of declared mission, because many big applications (most Big Data ones) state that it has been tested with Oracle JVM only and either will not run with others or have no guarantees.
Counterargument 2: Linux kernel. Linux Foundation develop single implementation of linux kernel. Guarantee of investment is not in multiple vendors implementing standardized forks of kernel but multiple vendors working on single implementation.
I see this opinion about goodness of standardization from time to time, but there are not so many examples of successful implementation of applications (not protocols). SQL is standartized and has multiple implementation, but migrating large application from Oracle RDBMS to MySql is impractical.
Standards, generally speaking, do not provide you with plug-in replacement. Making abstraction non-leaking is hard in many practical cases, and in case of complex applications impossible. In case of SQL, for example, standard is more applicable to knowledge transfer and not applications mobility.
I think idea of multiple implementations in case of Rust would be counterproductive because it would fragment effort. There would be real danger of "designed by committee" effect should Rust be developed by multiple players. Current single team does amazing job of steering development. Rust guarantees are in raising adoption by major players and best outcome IMHO would be a foundation with financial backers.
5 Likes
I'd just like to point out that all the technologies you mention originated back in the nineties. As far as I know the only alternative JDK implementation that still survives with some success is IBM's but that is because you're sort of compelled to use it with other IBM products. This is simply something that doesn't happen anymore. I suspect it is because there is not enough money to be made out of it. As far as I can tell very few languages apart from C and C++ have multiple successful implementations available. COBOL does.
1 Like
I'm sorry, but your argument is the one that doesn't hold. Maintaining a compiler is way too expensive for any single company to consider forking a viable alternative.