Okay, dude, glad to have talked.

Having to make a decision isn’t my primary issue here (even though it can also be problematic, when you need to serialize domain-specific data for which you’re no expert). My issue is rather in that you have to write this decision down, so that it can be used for deserializing again. This just makes XML serialization code significantly more complex than JSON serialization code. Both in terms of the code becoming harder to understand, but also just lines of code needed.
I’ve somewhat come to expect less than a handful lines of code for serializing an object from memory into a file. If you do that with XML, it will just slap everything into child nodes, which may be fine, but might also not be.

Ah, well, as far as XML is concerned, yeah, these are very different things, but that’s where the problem stems from. In your programming language, you don’t have two variants. You just have (person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether “name” and “age” are one or the other.

And the point I wanted to make, which perhaps didn’t come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.
And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.

Granted, Rust kind of lends itself to being serialized as JSON, but well, I’m just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I’m aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.html
But even in Scala, you don’t use a case class for XML, which is what you normally use for data records in the language, but rather you would take the values out of your case class and stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it’s still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.html

Alright, I haven’t really looked into XML specifications so far. But I also have to say that needing a specification to consistently serialize and deserialize data isn’t great either.

And yes, JSON not having attributes is what I’m saying is a good thing, at least for most data serialization use-cases, since programming languages do not typically have such attributes on their data type fields either.

IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:

(person (name "Alice") (age 30))
[is serialized as]

<person>
  <name>Alice</name>
  <age>30</age>
</person>

Or with attributes:
<person name="Alice" age="30" />

The same data can be portrayed in two different ways. Whenever you serialize or deserialize data, you need to decide whether to read/write values from/to child nodes or attributes.

That’s because XML is a markup language. It’s great for typing up documents, e.g. to describe a user interface. It was not designed for taking programmatic data and serializing that out.

There is JSONPath, at least: https://en.wikipedia.org/wiki/JSONPath

Terraform is proprietary. You want to the use the OpenTofu fork instead: https://opentofu.org/

Hmm, they might’ve scrambled to add Recall et al, because those other features you named don’t particularly need to be offloaded. Except for maybe TTS, you’re not gonna run these in the background all the time. And if you need the occasional translation, it’s fine, if it takes a bit longer.

At least, I would’ve absolutely seen headlines à la “Microslop wants you to buy an expensive new PC – to do things your current PC can perfectly fine”.

Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.

Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they’re working on, that can help, depending on your team’s specific needs.

At its core, SystemD coordinates and launches all the services in your operating system. So, it is essential for the boot process, but also does scheduling, meaning you could run a backup script every night with it, for example.

That’s the simple answer. But in truth, SystemD is often criticized for doing too much, so it’s hard to describe what it really does. For example, you can also manage network interfaces via SystemD.

Kind of the goal of SystemD is to provide common plumbing which works the same across distros, so that when you configure your services or network interfaces etc. on Ubuntu, it works the same as on openSUSE or Arch or whatever.

Gotta love Linux newbies talking about their first experiences and they’ve already tried 3 distros that I have barely on my radar. A few months in, I hardly knew what SystemD was and this guy’s already on a distro that explicitly removes it.

If you prepare an installation USB stick, so-called “Live-USB”, and select in the BIOS that it should boot from that, then you can test-drive Linux before you install it.

There is more details involved, like you may need to turn off Secure Boot in the BIOS, but yeah, point is, you don’t have to commit to Linux to try it.

I’m guessing, you mean this then: https://github.com/edc/bass

But well, I was rather thinking of when it’s using Bash-scripting-syntax to combine multiple commands.
Like, maybe there’s a for-loop in there. You just can’t paste that directly into Fish and have it work. Granted, you should probably put that into a script file, even if you’re using Bash, but yeah, just temporarily launching bash is also an option.

I have that occasionally when I want to copy a complex bash command from somewhere. But yeah, I can then just run bash, run the command in there and then exit back out of there.

It still gives you basically no advantage compared to just making your terminal emulator launch fish by default. And well, it does give you the major disadvantage that scripts without shebang will fail.

To me, it genuinely makes a huge difference that I don’t have to manually press Ctrl+R for history search. Because 9 times out of 10, I accept a history suggestion from Fish where I did not think about whether it would be in my history.

This includes really mundane commands, like cd some/deeply/nested/path/. You would not believe, how often I want to cd into the same directory.
But I’ve also had it where I started typing a complicated docker run command and Fish suggests the exact command I want to write, because apparently I already ran that exact command months ago and simply forgot.

Yeah, my current software project at work was basically half a year of feature development and since then, we’ve purely tried to get it into the real world, which meant evaluating use-cases to see where it falls flat and what needs stabilizing, as well as figuring out people’s needs and how our software can assist with that, then setting up a demo and hoping they find money somewhere…

My problem was that “Albert Heijn” is a dude’s name. It does not exactly scream “we’re talking about a real physical building”.

For all I knew, the impossible problem we’re solving could’ve been on a mathematical plane, named after mathematician Albert Heijn. “Sweeping” just as well can be used in an abstract sense.

Obviously, I did think of physically sweeping a physical floor first and foremost, but especially with the rest of the blog post being so entirely abstract, I had doubts on that for far too long, which did not make it easier to understand.

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.