They should be keeping them in something like kwallet. But in practice they don't because a) there isn't really a single standard for that on Linux (yeay, I have to support gnome-keyring too!), b) it's a lot more work than using a plain text file, c) the UX is considerably worse, and d) the security benefits are marginal at best (especially if you have full disk encryption).

Plain text is the most sensible option.

They're released on a schedule so they are often quite boring.

I don't think there were any standards for this sort of thing when Flatpak and Snaps first came out, and they arrived at the same time and have pretty big differences. So this doesn't apply.

pointing and saying “this is shit. Look at this shit”

Yeah you only get to do that if you're Linus 😄

Its definitely best to try and avoid raw pointers, but even if you try really hard I found it's not really possible to get a Rust-like experience with no UB.

Even something as simple as std::optional - you can easily forget to check it has a value and then boom, UB.

The C++ committee still have the attitude that programmers are capable of avoiding UB if they simply document it, and therefore they can omit all sanity checks. std::optional could easily have thrown an exception rather than UB but they think programmers are perfect and will never make that mistake. There are similar wild decisions with more recent features like coroutines.

They somehow haven't even learnt the very old lesson "safe by default".

If I wanted memory unsafety I think I would consider Zig instead of C++ at this point.

TOML is not a very good format IMO. It's fine for very simple config structures, but as soon as you have any level of nesting at all it becomes an unobvious mess. Worse than YAML even.

What is this even?

[[fruits]]
name = "apple"

[fruits.physical]
color = "red"
shape = "round"

[[fruits.varieties]]
name = "red delicious"

[[fruits.varieties]]
name = "granny smith"

[[fruits]]
name = "banana"

[[fruits.varieties]]
name = "plantain"

That's an example from the docs, and I have literally no idea what structure it makes. Compare to the JSON which is far more obvious:

{
  "fruits": [
    {
      "name": "apple",
      "physical": {
        "color": "red",
        "shape": "round"
      },
      "varieties": [
        { "name": "red delicious" },
        { "name": "granny smith" }
      ]
    },
    {
      "name": "banana",
      "varieties": [
        { "name": "plantain" }
      ]
    }
  ]
}

The fact that they have to explain the structure by showing you the corresponding JSON says a lot.

JSON5 is much better IMO. Unfortunately it isn't as popular and doesn't have as much ecosystem support.

I use this big expensive simulator called Questa, and if there's an error during the simulation it prints Errors: 1, Warnings: 0 and then exits with EXIT_SUCCESS (0)! I tried to convince them that this is wrong but they're like "but it successfully simulated the error". 🤦🏻‍♂️

We end up parsing the output which is very dumb but also seems to be industry standard in the silicon industry unfortunately (hardware people are not very good at software engineering).

uv is fantastic. I would highly recommend it. I've used it in a quite complex environment, with no issues (quite an achievement!) and it's about 10x faster than pip.

I mean... I guess it's not surprising given uv is written in Rust and pip is written in Python, but even so given pip is surely IO bound I was expecting something like 4x improvement. 10x is impressive.

TL;DR (there should be an open source drama summarising website!):

• Hazing someone in your discord because they have pronouns in their bio
• Speaking pretty bluntly against queer people and minorities at large
  • "at 15 he doesnt even know what he will be studying at uni and he already wanna go get AIDS?"
  • "I think this server's motto should be 'love guns, hate damn minorities'"

They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.

No they aren't. A higher version of UUID isn't "newer and better", like the word "version" implies. It's just different. It's like they called a car "vehicle version 1" and a motorbike "vehicle version 2". The common use of "version" in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.

The talking pumpkin is 100% right that they should have used "type" or "mode" or "scheme" or something instead.

Yeah I think it's trauma due to C/C++'s awful warning system, where you need a gazillion warnings for all the flaws in the language but because there are a gazillion of them and some are quite noisy and false positives prone, it's extremely common to ignore them. Even worse, even the deadly no-brainer ones (e.g. not returning something from a function that says it will) tend to be off by default, which means it is common to release code that triggers some warnings.

Finally C/C++ doesn't have a good packaging story so you'll pretty much always see warnings from third party code in your compilations, leading you to ignore warnings even more.

Based on that, it's very easy to see why the Go people said "no warnings!". An unused variable should definitely be at least a warning so they have no choice but to make it an error.

I think Rust has proven that it was the wrong decision though. When you have proper packaging support (as Go does), it's trivial to suppress warnings in third party code, and so people don't ignore warnings. Also it's a modern language so you don't need to warn for the mistakes the language made (like case fall through, octal literals) because hopefully you didn't make any (or at least as many).

Saving this for when people try to claim that naming things isn't important!

Also that is clearly a security issue. Anyone who tries to claim otherwise is forgetting that humans exist. Though I suspect they were just trying to avoid admitting fault and doing work. Disappointing either way.