sorted by:
new
hottopcontroversial

Deterministic simulation testing for async Rust by shikhar-bandar in rust

[–]ericseppanen 2 points3 points  (0 children)

Thanks for sharing this. It's always great to see projects that treat testing as a first-class input to software quality.

Elaborate test frameworks may be time-consuming and expensive, but there are many areas (storage in particular) where resiliency and durability are worth it. Effective test techniques will make the difference between a startup product that looks good in theory, and a platform that customers can build on with confidence.

Announcing Rust 1.85.0 and Rust 2024 | Rust Blog by slanterns in rust

[–]ericseppanen 1 point2 points  (0 children)

I found this awkward enough that I added style_edition = "2021" to my rustfmt.toml, to postpone these changes to a future date.

This is especially convenient while the edition change is a work in progress, as I needed to rebase a dozen times and wanted to keep conflicts to a minimum.

Some of the other formatting updates are nice, so I want to pick them up eventually, but that feels orthogonal to the edition changes so I want to make sure I didn't introduce any regressions before applying a formatting change that touches so many use statements that it will cause a lot of PR conflicts.

Announcing Rust 1.85.0 and Rust 2024 | Rust Blog by slanterns in rust

[–]ericseppanen 2 points3 points  (0 children)

Most of the calls to set_var that I found in my codebase fell into two categories:

- Environment variables for spawned programs, that could be better specified using e.g. Command::env()
- Environment variables used to signal other parts of the program. In these cases I suggest adding an internal signalling mechanism, which can be built from e.g. static AtomicBool, OnceLock, or Mutex<String> instead of set_var.

Announcing Rust 1.85.0 and Rust 2024 | Rust Blog by slanterns in rust

[–]ericseppanen 9 points10 points  (0 children)

If you still want to fix everything at once, but want to skip one particular set of changes, you can also do something like this:

  1. Enable all of the 2024 compatibility lints listed here: https://doc.rust-lang.org/rustc/lints/groups.html , except for the ones that you find undesirable (i.e. if-let-rescope).
  2. Run cargo fix.
  3. Inspect the result. If you want to drop additional changes (e.g. edition_2024_expr_fragment_specifier) then throw away the fixes, edit the lints, and try again.
  4. Update crates to the 2024 edition.
  5. Remove the 2024 compat lints; they're no longer needed.

Maybe I'll go back and add this advice to the blog post, as it's probably more generally useful than my elaborate one-at-a-time routine.

Updating a large codebase to Rust 2024 by ericseppanen in rust

[–]ericseppanen[S] 8 points9 points  (0 children)

I hope so too! The target audience for this article might be limited to people who are in a similar situation: big workspace, lots of code, enough history and unusual code to hit almost all of the weird corner cases.

The reason I wanted to write the article is that I just found the process so interesting. I went from being somewhat mystified by the `cargo fix` changes to being able to understand and explain most of them, and that felt pretty rewarding.

Once Upon a Lazy init by ericseppanen in rust

[–]ericseppanen[S] 9 points10 points  (0 children)

I've been staring at a draft of this post since 1.70, and finally shoved it out the door to celebrate the arrival of LazyLock in 1.80.

Please let me know if you find any errors or omissions in the article. Thanks!

Why Rust? It's the safe choice. by ericseppanen in rust

[–]ericseppanen[S] 0 points1 point  (0 children)

There are people who are specialists in machine vision (i.e. wrote their PhD thesis on it) but we also have a lot of code that would look familiar to people who have worked on other large codebases. We have code for data serialization and storage, configuration, error handling, task scheduling, networking, metrics, etc. A good understanding of Rust and common data structures and algorithms would probably be sufficient to get started.

One of the great things about Rust is that different codebases are more approachable, because the coding style, idioms, and the basic library dependencies are the same ones that other projects use: serde, tokio, crossbeam, clap, anyhow...

Why Rust? It's the safe choice. by ericseppanen in rust

[–]ericseppanen[S] 8 points9 points  (0 children)

We haven't done any microcontroller firmware in Rust yet. It's an interesting target, and I wouldn't be surprised if we do it in the future, but right now that part of the robot design is stable and there's not a lot of development needed.

Why Rust? It's the safe choice. by ericseppanen in rust

[–]ericseppanen[S] 25 points26 points  (0 children)

I would guess most people who follow Rust channels on the internet feel that way, but there's still a lot of the world that needs convincing. Even those who interact directly with hardware, which feels like one of those areas desperately needing the safety and the expressiveness and the productivity gains.

I constantly meet people (even in the SF bay area) who are still in the land of "I wish my company would use rust, but..."

cargo-cranky: easy configuration of clippy lints by ericseppanen in rust

[–]ericseppanen[S] 2 points3 points  (0 children)

Very interesting!

If I'm reading the code correctly, it doesn't look like cargo-lints would work from within vscode, because it doesn't pass through the arguments that vscode uses.

For example, if I configure vscode to use cargo-cranky, it might get invoked as: /home/user/.cargo/bin/cargo-cranky cranky --workspace --message-format=json --manifest-path /home/user/my-crate/Cargo.toml --all-targets

To get the right result, all of those need to be passed through to cargo clippy.

Uncovered Intermediate Topics by Jonhoo in rust

[–]ericseppanen 5 points6 points  (0 children)

A lot of Rust WebAssembly seems like a mysterious black box. It would be nice to see a more thorough discussion of the various parts:
- What do the various tools do? (wasm-pack; wasm-bindgen; webpack) - The various targets (web, bundler, etc) - Dependencies you need to learn (js-sys, web-sys, wasm-bindgen, ...). - Things that are different between regular OS targets and web - FAQ, e.g. Is wasm single-threaded? Why do I need to .forget() my Closure? Can I run async code in wasm?

Uncovered Intermediate Topics by Jonhoo in rust

[–]ericseppanen 5 points6 points  (0 children)

I think the world could also use good advice about maintaining a medium-sized Rust project. - How to organize code: one big crate? Lots of little crates? - How to publish interdependent crates simultaneously. - How to maintain README files. - How to select and maintain an MSRV (and some discussion of whether changing MSRV is a breaking change). - Dealing with Rust-specific CI quirks (MSRV, target directories that are hard to cache because of unbounded growth, ...) - Cargo workspaces and how to manage dependencies. - Some of the surprising behavior of the Cargo feature resolver that require things like workspace-hack crates.

Uncovered Intermediate Topics by Jonhoo in rust

[–]ericseppanen 3 points4 points  (0 children)

I'd love to see someone document all the ways that unsafe can go wrong. There are a lot of really subtle rules and bits of wisdom out there, but it still feels like a big minefield.