121–130 of 135 posts
Earlier quoted context omitted.
Counterexample: the fact that there is only a single official go compiler is great advantage IMO since it enables a lot of cool tooling and great new features are introduced quickly in the official implementation.
Doesn’t Go also have a GCC version?
Earlier quoted context omitted.
Thats just silly, there are a lot of production ready languages that only have one full implementation such as Typescript, Elixir etc
> (...) such as Typescript It seems you're oblivious to the fact that projects such as swc[1] exist, and have been adopted by projects such as deno. [1] https://swc.rs/ > Elixir etc I'm not familiar with Elixir nor am I in a googling mood. Nevertheless that was an awfully short list. Why is that?
Earlier quoted context omitted.
> (...) such as Typescript It seems you're oblivious to the fact that projects such as swc[1] exist, and have been adopted by projects such as deno. [1] https://swc.rs/ > Elixir etc I'm not familiar with Elixir nor am I in a googling mood. Nevertheless that was an awfully short list. Why is that?
swc only does transpilation, it does not support TypeScript's type-checking which is its main feature.
Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust
What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries & binaries to be distributed? (at least in theory, gcj didn't work out well)
More architectures supported at least. Now Rust can really be used anywhere C is used
Non-standard C-like languages are used in computer graphics and GPU computing (OpenGL, Direct3D, OpenCL), but strictly speaking they don't count as C.
Earlier quoted context omitted.
Somehow Python people, Java people, Ruby people, JavaScript people managed to produce multiple independent high-quality implementations.
python has 1.5 implementations pypy is close, but not that close to being a complete implementation.
Micropython can be counted as 0.25 or something :)
Earlier quoted context omitted.
The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private: - They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process. - They're treating rustc as the reference for correct Rust. This doesn't mean…
They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough
Earlier quoted context omitted.
It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?
Borrow checker is compile time. There is no reason to have multiple implementations.
Earlier quoted context omitted.
Since there is now OpenJDK, there was no reason to keep working on it, and both GCJ and the associated class libraries didn't follow the evolution in the Java language. In the beginning GCJ became only an ahead-of-time bytecode compiler, with the Java->bytecode translation done using ecj; but ultimately there was no reason to keep it around at all and it was deleted in GCC 7.
Ahead of time native code compiler. It was kept around for a long time after everyone went to OpenJDK, because it was the only project with certain unit tests for GCC code paths, when that was eventually sorted out, it was when they dropped it.
Earlier quoted context omitted.
> Yeah, it's not like Google (and dozens of others) has an internal fork of Linux... Doesn't matter for completely internal stuff. My concern is public code requiring non-public toolchains to compile. I have experienced this enough during the decades. I don't want to fight with this again. Google doesn't want to touch Linux for their devices anymore, so they're building Fuchsia, but let's not digress... > Multiple co…
> What GPL brings to the table is strict openness, not compatibility. I kinda wonder where this has been an issue with LLVM re: non-public toolchains, and public code where it wouldn't also be an issue with GCC. FWIW I definitely could see it being an issue in HPC/graphics/ML. > I also wonder whether people would be this reactive to this issue if $company announced a closed source compiler with strict rustc compatibi…
We wanted to use these thing in newer systems, but it was not always possible, and made our lives way harder than it should be. At the end of the day, you buy vendor's hardware and want to couple it with more modern software, but the vendor doesn't want this for some unknown reason. Planned obsolescence, maybe.
Now, consider that a company pulls the same shenanigans, but by moving the magic to the compiler. All source is open, but can't be compiled because, while the code valid, its correct compilation needs a specific compiler behavior, and the vendor who opened the source cannot share the compiler in source form due to "trade secrets". They may require you to send the code in to "make sure that it's fine", or "sign an agreement" to get the compiler, for a fee, maybe.
I don't want to live in this world, or leave anyone accidentally in that state.
> Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.
As someone else noted, gccrs people say that "We strive for rustc compatibility. We will not extend or mangle the language, and consider rustc as our test suite." This is a pretty strong commitment to "many implementations, single behavior" promise.
I started my computing journey in a very open and flexible ecosystem, and with every stopgap put as in the name of security, this openness and flexibility eroded step by step. With this pace, programming and development will be confined to corporations which design the hardware and OS running on them, and PCs will be consoles with keyboards.
I don't want to live in such future. This is why FSF/GPL is important, for me.
Earlier quoted context omitted.
> Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. If there are people who care about these historical architectures, they can do the work to maintain them in LLVM. That's how m68k support was added.
So in order to use rust you also have to become a compiler developer?