4 ms·
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
by tannhaeuser 6y ago
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
- Ar-Curunir 6y agoWhy? And FWIW there are alternate implementations (mrustc) and alternate backends (cranelift)
- deleted 6y ago[deleted]
- nindalf 6y agoCould 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.
- tannhaeuser 6y ago> Rust is stable 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.
- nindalf 6y agoForget 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.
- nicoburns 6y ago> 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.
- cbarrick 6y agoThe 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. [1]: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc [2]: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift [3]: https://github.com/rust-lang/miri https://github.com/rust-lang/miri