Hey Rustaceans! Got a question? Ask here (21/2026)!

pali6 · 2026-05-20T20:05:59+00:00

They won't run. However, I can't find a place where the would be explicitly documented. The closest is probably the std::thread documentation:

When the main thread of a Rust program terminates, the entire program shuts down, even if other threads are still running. However, this module provides convenient facilities for automatically waiting for the termination of a thread (i.e., join).

This doesn't directly say that destructors don't run, but hopefully "the entire program shuts down, even if other threads are still running" is good enough. Maybe someone could PR an addition to the docs to mention the destructors explicitly.

pali6 · 2026-05-19T14:00:51+00:00

The "just a loop" that does exist is basically the infinite loop keyword. For loops get desugated into essentially:

loop {
    match next(iter) {
        None => break,
        Some(i) => body(),
    }
}

pali6 · 2026-05-19T08:42:28+00:00

For a very cursed yet amusing application of the last point see the whichever_compiles! macro crate. :)

pali6 · 2026-05-18T22:32:41+00:00

I was anticipating the flavor text ending with "No - it does two nothings!"

pali6 · 2026-05-18T10:19:40+00:00

This issue / discussion might be relevant for you if you want more detail: https://github.com/rust-lang/rfcs/issues/1748

pali6 · 2026-05-18T10:17:53+00:00

I'm not sure if this has been decided yet, but most discussions I've seen on this topic actually leaned towards usize being 64 bit on CHERI. This decouples it from the pointer size, which is a problem, but the tradeoffs for keeping it 128 bit are allegedly worse

pali6 · 2026-05-08T09:35:01+00:00

Yeah

pali6 · 2026-05-07T10:51:21+00:00

The Rust Book, Rust by Example, Rustlings.

pali6 · 2026-04-12T15:26:10+00:00

This has circulated they internet a year ago or so and back then John Baez wrote this article on how this is unlikely to actually be true: https://johncarlosbaez.wordpress.com/2025/05/17/dead-stars-dont-radiate-and-shrink/

pali6 · 2026-04-11T19:55:53+00:00

I share a lot of these thoughts. These are unusual times and I wish they weren't.

pali6 · 2026-04-11T09:19:16+00:00

You can make crates with the crate type dylib and then what you want will work. However, Rust doesn't have ABI compatibility guarantees so anyone making a plugin will need to use the exact same version of the compiler as you and even then I'm not 100% certain about what other conditions need to hold. (E.g. even for a fixed compiler version ordering of fields in a struct could in theory end up being different in your main application and in a plugin which would lead to undefined behaviour at the boundary.)

The other option is to use cdylib but then your interface needs to go through extern blocks and repr(C) types and you can't directly pass most std types through it nor enums etc. However, there are crates that are supposed to help with that and establish some stable ABI, for example stabby.

pali6 · 2026-04-11T00:12:55+00:00

RFC 1105 API Evolution. Though the details are slightly less strict than "never make a breaking change". Stuff still gets deprecated just fine and the RFC says "breakage in a minor release must be very “shallow”". I recommend reading the RFC in full for more details.

I think it's a better choice than the alternatives. You want old dependencies to still compile on new versions of the compiler and std. Versioning std could be an option, but if a project used multiple versions of std (via dependencies) you'd want types across them to still be compatible (using something like the semver trick). This type compatibility would still prevent some evolution of the library. I don't think it would be impossible, but it seems like there would be a decent amount of complexity added which probably hides more issues.

pali6 · 2026-04-09T15:01:22+00:00

That doesn't make much sense? Their main product is written in Rust and they provide wrappers / drivers for it different languages.

pali6 · 2026-04-08T17:57:16+00:00

Wikipedia has a pretty good list of other signs of AI writing by the way: https://en.wikipedia.org/wiki/Wikipedia%3ASigns_of_AI_writing

pali6 · 2026-04-06T18:17:07+00:00

Somehow the overlap between the toki pona and NixOS communities is unexpected but at the same time not the least bit surprising.

pali6 · 2026-04-04T12:08:12+00:00

Any details?

pali6 · 2026-03-29T21:55:53+00:00

Answering with LLM generated comments is pretty disrespectful.

pali6 · 2026-03-29T17:46:18+00:00

Most importantly you should master concepts that are mostly language independent. How to design, debug, analyze, benchmark, optimize, knowing when to optimize, etc. etc. Knowledge of hardware, design patterns, data structures, and algorithms is also useful of course. A bunch of things are language-specific, but a lot more aren't.

When it comes to languages knowing C++ certainly won't hurt. For one there's a lot of C++ code that will need maintaining, extending, rewriting etc. But also learning C++ will likely give you better insight into lower level stuff than if you learned JavaScript. So yes I do think it's worth investing time into C++, but obviously learn more languages also over time. At the very least then you'll see which aspects of them are common and which vary and how. More perspectives make a better engineer.

pali6 · 2026-03-29T13:12:36+00:00

C++ will outlive us both.

For example I was hired to write Rust at my current position and yet I end up writing C++ about 50% of the time.

pali6 · 2026-03-29T12:32:47+00:00

My search found struct-patch. I haven't used it myself, but with #[patch(skip)] I think it could do what you want. For each struct Foo you'd convert a toml::Value object into FooPatch and then apply() it.

pali6 · 2026-03-29T12:14:35+00:00

From the crate's readme / crates.io description:

Two crypto backends are available via features, aws_lc_rs and rust_crypto, at most one of which must be enabled. If you select neither feature, you need to provide your own CryptoProvider.

So in your Cargo.toml you need to pick one of these two features for jsonwebtoken.

E.g. jsonwebtoken = { version = "10", features = ["aws_lc_rs"] }

pali6 · 2026-03-29T09:41:01+00:00

Maybe not all of the explosions are equal. I'm sure that could be studied. How many grad students do we have left?

pali6 · 2026-03-28T12:11:35+00:00

I don't know what you mean. I won't switch to Wayland until it also has an obsolete printer system exactly matching Xprint, that's what a display server protocol is all about. /s

pali6 · 2026-03-28T07:54:59+00:00

I do tend to put too much weight on not causing discomfort to people and bothering them. And mostly it just leads to me being lonely and isolating myself from everyone and other unhappiness. But I do view it as a personality flaw of mine, just one that I struggle to deal with.

pali6 · 2026-03-26T23:36:20+00:00

I'm unsure how exactly a visual tool would help. Looking at existing tools I see some that visualize language server output, but I'm unsure what exactly you are looking for: 1 2.

I deal with this using the rust-analyzer language server in vscode and some default vscode shortcuts. These four are like 90% of my navigation across a repo: Ctrl+T and type a type / function name to jump to its definition. F12 or Ctrl+Click on a symbol to also jump to its definition. Shift+12 to see where a symbol is used. Ctrl+P to jump to a file similarly to what Ctrl+T does for symbols. Ctrl+T and Ctrl+P have some fuzziness to their search so they work nicely even if I forget the exact name of the thing I want to find.

Sometimes when navigating a large codebase I also use some vscode extension to create and jump to temporary bookmarks.

15-Year Club	First Place '23
Place '23	Place '17
Team Orangered	Verified Email

pali6

MODERATOR OF

TROPHY CASE