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.
> 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++
For a good while this process was just straight up not possible for C and C++, until someone put in a lot of effort to recreate the bootstrap process for reasons of reproducible builds (and it's still a long and complicated process I think only a few people have done). For decades people were just building from source with compilers that had extremely long and undocumented bootstrap chains (they may have documentation for how to bootstrap from a different C or C++ compiler, but there wasn't one that would start from scratch).
I laughed reading the comment above yours. I also laughed reading yours, you are so right on. Next, I am expecting someone telling that there is a javascript on github to automate that build process...
This is not what I was expecting computer science to become, 30 years ago...
Go need a smaller chainloading process from C/C++ too. But the good thing it's there are prebuilt self-contained binary ports from every OS to almost any OS so you can bootstrap it with very little.
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.
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).
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.
> 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++
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/
And this is good because? Seriously, modern devs have lost their minds if they think that this state of affairs is okay.
For a good while this process was just straight up not possible for C and C++, until someone put in a lot of effort to recreate the bootstrap process for reasons of reproducible builds (and it's still a long and complicated process I think only a few people have done). For decades people were just building from source with compilers that had extremely long and undocumented bootstrap chains (they may have documentation for how to bootstrap from a different C or C++ compiler, but there wasn't one that would start from scratch).
I laughed reading the comment above yours. I also laughed reading yours, you are so right on. Next, I am expecting someone telling that there is a javascript on github to automate that build process...
This is not what I was expecting computer science to become, 30 years ago...
And that JS project needs only 1Gb of node.js modules to run. Aren't computers fun? /s
Go need a smaller chainloading process from C/C++ too. But the good thing it's there are prebuilt self-contained binary ports from every OS to almost any OS so you can bootstrap it with very little.
O really? Please.. can I bootstrap it here?
CYGWIN_NT-5.2 1.3.22(0.78/3/2)
There are some Go backports to XP.
https://github.com/BieHDC/go-backports
We need memory safety but Rust is not the answer.
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?
It has a partial spec.
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.
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).
There are self-hosted Forths
Subleq and Eforth can self-compile, yes.
Being base.dec a subleq EForth image and eforth.fth the source code, to create a new one:
So by just having a recent working VM you can compile the rest with uxn2 or 'uxncli dribflim.rom app.tal app.rom'. Tal files are source files.