You often need to be pretty good at math. But not because you’re “doing math” to write the code.

In real world software systems, you need to handle monitoring and alerting. To properly do this, you need to understand stats, rolling averages, percentiles, probability distributions, and significance testing. At least at a basic level. Enough to know how to recognize these problems and where to look when you run into them.

For being a better coder, you need to understand mathematical logic, proofs, algebra/symbolic logic, etc in order to reason your way through tricky edge cases.

To do AI/ML, you need to know a shitton of calculus and diff eqs, plus numerical algorithms concepts like numerical stability. This is kinda a niche (but rapidly growing) engineering field.

The same thing about AI also applies to any other domain where the thing being computed is fundamentally a math or logic solution. This is somewhat common in backend engineering.

I’m not “doing math” when pen and paper at work, but I do use all of these mathematical skills all. the. time.

I am an SRE on a ML serving platform.

Part of it is the community. I really like the OpenWRT community, but it’s harder to engage with them when you run a downstream distribution.

But also I’m a bit of a hacker (in the traditional sense). I like to experiment with custom builds of OpenWRT. (And FWIW, their build system uses the same menuconfig as Linux.)

I love my Turris Omnia!

I got the one with the WiFi 6 card. The cool thing is that you can easily open it up and replace parts.

I run the upstream OpenWRT rather than the customized version by Turris. They are good about submitting patches upstream.

TL;DR - We can now control swappiness per cgroup instead of just globally. This is something that userspace oom killers will want to use.

The meaning of version numbers can vary across projects.

One common scheme is Semantic Versioning, which divides the version number into three parts: MAJOR.MINOR.PATCH*

• MAJOR is incremented when there are backwards incompatible changes.
• MINOR is incremented when new features are added in a backwards compatible way.
• PATCH is incremented for smaller big fixes.
• Each number is reset to zero when a higher level number is incremented.

* It’s a bit more complex than this, but this is the gist.

You talk about “non-absolutist,” but this thread got started because the parent comment said “literally never.”

I am literally making the point that the absolutist take is bad, and that there are good reasons to call unwrap in prod code.

smdh

Fair. But unwrap versus expect isn’t really the point. Sure one has a better error message printed to your backtrace. But IMO that’s not what I’m looking for when I’m looking at a backtrace. I don’t mind plain unwraps or assertions without messages.

From my experience, when people say “don’t unwrap in production code” they really mean “don’t call panic! in production code.” And that’s a bad take.

Annotating unreachable branches with a panic is the right thing to do; mucking up your interfaces to propagate errors that can’t actually happen is the wrong thing to do.

Unwrap should literally never appear in production code

Unwrap comes up all the time in the standard library.

For example, if you know you’re popping from a non-empty vector, unwrap is totally the right too for the job. There are tons of circumstances where you know at higher levels that edge cases defended against at lower levels with Option cannot occur.

orlp invented PDQSort and Glidesort. He collaborated with Voultapher on Driftsort.

Driftsort is like a successor to Glidesort.

Glidesort had some issues that prevented it from being merged into std, and which are addressed in Driftsort. IIRC it had something to do with codegen bloat.

The thumbnail is of the 9/11 attack with the Wine logo overlayed.

TL;DR

The two most popular insect specialists used to control spider mites are a ladybug named Stethorus punctum and a predatory mite named T. pyri.

And later they say that the ladybug was the go-to. But new EPA regulations prompted some farms to use pesticides that kill the ladybugs. So the predatory mites are better if you are using those kinds of pesticides.

While the tone of the comment is dismissive, they have a point.

It’s not the engineers that are the problem, or even limited to the tech industry. Dark patterns are top-down business decisions, motivated by money.

It’s not that the “tech industry doesn’t understand consent,” but rather that greedy people do evil things. And software is just a low hanging fruit for that kind of business.

The Rust folks know their CS and PL theory. Of course they’ve considered monads.

That’s what, 2 senior engineers for one year in the Bay or NYC?

Maybe 3 or 4 in a low CoL city?

Or maybe it’s more like an army of grad students?

Not too bad.

Edit: doh, it says in the article

Recommendations will likely include the hiring of one or more Interop Initiative engineers

deleted by creator

You can manually convert a tokio::main to a regular main by constructing a tokio runtime and telling it to block on a top-level future (e.g. an async block).

https://tokio.rs/tokio/tutorial/hello-tokio

That will at least help you break down the problem to locate the issue.

I don't know anything about Windows though. Maybe there's some per-thread setup that needs to be done in tokio's thread pool?

The following comment is literally:

whitequark would be pretty well known to an old Rust team member such as matklad, having been one themself, so no, not anonymous…

But yeah, no one has named dtolnay outside of this thread. Now that the name has been dropped, let’s hold off for something more substantial before we take our pitchforks.