sunshowers

Like all things in life, there is a balance :) I didn't remove the cattle vs pets analogy but I did replace "terminate" with "handle".

Look, you can either let people make a living and manage their own lives while contributing to society, or you can not let them make a living and ensure they're housed and fed. You can't be angry at A and also be angry at B.

Nextest does run tests in lexicographic (binary, test name) order by default, so first executions tend to be staggered. Unfortunately this is a known problem that is much larger than nextest, and it is why Windows introduced Dev Drive with a mode to disable AV/EDR on those drives entirely.

I wish I had a better answer here — it is frustrating how poorly behaved the EDR stuff tends to be. Maybe I should try and network a bit to get in touch with the people working on this stuff. (Planning to be at DEF CON this year, so come find me if you work on this stuff and will be there!)

From what I can tell, a big part of the problem in Europe is that people seeking asylum are prohibited from making a living (due to widespread belief in the lump of labor fallacy) and so have to be dependent on welfare.

The benchmarks are against non-doctest cargo test runs. (But you should measure against your own project, of course!) Unfortunately Cargo doesn't provide enough information for nextest to run doctests reliably with.

I think in practice you're right that GitHub Actions' caching slowness can end up dominating performance. I don't have any great tips other than to measure.

> Can you run tests serially in the (horrible) case when tests need to build on one another?

Yes: https://nexte.st/docs/configuration/test-groups/ (edit: though tests that build on each other is a bit harder — test groups are meant for when tests need access to a shared resource)

> How are you querying for the tests? Is that just built into rust's test stuff?

Just running --list against test binaries.

> Would it be possible to fork the test process? It'd be pretty interesting if you could spawn a test process, and then fork it for each test to save both on memory and any static state stored within the test.

This is possible in principle, but nextest doesn't really inject itself into tests like that (injection can cause reliability issues in practice, and a big focus of nextest is reliability). Forking is also not possible in multithreaded programs.

Thanks! BTW you might enjoy setting CARGO_TERM_COLOR=always in your environment :) dtolnay/rust-toolchain does this automatically but it looks like you aren't using that action.

Oh gosh, were we to be so lucky :) just aiming to solve problems my coworkers and users see, and doing it with care, is all.

The How it works [1] and Why process-per-test? [2] pages should answer your questions.

[1] https://nexte.st/docs/design/how-it-works/

[2] https://nexte.st/docs/design/why-process-per-test/

Yeah that was indeed the inspiration (though I'm pretty sure it predates Kubernetes!) but the juxtaposition with "terminate" is unfortunate.

That's fair! I'll find a way to rephrase it.

edit: Updated to "Detect and handle slow tests". Thanks again!

That is indeed the pun =)

Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.

I'm sure you're aware there's a huge amount of computation that isn't matrix multiplication :)

My successful application took around 12 hours of writing and editing across 3 days, though I was lucky that most of my portfolio was already open source or otherwise public. Some people spend more, some spend less.

It is worth keeping in mind that we write a _lot_. If you don't enjoy the process of writing, you might not like working here.

We have a number of TLA+ models at Oxide. Here's one:

https://github.com/oxidecomputer/omicron/blob/8b0886dbd02229...

Updated https://oxide.computer/blog/iddqd-unsafe#what-about-formal-m... with some notes.

Mostly chatted with some people and figured it out with their help.

Rust is a beautiful language. Gorgeous.

I'm a huge fan of Rust! I like to think my writing makes the Rust community better more than it annoys people :)

If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe

I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).

I look at people saying things like "Rust has a miserable DX" and I wonder whether I live on a different planet from them.

A one-shot process is easier to build and reason about than an event-driven server (speaking as someone who has written plenty of both).

The problem is that threads are not fault boundaries but processes are. So they're not interchangeable when you care about resilience and misbehaving code.

The secure/double slip knot that's linked in the story. I practiced it a few times (making sure the knots are in opposite directions took a bit of retraining muscle memory) and can tie it by heart now.

Thank you for the link! Just donated. That site changed my life in a small but persistent way — my shoelaces haven't come undone in more than a decade now.

Elliptic curves over reals and the complex numbers had some physical/scientific meaning, but elliptic curves over finite fields had none before cryptography.

Since iddqd works on structured data, the model-based tests (while not being coverage-guided) do a lot of the kinds of things fuzzing would do against an algorithm which accepted unstructured data. In principle the bitstream from which structured data is generated could be provided by a fuzzer rather than the system RNG, but proptest makes that somewhat inconvenient. It's possible the newer Hegel library makes that easier, though.

(You're welcome!)

At this point the subsidized rates are only available with individual plans. In principle your workplace can pay for an individual plan for you, but for compliance reasons that is likely only feasible at smaller places that are primarily open source oriented (so there's little risk of proprietary code leaking).