What's Ruby?
An interpreted, multi-paradigm, high-level, general-purpose programming language. You need Rust to build it.
What's Rust?
A compiled, multi-paradigm, high-level, general-purpose programming language. You need Python to build it.
What's Python?
An interpreted, multi-paradigm, high-level, general-purpose programming language.
Do I need, uhm, Perl to build it?
No, but you need Perl to build Rust.
I knew it. What's Perl?
An interpreted, multi-paradigm, high-level, general-
@jschauma FFS when can folks stop making these gratuitous compounding build/bootstrapping dependencies? Ruby needing Rust is probably reasonable. Rust needing Python and Perl is nothing but laziness and cost externalization.
@cbehopkins @dr2chase @jschauma It's the main compiler involved in the only reduced binary bootstrap seed project (https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/) I'm aware of.
As for Golang specifically, it weakens the Google domination, which I find valuable in itself.
Of course, making an interpreter instead of a GCC frontend & using that to compile a self-hosting compiler works too (you still need to compile that interpreter too at some point unless you write in assembler I guess, then you assemble it).
@cbehopkins @dr2chase @jschauma But then that begs the question, why make yet another compiler instead of reusing the optimization & portability work already done by others before you?
Having a compiler implemented in a safe language is a valid answer to that question, but it does mean you're willing to trade-off portability (or a lot more work to be done) in exchange for it.
@lispi314 I'm sorry I'm missing something here with you referring to an interpreter in the context of GCC and Go.
If I understand you correctly, the interest is to bootstrap from the minimal possible outside dependencies. (Rather than the ability to bring up the toolchain in a cross platform situation with minimal complications?)
I guess the concern for me in bootstrapping is simplicity, not code size.
@cbehopkins Unauditable code-size, more specifically.
Golang requires Golang to build.
Currently that means that Guix, in order to not accept arbitrary binary blobs from Google to build Golang, has to start from Golang 1.4 & iteratively build each following one up to the current version.
A Golang interpreter or sufficent GCC frontend (like GCCGO is intended to be) would also short-circuit that chain of builds so that one could build the final Go compiler (in Golang) directly.
@cbehopkins @lispi314 @dr2chase @jschauma I'd add portability. You generally need (and already have, by the time you're porting a second language) C anyway, and GCC provides that nicely, so it's probably already there.
Go is available for fewer platforms than GCC, and seems equally difficult to port (never touched it, so IDK). If your language porting story begins with “port the Go compiler and libs first”, you're not going anywhere.