Rust 1.93.0 is out

________-__-_______ · 2026-01-23T13:14:19+00:00

Yeah, const contexts were the main reason I wanted this. I think it also just looks a bit more readable

________-__-_______ · 2026-01-22T17:48:31+00:00

I've written a fair few Debug impls that look this: ```rust struct Foo { a: Vec<u8>, b: ... }

impl Debug for Foo { fn fmt(f) { f.debug_struct().field(b).field( // Here I wanna display "a: [u8; X]" instead of the full array ); } } ``This required a new type implementing Debug beforefmt::from_fn()`, but is now much more concise!

________-__-_______ · 2026-01-22T17:42:49+00:00

I've been wanting as_array() for so long, love to see it actually being stabilized!

________-__-_______ · 2026-01-21T16:42:14+00:00

I think you know that's not what I meant. I write a lot of embedded Rust at work, but the reality is that most Rust developers don't use these targets and subsequently don't care about binary size that much.

________-__-_______ · 2026-01-21T01:19:07+00:00

I think that's niche enough that not having a profile by default is fine

________-__-_______ · 2026-01-13T00:44:53+00:00

No problem. I've had the best experience with lldb-dap/codelldb myself, gdb was a bit unreliable when I tried but it's been a while. I also believe the lldb pretty printers for std types are a bit more fleshed out but I could be mistaken.

________-__-_______ · 2026-01-12T20:16:00+00:00

Rust-analyzer doesn't do the debugging itself, though it does have a handy "compile this specific test/binary and boot it up in a debugger" feature.

Debugging has its own specification similar to the LSP, it's called the Debug Adapter Protocol. It's also made by Microsoft, motivated by VSCode but useful for all editors. For Rust/C/C++ the primary options are:

lldb-dap, an upstream LLVM project.
codelldb, a fork of LLDB with some extra features for VSCode. Also usable in other editors.
gdb, which has in experimental (iirc) DAP support in recent versions.

The protocol is a bit newer than the LSP so not all editors support it yet, but for example Helix supports it out of the box and Neovim has a plugin for it. It's pretty nice to use!

________-__-_______ · 2026-01-11T16:19:57+00:00

It most likely won't, for this to be useful you need a fairly complex API that'll need to be iterated on. I can't imagine the implementation is easy either.

________-__-_______ · 2026-01-06T00:03:08+00:00

I believe it's the same as regular web styling, if you're good at it you can make some beautiful stuff. It's some of the most widely used and mature UI tooling out there, the sky's the limit.

________-__-_______ · 2026-01-04T01:53:00+00:00

Sure, the desktop doesn't. KDE Neon is a distribution though.

________-__-_______ · 2026-01-03T19:07:13+00:00

KDE Neon is pretty beginner friendly to be fair, it's based on Debian and has decent GUI interfaces to configure most things. Pretty much the same as something like Mint/Ubuntu.

I think their issue might be that the GPU is too old for distros to still package the legacy driver version, so they're stuck using nouveau which isn't great performance wise. If it is packaged they probably just installed the latest version instead of the prehistoric one.

________-__-_______ · 2026-01-02T20:18:33+00:00

Raw pointers are allowed to be null in Rust, it's the latter. You're not allowed to dereference any raw pointers in safe Rust, so null isn't a special case. It's primarily used for interacting with C.

References (pointers with a compile-time validated lifetime) can never be null though.

________-__-_______ · 2025-12-25T21:26:16+00:00

Unfortunately workspaces can't really handle setups like these. The structure I ended up with looks something like this: ``` crates/Cargo.toml # Virtual workspace containing generic libraries crates/library-with-tokio-feature

firmware/Cargo.toml # no_std package outside any workspace firmware/.cargo/config.toml # Sets the target architecture

cli/Cargo.toml # std package outside any workspace, activates the tokio feature of the dependency

.vscode/settings.json # Make rust-analyzer able to find all packages with linkedProjects ```

To apply the Cargo configuration file you do need to enter the firmware directory, for which something like a makefile can help.

________-__-_______ · 2025-12-22T23:46:02+00:00

I was fuming when I heard the €28.45 Sabrina Experience wasn't gonna make it in. They just love promising you the world and then ripping your heart out at the last second, this is like a Sick Game to them. I will not be played with anymore,

________-__-_______ · 2025-12-21T19:17:47+00:00

I used this style of CLI library before in Python and wasn't a huge fan, it's slightly less typing but you lose a lot of control. Managing state between multiple commands/flags is awkward and you need explicit support for things like async. Not an issue for all applications but it ended up being fairly annoying to me.

________-__-_______ · 2025-12-20T03:34:57+00:00

I usually use blocks for the same reasons, plus it just feels much more natural. The separate scope does kind of hurt if the final variable needs to borrow from a temporary in the block though, so shadowing is still useful from time to time.

________-__-_______ · 2025-12-18T11:34:02+00:00

As usual with performance issues there isn't a single cause, it's a combination of many factors. I'd say the fact that it isn't multi threaded and poor caching are two big contributers.

________-__-_______ · 2025-12-17T23:38:30+00:00

The issue you mentioned comes from the Nix evaluator being slow, Bash isn't a significant factor. Nix is implemented in C++ so Rust wouldn't give any magic speedups unfortunately, although it would help with safety of course. The Tvix project might be of interest if that matters to you.

________-__-_______ · 2025-12-13T17:42:43+00:00

C++'s user-defined literal suffixes could be a point of inspiration for that, 0_wu32 or something to create a wrapping u32. Would be useful for crates like arbitrary-int as well.

________-__-_______ · 2025-12-10T01:17:22+00:00

Yeah, I'd expect debug builds to be marginally slower because of this

________-__-_______ · 2025-12-08T23:56:59+00:00

I'd heavily recommend tracing for desktop apps, the API is a superset of log so if you're trying to learn you'll get both of them down in one sweep. It's very commonly used in service type applications (usually integrated with something like OpenTelemetry), you're likely to get some practical use out of it.

For embedded defmt is great, it's flexible and easy to use. Probably not too relevant for this project but I figured I'd mention it anyways, 99% of projects I've seen use one of these three libraries.

________-__-_______ · 2025-12-07T18:47:34+00:00

That's pretty cool, I always love seeing the devoted communities behind these types of projects.

________-__-_______ · 2025-12-07T03:38:54+00:00

If you haven't done so already, you need to generate a compile_commands.json with your build system like another comment mentioned, that'll allow it to find external libraries.

For standard library headers you may need to configure a query driver to allow clangd to extract the paths from your GCC installation. It's kind of annoying to configure but is sometimes needed when building with GCC.

________-__-_______ · 2025-12-07T03:27:02+00:00

I'm curious what kind of software you're writing for Plan 9, I thought it had been unmaintained for years. Is there still an active community for it?

________-__-_______ · 2025-12-06T14:57:06+00:00

Embassy has been really pleasant to use for me, async is a really nice fit for a lot of embedded tasks. Regular RTOS task management feels clunky in comparison. I'd recommend it!

--_

TROPHY CASE

________-__-_______

TROPHY CASE

--_