> In general, the bootstrap relies on a binary package of the previous version. This is unacceptable for an otherwise source-only, self-contained distribution like the NetBSD sources.
This does not paint the full picture. Rust can be bootstrapped with mrustc, which is written in C++
> getting a Rust compiler running in the first place is hard
> bootstrap relies on a binary package
> the compiler would also have to be part of the base system
The gccrs project aims to make Rust a fully supported language in GCC. It is fully self-hosting and can be built from source. Once accepted, it will be one of the languages you get when you build GCC.
When gccrs is ready, it will address all the above objections.
Linux faces the same issues. Today, Rust is optional in Linux and can be skipped on any platform not supported in LLVM and rustc. For Rust to become mandatory in Linux, gccrs is going to be required (for some platforms).
> the release cycles of Rust are not compatible with the NetBSD ones
I do not fully grasp the objection here. Obviously NetBSD would not be forced to use any Rust features they cannot compile. And using gccrs for the NetBSD kernel would not prevent them from bundling LLVM and rustc as well if they want.
Anyway, I am not advocating the use of Rust in NetBSD. I am merely pointing out that solutions to the issues raised are being worked on.
This means that you will be able to use either GCC or LLVM to build your Rust code with rustc (the main Rust compiler). That means you can compile your Rust for any platform that GCC supports.
This only addresses the first point in the blog post (architecture support) but it is an interesting development.
It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breath, and is controlled by a foundation that is controlled by big tech corps.
Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.
The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions.
It's absolutely not changing too fast
> depends on third party libraries that change faster than I can breath
No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies.
Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.
this is the right way to do it. just explain why you think rust is not a good match for your project right now. no politics and no hate for the language.
if it can't be build with Ansi C or perhaps old style C++ it is not self contained i think. depending a Language on some fast moving binarys is in my eye a bad decission. Excuse my english. im not a native speaker.
Why are C and C++ special in this regard? I could just as well claim it's not self-contained unless you can start from source and a snippet of inspectable machine code, like Guix can (which still has fairly significant gaps in what you could call 'completely self contained', if you wanted to poke holes in it).
nextaccountic|27 days ago
This does not paint the full picture. Rust can be bootstrapped with mrustc, which is written in C++
https://github.com/thepowersgang/mrustc
Now, mrustc supports only Rust 1.74. To build Rust 1.92, you need almost 20 builds. But this can be done from source
Guix has written about bootstrapping Rust from source (they care a lot about this). Here is how it looked like in 2018
https://guix.gnu.org/nb-NO/blog/2018/bootstrapping-rust/
stockerta|27 days ago
LeFantome|26 days ago
Are there many architectures that NetBSD supports where GCC is not available?
The rustc_codegen_gcc project allows using the rustc compiler to target any architecture that GCC supports. I think it is pretty far along.
https://github.com/rust-lang/rustc_codegen_gcc
> getting a Rust compiler running in the first place is hard
> bootstrap relies on a binary package
> the compiler would also have to be part of the base system
The gccrs project aims to make Rust a fully supported language in GCC. It is fully self-hosting and can be built from source. Once accepted, it will be one of the languages you get when you build GCC.
https://github.com/Rust-GCC/gccrs
When gccrs is ready, it will address all the above objections.
Linux faces the same issues. Today, Rust is optional in Linux and can be skipped on any platform not supported in LLVM and rustc. For Rust to become mandatory in Linux, gccrs is going to be required (for some platforms).
> the release cycles of Rust are not compatible with the NetBSD ones
I do not fully grasp the objection here. Obviously NetBSD would not be forced to use any Rust features they cannot compile. And using gccrs for the NetBSD kernel would not prevent them from bundling LLVM and rustc as well if they want.
Anyway, I am not advocating the use of Rust in NetBSD. I am merely pointing out that solutions to the issues raised are being worked on.
LeFantome|26 days ago
https://github.com/rust-lang/rust/pull/151156
This means that you will be able to use either GCC or LLVM to build your Rust code with rustc (the main Rust compiler). That means you can compile your Rust for any platform that GCC supports.
This only addresses the first point in the blog post (architecture support) but it is an interesting development.
akagusu|27 days ago
It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breath, and is controlled by a foundation that is controlled by big tech corps.
What could go wrong?
pjmlp|27 days ago
https://ferrous-systems.com/blog/ferrocene-25-11-0/
Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.
budgefrankly|27 days ago
The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions.
It's absolutely not changing too fast
> depends on third party libraries that change faster than I can breath
No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies.
Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.
tancop|27 days ago
Surac|27 days ago
rcxdude|27 days ago
bandrami|27 days ago