Worst part is, at some point in my life, I believed there to be a correlation between words read and information acquired. I do not believe that anymore. You give that LLM three points to cover and the instruction to fill a whole page, of course it’s going to pad with as much dead air as possible.

Oh man, I lightly skimmed the comic before deciding to read and I was convinced the joke would be that the bride doesn’t want her husband-to-be to look at the bridesmaid’s cleavage, so that’s why she should hold the flowers. 🫠

I’d say technically it’s Rust, because you can do everything from embedded/kernel development to web frontends (via WebAssembly).

I do like the versatility, but I agree with what has already been commented, that you shouldn’t worry about this yet.
Newbie programmers always consider it a daunting task to learn a new language and then you’re a few years in and just inhale a new language on a weekend for fun.

And when I say fun, I do mean that it’s actually educational to learn multiple languages. They emphasize different concepts, which gives you a new perspective and new patterns for solving problems.

As a Rust dev, I approve of this.

(Especially the rewriting. Spacetime has way too many quirks and should be deprecated.)

I mean, just to offer you the counter perspective, IMHO programs written in X tend to have problem Y:

• Python: Terrible error messages, buggy, sluggish, slow, but good documentation
• Java: Gurgles RAM like there’s no tomorrow (but tends to do something useful with it), sluggish
• Node.js: Just gurgles RAM for the fun of it, buggy, over-engineered functionality, confusing documentation
• Rust: Over-engineered functionality
• Go: Bad error messages, quirky detail behavior
• Haskell: Practically 0 bugs, but if you do run into a bug, good luck. Thin documentation.
• C/C++: Basically no bells or whistles, and no compiled build available. Also stupidly difficult compile on anything, except the singular dev’s PC.

Obviously, these are caricatures, i.e. I’m overdrawing the details and omitting nuance. And these are also influenced by the kind of people that are drawn to these languages. And these are influenced by what I know about the languages, I didn’t conduct a double-blind study.

But yeah, there’s a reason why Python ended up first on that list. I don’t have that hard of an opinion about the others, but genuinely, when I know a non-trivial program is written in Python, I will think twice whether I want to use it. Because it always seems to cost me a non-trivial amount of nerves in the end.

Oh, hmm, the release notes say that it should be out: https://github.com/streetcomplete/StreetComplete/releases/tag/v64.0

Maybe I’m dumb then. 😅
Someone else already posted in this community a week ago, that it was in TestFlight. But well, at least it reached one more person, so that’s something. 🙃

When they first started doing these tests unannounced, our IT department got a horrendous failure rate and then management had to announce that if we recognize it as a phishing simulation, we should still report it, and we also shouldn’t start poking around in the supposed phishing links. 😅

So, I’m not actually that deep into audio, but I believe, you need to do this: https://superuser.com/a/1827716

Direct link to the Wiki as well, in case superuser.com evaporates: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Virtual-Devices#combine-source-selected-channels-and-sources

So, this will create a virtual audio device. And I’m guessing, you’ll then be able to select that as your microphone of choice in KDE’s sound settings.

What I’ve realized is that because of the hype, you’ve virtually always got investors willing to offer a service for free, in hopes of attracting users.
Which means, if that service then tries to make that money back, users will quickly find another free offering and switch to that instead.

Obviously, in theory, you might manage to offer such a unique service that folks won’t find a competing service, but:

1. a lot of these AI services do the same shit, because it is just language models and image models at the end of the day, and
2. if you can quickly build that service then others can quickly build it, too, so if people are willing to spend money on your offering, you won’t need to wait for competitors.

This is a very different situation than a gold rush, and yet it feels ever more appropriate when folks say only those who sell shovels earn money from it…

I did have the same misreading. And I should in fact visit an optometrist…

So, I’m actually able to reproduce that and then had to fix it myself. 😅

The “Pro Audio” profile seems to be a PipeWire thing: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-is-the-pro-audio-profile

I’m guessing, the recording device doesn’t like that profile and just crashes right away. And when it has crashed, it won’t show up in the list of available devices.

Now, how is that profile remembered even when the device disconnects? Apparently, a component called “WirePlumber” is responsible for that.
And it stores this information in: ~/.local/state/wireplumber/default-profile

If you don’t mind losing your profile selection for other devices, you can just do:

mv ~/.local/state/wireplumber/default-profile ~/.local/state/wireplumber/default-profile.old

and then do a reboot.
After the reboot, your recording device should be back.

If you do mind losing the other profiles, then make a backup of that file and try to remove lines related to your recording device, and again do a reboot to test it.
For me, it was a device which had both input and output, and I had to remove both lines before it recognized it as unconfigured.

Because they take away tons of libraries I normally use.
For example, for querying low-level system information (like I imagine you need to do a lot in systemd), I’d normally use the nix library. If I can’t do that, I have to use libc directly. Well, and write a wrapper for it, if they don’t already have one.

So, I don’t want to say it would be extremely hard, but it would still mean learning a different way of doing things…

Functional programming is definitely worth a look in this regard as well, but what really drove this home for me is Rust.

Its ownership+borrowing concept is exactly that, it enforces that you’ve got one place where an object is managed and in particular mutating can only be done in at most one place.
Obviously, there’s also ways to get out of that, in case you do want some memory managed centrally, but it just isn’t the default.

Yeah, in detail, they use or can use:

• Syntax + tooling for it, like editors, linters, formatters
• Compiler (rustc, which enforces memory+thread-safety for the parts not implemented in C)

They’ve replaced:

• std library → core library + their own implementation of types that do memory allocations, so in particular dynamically-sized types like lists and strings
• Cargo → their own Meson definitions

What they don’t use:

• the library ecosystem of Rust (although apparently they’ve got own implementations of “logging, command-line argument handling, event processing, and error management”)

It does sound like someone thought about this stuff, but yeah, as a Rust dev, it also sounds like I would struggle…

Fair enough, I guess.
Personally, I don’t really see the point, because there’s hardly any projects that can be compiled with just rustc.

I mean, cargo is actually surprisingly useful for normal users, because there’s a decent chance you can compile medium-sized Rust projects without having to jump through endless hoops.

But yeah, at that point, you’re adding a nontrivial number of megabytes to user installations for something they might not use. I would guess that even just rustc is larger than gcc and clang, since it implements more sophisticated logic…

Kind of weird how GRUB is “BURG” backwards…

This is about the official systemd repository. They use a mono-repo-approach, where all the official components are in one repository and use the same build system, so adding a second language into that is a bigger hurdle.

If you develop a third-party tool that somehow hooks into systemd, then you can use whatever language you want.

Firefox and Python’s cryptography toolchain have a build dependency on Rust, which are two packages that virtually all Linux distributions have packaged. So, some version of the Rust compiler is going to be available on virtually all Linux distributions.

There’s no real reason to have the Rust compiler installed on non-dev systems, as you don’t need it for running Rust programs (although I kind of assume you know this).
But yeah, it seems to be possible to dynamically link the standard library into Rust programs, so Linux distros could try to share that between them, and then it would effectively be installed by default.

Those are some wild restrictions. You’re using the syntax and presumably compiler (rustc), but almost nothing else from Rust…

Moreso correctness, not security. In the end, your user is shooting themselves in their foot, if they mutate a variable that they shouldn’t, and by making the variable private and only offering a getter, we document that.

Having said that, there’s also big differences between languages and paradigms, though.
In object-oriented / garbage-collected languages, you often pass around references to an object into so many places that you need to code defensively versus your own codebase. That’s why getters/setters were taught religiously during the height of OOP.

In other paradigms, you often just have one place that uses an object and then you can …simply not shoot yourself in the foot there. When you control both the definition and the access, you don’t need to protect yourself from yourself. In particular, you would probably think twice before mutating an object anyways.