I can strongly recommend lazy loading in zsh in general, I use it for pyenv too (which is also slow to load, but I write Python maybe every other week or so only).

The way to do this is to use the autoload functionality in zsh and have the autoloaded script replace itself with the real shell init code for the tool in question.

Maybe this is not the case if you are doing a dozen throwaway websites, but for anything serious that is an absolute requirement. I work in hard realtime safety critical code, think things like brake controllers, medical devices, auto pilots, etc. In my case industrial control systems. You need to have full control and documentation for your development process.

But I often do think across adjacent abstraction levels, because abstractions are (varying levels of) leaky. Modern compilers are after many decades good enough and modern computers fast enough that it is rare that I need to dig into the assembly (but I happens, compiler explorer is in my bookmark bar in Firefox).

Other abstractions are far leakier, it is far more common that I look in wireshark to debug network issues, the application level view is often not enough.

One of the leakiest abstractions currently is LLMs. Maybe in a decade or three they will be good enough, but they aren't yet, that's for sure. At least for the hard realtime systems level programming I do. For code generation they often make enough mistakes that the time spent after review and fixes comes out in the wash, even for simple tools. Their use for bug finding, RAG and similar is however promising.

Because of things like acceleration and flow limits the scaling isn't as simple as a constant factor but also depends on the geometry of the part (sharp corners lead to slowing down) and material (check max volumetric flow in your slicer, will likely be set way too low for your current filament profiles, especially if you switch to a high flow nozzle on the nextruder).

The Mk3.9 probably isn't a price competitive upgrade though, today I would in your position probably look at selling the Mk3s for 100-200 EUR and buying a Core One instead. But if the Mk3s works for what you are doing, then don't bother. (The Mk3.5 might make some sense if you only want a bit higher speed and network connectivity.)

Personally I don't see myself replacing the Mk3.9s for a long time, though an enclosed printer would be nice and let me print warp-prone materials like PC and ASA.

https://www.printables.com/search/models?q=drybox shows plenty of fancier alternatives as well.

EDIT: See also https://www.printables.com/search/models?q=drybox for plenty of more fancy alternatives, including some for mounting on top of the printer.

(Also, what did Snapmaker do? I thought they were relatively innocuous?)

Snapmaker (also Chinese) seem to be doing things better at the moment, but only time will tell how the serviceability is.

For me personally, the only viable choices today would be a Prusa Core One (possibly with INDX for multi-material, I don't care about MMU/AMS, those are just for multi-colour and with a lot of waste) or a Voron 2.4. My Prusa Mk3.9s bedslinger is still going strong though, and I don't expect to replace it any time soon.

I have heard good things about the Snapmaker U1 that just released, though apparently the slicer software isn't quite there yet, but you could just run stock OrcaSlicer instead.

Time will tell how reliable and more importantly serviceable the Snapmaker is. Prusas are renowned for both of those.

[1] https://github.com/ajayyy/SponsorBlock

(It is worth noting that at least in Sweden "published" here has a very specific meaning, that doesn't include personal websites etc, but it does include news outlets.)

The fallout of this are quite large! If behaviour is implementation defined the compiler has to stick to one consistent behaviour. No such need for UB, you can get different behaviour bu changing unrelated code, by changing between debug and release or just because of what garbage happened to be on the stack.

Since the compiler is allowed to assume the UB doesn't happen it will also sometimes look like the compiler miscompiled your code elsewhere, but what actually happened was some inlining followed by extrapolating "this can never happen".

UB is often surprising: I have seen unaligned loads crash on x86 due to it bring UB in C (even though x86 is generally fine with it). But once a newer compiler decided that it was fine to vectorise that code (since it clearly aligned) the CPU was no longer happy with it.

Interesting study though and I wonder if it has at all improved since.