make uses multiple processes for parallelism, or what the blog post (below) calls “interprocess parallelism”. cargo/rustc has that and intraprocess parallelism for code generation (the backend) already. the plan is to have parallelism all the way starting from the frontend. This blog post explains it all:

https://blog.rust-lang.org/2023/11/09/parallel-rustc/

Cool and all. But missing some experiments:

• cranelift
• multi-threaded rustc
• undoing type erasure after the split
• lto = "off"
• strip = false (for good measure)
• [PRIORITY] a website that works with Tridactyl✋

Along the same vein, too many open source projects don’t factor in non-“gnu/linux” environments from the start.

No one is entitled to anything from open-source projects.

I spent time making sure one of my public tools was cross platform once. This was pre-Rust (a C project), and before CI runners were commonly available.

I did manage it with relative ease, but Mac/mac (what is it now?) without hardware or VMware wasn’t fun (or even supported/allowed). Windows was a space hog and it’s a shit non-POSIX OS created by shits anyway, and Cygwin/MSYS wouldn’t have cut it for multiple reasons including performance. The three major BSDs, however, were very easy (I had prior experience with FreeBSD, but it would have been easy in any case).

People seem to have forgotten that doing open-source was supposed to be fun first and for most. Or rather, the new generation seems to never have gotten that memo.

POSIX is usually where a good balance between fun and public service is struck. Whether Mac/mac is included depends on the project, AND the developers involved. With CLI tools, supporting Mac/mac is often easy, especially nowadays with CI runners. With GUIs, it’s more complicated/situational.

Windows support should always be seen as charity, not an obligation, for all projects where it’s not the primary target platform.