lightweight

😑
/me looks inside
/me finds >20 sub-crates and all kinds of dependencies including a web server
/me starting to think i’m the weird one for saving my passwords in a text file and almost getting annoyed about having to use cotp

Brother, some of us already moved from lld to mold to wild already. The project could have waited a little bit, then went with the implemented-in-rust option directly.

Thank you (+ contributors) for doing this work and keeping us posted.

Last time I took a look, I think LTO was broken. Is that still the case?

I always felt “for embedded” was always selling this crate short, or rather pushing potential users away who aren’t aware some data structures here are useful in non-embedded scenarios.

I for example use the admittedly simple Deque (with its is_full()) method in one of my projects for pushing/popping tasks to/from a fixed-size thread queue, which one could argue is a very unembedded-like use-case 😉.

(stating the obvious)

You can already :

res_res??;
// or
res_res?.map_err(..)?;
// or
res_res.map_err(...)??;
// or
res_res.map_err(...)?.map_err(...)?;

With res_res.flatten()?, you don’t know where you got the error anymore, unless the error type itself is “flatten-aware”, which is a bigger adjustment than the simple ergonomic library addition, and can become itself a problematic pattern with its own disadvantages.

Result::flatten() is probably my favorite addition

It’s rare to a have a negative reaction to a library addition. But I don’t like this one at all actually.

For me, error contexts are as important as the errors themselves. And ergonomically helping with muddying these contexts is not a good thing!

This is cool and lies within my area of interests.

One thing that is not clear is if there will be a way to do playback outside of custom players. If a stream can’t be trivially grabbed, and/or played directly in mpv (via ffmpeg library support or otherwise), this won’t be very useful for me.

It would also be interesting to see how the video streams are encoded, if the GOP size is forced to 1 and it’s all intra frames or not, and if it’s not, how synchronization after recovery (where FEC is not enough) is done.

Hopefully this gets posted again when the code is released.

Good thing we can edit titles here.

As someone who hasn’t been following this, playing the connotation game (using “automatic” instead [partially] “implicit”) is rubbing me the wrong way.

Otherwise, the keyword use seems too generic to be used for this. But I’m sure this has been bikeshedded already, and if it hasn’t, it will be.

I only skimmed this. But my mind from the start immediately went to

struct CommonData {
 // common fields
}

enum VariantData {
  Variant1 {
    // Variant1 specific fields
  },
  // same for other variants
}

struct Search {
  common: CommonData,
  variant: VariantData,
}

but I reached the end and didn’t see it.

Isn’t this the way that comes to mind first for others too?

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.

Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as “Rust makes it harder for a ‘contributor’ to sneak in LLM-generated crap”.

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.