Programming languages and pain points


Herdiansyah - a personal blog


Programming languages and pain points


Nowadays, new progamming languages probably pop-up every other month, some of the most popular (relatively) new languages are Rust and Go. Using Wyvertux myself, I wonder if the programming languages can be built without the use of GNU toolchain. So, the starting point of course, is the KISS official repo [1] which has Rust and Daniel M. Matongo’s kiss-lang [2] repo. There are some pain points though, which I would address here.

  1. Bootstrapping Rust (and perhaps Java since I remember when I used Gentoo back then compiling icedTea is painful) is probably notorious for this in the “small distribution” or “Gentoo users” circle since Rust needs itself to build. Guix [3] has a good article about bootstraping Rust using mrustc, and they did it from Rust 1.19.0 to Rust 1.28.0. The current Rust version (as of 2 April 2021) is Rust 1.51.0, therefore if the Guix people do their bootstrap process all over again, it would take even longer.

    You need the last stable version to build the newest version. Some might argue it’s a good thing since it means the language is rapidly evolving, but man it is painful. Especially since compiling Rust can take a long time (this can be attributed to LLVM, but I admit I’m not an expert on the topic so I don’t really know about this one). And more packages are depending on Rust, like Firefox, librsvg, and probably bzip2 in the future. Hell, Linus doesn’t really mind Rust and can consider Rust in Linux kernel (probably in drivers? I don’t think Linus or his possible successors would use Rust in the core Linux kernel) though I don’t know how well would it play since it uses crates extensively ala npm’s packages. I understand the appeal, but if the bootstrap situation can be improved, that would honestly be great. I don’t mind the language, I just mind the hurdles I need to compile it.

    As for D, if you don’t have GNU D Compiler, you’ll have to use their binary to bootstrap to build the DMD compiler. As for LLVM D compiler, the last C++ version supports LLVM 8.0.0 (and they don’t bother updating).

    In comparison, Go and Nim have a fairly pleasant bootstrapping process since Go (1.4 bootstrap) and Nim (csources) which are written in C can build later versions of the respective languages.

  2. Libraries My example, again, is Rust. This doesn’t apply to Go, Nim, and Zig because they don’t require binaries to bootstrap it from scratch. I suspect Crystal to suffer from the same problem though.

    Unlike the rustup binaries they provide over at rust-lang.org which are static (so you can just download its binaries and execute it, without caring whether libsomething.so.19 exists), the bootstrap binary is dynamic. To make matters worse, it is dynamically linked to libgcc.so, which is not available in GCC-less systems. In the past, I used to create my own binary tarballs (which links to LLVM’s libunwind.so instead of libgcc.so), but now I just trick the binary by symlinking libunwind.so to libgcc.so in a temporary directory, and use LD_LIBRARY_PATH to do the magic [4]. In other words, one horrible hack, to another horrible hack. I just hope it will always work in the future releases.

[3] https://guix.gnu.org/en/blog/2018/bootstrapping-rust/