This post is very welcome. It’s sure more relevant than many posts made in this instance.

Please continue to post whatever you like, as long as it’s on-topic.

The uppercase A in Axium.

Very quickly skimmed Cargo.toml and main.rs.

• What’s with the title-case name?
• The name proximity to axum is also not cool.
• You should mention that this is built on top of axum in the project description.
• How did you end up using both lazy_static and once_cell, when OnceLock has been stable since 1.70 and axum’s MSRV is 1.75?
• Why did you copy-paste min-sized-rust flags?
• You can actually print like this:

println!("{proto}://{ip}:{port}");

instead of

println!("{0}://{1}:{2}", proto, ip, port);

and the positional indices are redundant anyway.

• Since you’re depending on tracing, you should actually use tracing::error instead of eprintln!("❌ ...").

Okay. I will stop here.

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✋

Oh, we got a nu-M$er here. lol.

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.

You need to call ./y.sh prepare again

Aha! Good to know. And yes, improved documents would be of great help.

Thanks again for working on this.

But running

./y.sh prepare
./y.sh test --release

does work. That’s what gave me the impression that clean all doesn’t actually clean everything!

Yeah, apologies for not communicating the issue clearly.

cp config.example.toml config.toml
./y.sh prepare
./y.sh build --sysroot
./y.sh clean all
# above commands finish with success
# below, building succeeds, but it later fails with "error: failed to load source for dependency `rustc-std-workspace-alloc`
./y.sh test --release 

And then trying to use the “release” build fails:

% CHANNEL="release"  ./y.sh cargo build  --manifest-path tests/hello-world/Cargo.toml
[BUILD] build system
    Finished `release` profile [optimized] target(s) in 0.03s
Using `/tmp/rust/rustc_codegen_gcc/build/libgccjit/d6f5a708104a98199ac0f01a3b6b279a0f7c66d3` as path for libgccjit
   Compiling mylib v0.1.0 (/tmp/rust/rustc_codegen_gcc/tests/hello-world/mylib)
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-linux-gnu`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `mylib` (lib) due to 1 previous error

I will make sure to report issues directly in the future, although from account(s) not connected to this username.

Oh, and clean all doesn’t work reliably. Since trying to build in release mode after building in debug mode then cleaning is weirdly broken.

And It’s not clear from the README how to build in release mode without running test --release. And the fact that all combinations of --release-sysroot and --release --sysroot and --release --release-sysroot exist doesn’t help 😉

@antoyo@programming.dev

I gave this a try for the first time. Non-LTO build worked. But LTO build failed:

x86_64-pc-linux-gnu-gcc-15.0.0: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found

I don’t have the time to build gcc and test. But presumably, liblto_plugin.so should be included with libgccjit.so?

Great to see this progressing still.
Great to see you posting here as well.
All the best.

Where does one even start ?

In any rust project, you start with API docs, and the examples folder if one exists. Just make sure the examples belong to the current version you will depend on, not the master/main branch. The link above is from v0.13.1 for example.

Doubly linked list is one of std’s collections. And safety in Rust is built on top of unsafely, because there is no way around that.

Did you try to actually look up literally anything before asking?! Because simply checking out std::collections docs would have given you some answers.

^{Who memory-holed 2021 an why❔😉}

They talk too much. But almost none of them actually code or know how to at a good level.

We have someone just like that here.

Now that others got all the technicalities out of the way, maybe ChromeOS/ChromiumOS would be something along the lines of what you’re looking for? not that anyone should choose to daily-drive it.

While you missed the mark here since typst has all the important stuff open (I wouldn’t use the web interface even if it was free/open source), I appreciate that you’re keeping an eye open.

If you were in r*ddit’s rust community a few years ago, you probably would have been banned, just like me😄

A blog post from M$ mentioning Rust with zero code

=> straight to the top

A news article regurgitating the same thing a week later

=> straight to the top

Another news article two weeks later regurgitating the same thing, possibly with the addition of a random tweet from some M$ dev

=> straight to the top

Anyone not sucking nu-M$'s ****

=> banished to the bottom, or worse.

Things got so silly to the point where I made this jerk post (archive link) about one of these silly posts.

I wouldn’t correct you if this was a general community where the internet gantry hangs in numbers like the multiple !linux communities, but let’s keep things more factual here in !rust.

After Wedson quit months ago, no one from the Rust-For-Linux effort has quit/resigned/whatever. No one quit who is relevant to current mainline kernel development in general, either.

There is a difference between the actual Rust-For-Linux team, and Rust proponents who may write kernel code out-of-tree, or may happen to still be listed as maintainers in a dead poor GPU driver. Confusing the two is good for drama, but let’s not do that here.

And the bad boy maintainer is entitled to his opinion (which I disagree with of course). An opinion which will always be more informed and relevant than 99.999% of whatever the internet gantry has been contributing.