syklemil

I generally agree, but

1. People who haven't used a package before likely aren't interested in release candidates.
2. Axum is one of the few pretty well-known Rust libraries. I'm willing to give that a pass on describing what it is for an RC, much like I'd do the same for FastAPI in a Python community. (But a little default blurb about what they are would be nice anyway to people who are new to the language and/or ecosystem.)

Yeah, that's the correctness focus. Some people dislike it as a straitjacket, some even take it as a personal insult because they see it as a skill issue. They, the good devs, shouldn't be held back like that (spoiler: they aren't as good as they think they are).

Personally I like that aspect of Rust, but I also write Python with a typechecker and a loong list of enabled lints in ruff. I can get the happy path done without it, but having just the happy path often isn't good enough.

Enforced correctness helps a lot with confidence for those of us who know we sometimes make bad assumptions or forget some nuance or detail. But it will be absolutely infuriating for people who can't stand being told they made an error, even one of omission.

Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with "I'm tired of paying for an ABI stability I'm not using" it's not so clear it would really be a boon to Rust.

That said no_std appears to be what people go to for the lean Rust.

And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It's part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it.

The serious answer here likely has several components:

1. Some people and businesses have invested a lot in languages that governments are now trying to deprecate. When someone is told that their assets may be stranding, and please move on to $NEWTHING, they're likely to get … grumpy. Both they and the government may be correct here, even if they're at odds—they have different scopes and concerns.
2. Differing values. See e.g. Cantrill's "Platform as a reflection of values".

• Rust highly values correctness, which will feel like a straitjacket to a lot of people.
• It also moves as much error detection as it can to the compilation stage, which won't sit well with people who want to get something out the door ASAP and then find the bugs as they happen.
• So it also encourages tackling complexity early rather than kicking the can down the road, which again isn't to everyone's preference.

Socks were invented to be used in sandals, it's the one true way!

(Typed wearing big woolen socks in birkenstocks)

I think I wouldn't find it particularly useful, as I'm used to the quasi-programming I can do in a terminal. The shell commands take some time & effort to learn, but once you're over that hump, being able to extract and compose information is really good. The primary shell tools I'd miss in a gui are |, jq, awk, sed and grep/rg, as well as for, if, while, variables, and having everything in one lightweight window.

Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn't grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.

I also have a sysadmin/devops/sre type career, and my impression is rather the opposite: With systemd Linux became a lot cleaner and predictable, compared to the mess of shell scripts we had before. There's never been anything clean or well-architected about shell scripts, they've always been a messy collection of not-quite-the-same languages that have all safeguards turned off by default, and it's up to the programmer to turn them on and hope they actually work. Good for one-shots and exploration in the terminal, though.

I also don't miss logrotate or finding out that some app places its logs somewhere mystical. Being able to read app logs just by knowing the service name is wonderful, as are the timestamp and boot arguments.

systemd didn't appear as just one guy's brain child, nor could it rise to the dominance it has if the way it works was as controversial or bad as it is in your opinion.

I haven't been on-call for the past few years, but my impression is that there have been fewer and fewer on-call events over my career. That's also largely on app developers and a shift to Kubernetes, but it's a generally pleasant change. There's nothing I hate more than being woken up.

And even with a "please keep your feet on the floor" sign right next to them.

I mean, the fact that more than half-century-old COBOL continues to be maintained does speak to the fact that it is maintainable. That might also be part of what makes COBOL painful to the average developer: You're not only dealing with a language that first appeared in 1959, designed for machines that were very different than modern computers; you're also dealing with over a half century of legacy code, including all that means for Hyrum's law.

Unfortunately maintainable and pleasant to work with are rather distinct concepts.

I also find that calling systemd "SystemD" is a tell that someone is unfamiliar with or has a conspiratorial relationship to it. It's named "systemd", all lowercase (but I'm likely to capitalize it on sentence starts like a normal word). Using an ungrammatical uppercase D at the end of the word, that isn't even something the creators claim is correct, is … a choice.

(And it's a choice that reminds me of e.g. how rabid anti-cyclists in Norwegian can't even spell "cyclist" correctly, but instead consistently use "bicycleist".)

The part is constructed from two parts:

1. ls: list
2. usb: usb

It lists usb devices that your machine (/kernel) knows has been connected; they may not necessarily be usable.

E.g. I have some sound output device connected via USB to one machine. On most of my machines I've switched from pulseaudio to pipewire¹, and I figured I'd bring that machine closer to the others so there's less variance. Unfortunately the sound output device didn't want to work with pipewire. The problem manifested as no sound and pipewire not listing the device. lsusb helped me know that the machine at the very least recognized the device, but wasn't currently able to use it. (It did actually also show up as an error in dmesg -H, but reinstating pulseaudio let the device work again as normally. So now I just have to live with a situation where some machines use pipewire because ~bluetooth~ and others use pulseaudio because … usb?¹)

¹ There's a memory of ALSA vs OSS I didn't want to be reminded of

Eevee's heteroglot entry for COBOL is interesting, coming from … practically anything else.

There's also someone doing AOC in ABAP (basically SAP COBOL) who posts over in the AOC subreddit. I've looked at them and ... mhm, I know some of these words!