The uppercase A in Axium.
BB_C
joined 2 years ago
Very quickly skimmed Cargo.toml and main.rs.
- What's with the title-case name?
- The name proximity to
axumis also not cool. - You should mention that this is built on top of
axumin the project description. - How did you end up using both
lazy_staticandonce_cell, whenOnceLockhas been stable since 1.70 andaxum's MSRV is 1.75? - Why did you copy-paste
min-sized-rustflags? - 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 usetracing::errorinstead ofeprintln!("❌ ...").
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".
/mj this post was an experiment to see If I should start posting from my personal jerk archive here. But exactly as I expected and anticipated given the visibility in public feeds, this community has decent traffic, but none of the culture, or any familiarity whatsoever with the meta-ironic jerking style of the OG community. The lack of a separate meta sub/community is also not helpful since it forces users to /mj inline. But that separate community would have been public too, possibly compounding the problem.
It is indeed when paired with an optimizing assembler, a sophisticated static analysis tool in its own right. And just like Rust, you have greybeards hating on such provided safety because "meh it's not close to the hardware anymore", like that old man Mel.
Its called fetching it.
No. I was specifically thinking of webfinger. That's Lemmy's (ActivityPub) way of checking if an id (user or community) exists or not. Then, an instance may "read" the remote community using its outbox (if requested), and a snapshot of that remote community would now exist in the local instance. That "snapshot" doesn't get updated unless another attempt is made to view the now known remote community, AND a certain period have passed (It was 24 hours the last time I looked). In that second time, a user may actually need to make a second request (refresh/retry) to see the updates, and may need to do that after a few seconds (depending on how busy/fast instances are).
If at least one user however subscribes to that remote community, then the remote instance live-federates all updates from that community to the subscribed user's local instance, and all these issues/complications go away.
You need subscribers from instances, not views. Without subscribers, an instance may have an outdated version of your community without updates. People may see your community because someone pinged* it recently, maybe via a search, and their instance grabbed your then outbox at that time.
Ideal Federation is achieved when you have 2+ subscribers from every instance federating with your community instance. One subscriber would be enough too, but people choose to nuke there accounts sometimes, and Lemmy has the option to really erase an account as if it never existed 😉
* or whatever Lemmy calls it, haven't looked in a while.
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:
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✋
ignore nulls, ignore race conditions, choose go
#WebVibin' #HumoriestDev #DockerFiddler
view more: next ›
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.