So, I’d argue that “frontend” and “backend” are the default modes of software engineering these days, and that embedded is a more niche field.

That said, if you’re doing encryption code, you’re doing far more advanced math than backend monitoring and alerting.

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” with 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.

+1

From an order of magnitude perspective, the max is terabytes. No “normal” users are dealing with petabytes. And if you are dealing with petabytes, you’re not using some random poster’s program from reddit.

For a concrete cap, I’d say 256 tebibytes…

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.

Maybe.

Linux won because it worked. Hurd was stuck in research and development hell. They never were able to catch up.

However, Linus’s kernel was more elaborate than GNU Hurd, so it was incorporated.

Quite the opposite.

GNU Hurd was a microkernel, using lots of cutting edge research, and necessitating a lot of additional complexity in userspace. This complexity also made it very difficult to get good performance.

Linux, on the other hand, was just a bog standard Unix monolithic kernel. Once they got a libc working on it, most existing Unix userspace, including the GNU userspace, was easy to port.

Linux won because it was simple, not elaborate.

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.

What’s wrong with AC if it’s powered by renewable electricity?

Zsh

No plugin manager. Zsh has a builtin plugin system (autoload) and ships with most things you want (like Git integration).

My config: http://github.com/cbarrick/dotfiles

Exactly.

My take is that the issue isn’t with tmpfiles.d, but rather the decision to use it for creating home directories.

This is a good book on how Google treats production environments at their scale.

Cattle, not pets.

3…

Edit: I can only count to four

Google operates on a trunk model, according to this:

https://dev.to/tbodt/comment/1j4e

Is it bad practice to use rm -rf / to delete my files, or should I specify the path explicitly?

I’ve always used rm -rf / to delete my files, but I noticed that it also deletes a lot of other things. Is this bad?

Just put the site behind a cache, like Cloudflare, and set your cache control headers properly?

They mention that they are already using Cloudflare. I’m confused about what is actually causing the load. They don’t mention any technical details, but it does kinda sound like their cache control headers are not set properly. I’m too lazy to check for myself though…

Ok. So if you have the infra already, it’s really just a matter of actually writing the tests. That can be done incrementally.

40%-60% unit test coverage is honestly not too bad. But if the company’s bottom line rests on this code, you probably want to get that up. 100% though isn’t really worth it for application code, but it is definitely worth it for library code.

One thing where I work is that all commits must be reviewed before being merged. A great way to improve coverage is to be that guy when people send you PRs.

Wow 😲

It’s not that hard to setup GitHub or GitLab to make sure all the unit tests run for each PR.

If you use something else for version control, check if they offer a similar CI feature. If not, setup Jenkins.

I’m an SRE at a big tech company, so part of my job is to make sure CI infrastructure is readily available to our Dev partners. But I’ve worked at smaller companies before (10 or less SWEs) and even they had a Jenkins instance.

This is a bright red flag to me. If I worked for a company that didn’t have CI, the first thing I would do is set it up. If I wasn’t allowed to take the time required to do that, I would quit…