Probably could’ve mentioned at some point in that whole article that Albert Heijn is a supermarket chain: https://en.wikipedia.org/wiki/Albert_Heijn

In many cases, you don’t need an equivalent to finally, because the cleanup is automatically handled via the Drop trait, which runs cleanup code when the object is freed from memory (similar to “destructors” in some other languages).
Because of Rust’s whole ownership thingamabob, it’s generally entirely deterministic when this code will run (at the closing brace for the scope in which the object is defined, unless you pass that object outside of that scope).

In other cases, you don’t need a finally, because nothing forces you to bubble up errors instantly. You can make a call which fails, store the error in a variable, run your cleanup steps and then return the error at the end of you function.

Sometimes, however, you do want to bubble up errors right away (via ? or early return), typically so you can group them together and handle them all the same.
In that case, you can run the cleanup code in the calling function. If you don’t to want to make it the responsibility of the caller, then pull out a small function within your function, so that you become the caller of that small function and can do the cleanup steps at the end of your function, while you do the bubbling within the smaller function.
There’s also ways to make that less invasive via closures (which also serve as a boundary to which you can bubble errors), but those are somewhat complex in Rust, due to the whole ownership thingamabob.

I will say, I do sometimes feel like Rust could use a better way to handle doing something before the error bubbles up. But generally speaking, I don’t feel like a finally is missing.

You can use the anyhow crate for something quite similar to exceptions: https://crates.io/crates/anyhow

In terms of how it actually fits into Rust, you want to use anyhow for application code. If you’re writing a library, then anyhow is a no-go, because users cannot match on different error classes with it. (Much like you would want custom exception classes, so that users can catch them in different catch branches and handle them differently.)

Every so often, you will also need matchable error classes within your application code, then you would have to replace anyhow with a custom error type there, too, of course.

I will also say, IMHO it is fine to use anyhow even while you’re learning Rust. It is so easy that you kind of skip learning error handling, which you will need to learn at some point, but you can still do that when you actually need it.

I’m guessing, those people are worried that it will be removed. It’s already somewhat on the line since Wayland started replacing X11, because individual desktop environments can now decide to implement it or not.

Ah, I think, I know what you mean, that the format is supposed to be written with foolish oversimplifications that are borderline incorrect, whereas “secured by TLS” just sounds like a normal statement from an expert…

It’s mainly just a nicely polished app with rather many optional features and settings.

But well, at the end of the day, it does still just show a list of 6-digit-numbers, so it’s not revolutionarily different either…

I’m guessing that was supposed to be “secured by a thin layer of TLS”…

Yeah, have not heard about any of these problems before this post…

Back in 2010, the OpenOffice devs had to abandon that name for trademark reasons¹, so they renamed to LibreOffice and continued developing under that name.

OpenOffice theoretically also still exists, but it’s hardly getting updates. Unless you specifically like software from 2010 (including some security vulnerabilities, I believe), you want to use LibreOffice.

¹) The OpenOffice trademark was owned by Sun Microsystems, which got bought by Oracle. Oracle has a very bad reputation, so the devs did not care to wait around for Oracle to fuck everything up.

We deployed a client software in a Docker container on Windows 10. It could not connect to the backend, even though we saw SYN packages originating from it.
So, we ran WireShark on the Windows host and saw that the SYN-ACK packages from the backend were arriving there, too, but no ACK came through to complete the TCP handshake.

Eventually, we rolled out a network debugging container on that Windows host and then could see in the tcpdump, that the SYN-ACK packages, which arrived on the Windows host, just did not show up in the container. Hyper-V or something was quietly dropping them.

Other network connections were working fine, just the SYN-ACK from our backend triggered this.

Ah, I thought you mixed them up, because they both look Windows-y in their default configuration. 🙃

Mint doesn’t use KDE out of the box. They have an own DE called Cinnamon.

I have caught myself genuinely thinking that management needs to unearth more budget, if they so desperately want us to use these AI tools, so that we can onboard another person to compensate for the productivity hit.

Unfortunately, they believe the opposite to be true, that we just need to use AI tools and then our productivity will be through the roof…

I have not looked into these myself yet, but Apertus is supposed to be fully open: https://programming.dev/post/36791696

And I recently heard of StarCoder, which was also said to be like that and which is optimized for coding assistance: https://github.com/bigcode-project/starcoder

I also always find that outsourcing is risky, whether it’s to other devs or to some AI, because it requires that you understand the problem in whole upfront. In 99% of cases, when I’m implementing something myself, I will run into some edge case I had not considered before and where an important decision has to be made. And well, a junior or LLM is unlikely to see all these edge cases and to make larger decisions, that might affect the whole codebase.

I can try to spend more time upfront to come up with all these corner cases without starting on the implementation, but that quickly stops being economic, because it takes me more time than when I can look at the code.

I mean, for me, it’s also mostly a matter of us doing embedded(-adjacent) software dev. So far, my company would hardly ever choose one stack over another for performance/efficiency reasons. But yeah, maybe that is going to change in the future.

Large shared codebases never reflect a single design, but are always in some intermediate state between different software designs. How the codebase will hang together after an individual change is thus way more important than what ideal “north star” you’re driving towards.

Yeah, learned this the hard way. Came up with an architecture to strive for 1½ years ago. We shipped the last remaining refactorings two weeks ago. It has been a ride. Mostly a ride of perpetually being low-priority, because refactorings always are.

In retrospect, it would’ve likely been better to go for a half-assed architecture that requires less of a diff, while still enabling us to ship similar features. It’s not like the new architecture is a flawless fit either, after 1½ years of evolving requirements.

And ultimately, architecture needs to serve the team. What does not serve the team is 1½ years of architectural limbo.

I mean, don’t get me wrong, I also find startup time important, particularly with CLIs. But high memory usage slows down your application in other ways, too (not just other applications on the system). You will have more L1, L2 etc. cache misses. And the OS is more likely to page/swap out more of your memory onto the hard drive.

Of course, I don’t either sit in front of an application and can tell that it was a non-local NUMA memory access that caused a particular slowness, so I can understand not really being able to care for iterative improvements. But yeah, that is also why I quite like using an efficient stack outright. It just makes computers feel as fast as they should be, without me having to worry about it.

I don’t know what part of that is supposed to be an insult.

And the article may have talked of such stark differences, but I didn’t. I’m just saying that the resource usage is noticeably lower.

Yeah, you need to do tree-shaking with JavaScript to get rid of unused library code: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking

I would expect larger corporate projects to do so. It is something that one needs to know about and configure, but if one senior webdev works on a project, they’ll set it up pretty quickly.