What is special is one time it was a one way lane next to the tram with a concrete stub down. I wouldn't be surprised if the anti-collision kicked in and applied lane assist even with the blinker.

At any rate, the principle of least surprise still applies: heavy machinery must not jerk unexpectedly to the side. Never ever ever.

Any dangerous machine (like a car) must not do anything unexpected out of the driver's control. A lane assist that resists the wheel when trying to get out? Why not, but dangerous. A lane assist that slam you back in the lane? Criminal. (same with anti-collision braking that triggers too strong too early and surprises drivers behind you)

I'm definitely of the opinion that all those features reduce security. The alarm fatigue is real, because the car always finds something to beep at you. Heck, even your hands not being a perfect 10-2 o'clock on the wheel is reason enough on some cars. You quickly ignore the beeps because there are so many reasons for the car to beep it's hard to even understand why.

Still, it pains me to see that practices from the early keylogger era are still "good practices".

Banks are notorious for taking security as a strict cost/savings measure. I would not be surprised if they enforce weak passwords stored in cleartext on purpose to save on support agents for the people that forget/lose their password. Imagine the customer service reviews: "they were able to find my password back, 5/5". Probably enough savings to offset the cost of refunding people that got their account pwnd. Cost of doing business.

I think the worst I ever had was HSBC that asked me for fragments of my password, like characters 4, 6, 7, 11, and 12. Absolute bonkers of a security theatre.

They all are little snowflakes. Compatibility is hit-or-miss. They run hot. They eat more power. They're finnicky. Heck, they plain out lie about what they are (I've got some that pretend to be fibre with 3m of copper, sure).

So yeah, DAC it is for patch, fibre for anything more.

And mind you, that's on a small 4 core VM on 2019 mid-range Xeons, which I would not consider to be a huge amount of compute (granted, not Raspberry Pi level, but I'd expect the SD card to be much more of an issue).

So yeah, along with the sane(r) way to do CI pipelines, and usable review tools, it's a net improvement over GitHub.

At my previous job, I've written production eBPF exclusively in Rust using Aya (mentioned by a sibling comment), and it's been a blast. Being able to share the type definitions between the kernel-space and the user-space code is a blessing to avoid subtle issues when going through the maps. And, at least in Rust, you can re-use crates and types that make you gain time. As a (simple) example, being able to use the standard library's IpAddr types or the ipnet crate to not have to roll your own IP and network manipulation libraries is a (small) timesave. It's main value is not needing to onboard new developers.

The Rust type system is a good helper in keeping the verifier happy. Slices, iterators, match statements, etc are very good in my experience (e.g. Option is a godsend to ensure you stay withing the bounds of the input packet, esp. slice::split_at when parsing headers).

But you're right that reading C is non-negotiatable, especially since pretty much all example code on the internet is in C.

As for error handling, this kind of enrichment is usually left to the caller (that is, the end application), with error libraries like anyhow where you can add arbitrary string contexts to an error. You would end up writing `Config::load(path).with_context(|| format!("Failed to load configuration file {path}"))?`.

In a nutshell, the LLM created abstractions that allow you to write unsound code in safe rust, which is squarely against the language.

To be specific: the abstraction takes a (shared) reference and uses unsafe to wrap it in an owned object, completely erasing le lifetime. In practice, this means users of the abstraction think they own the underlying memory: they choose when to free it. However, it just wraps a pointer that’s owned by someone else (it was a shared reference, remember?), thus it will be freed when you don’t expect it.

So why does it not exist in Zig: it’s a false contract about what it is. The Zig pointer is a pointer with no added lifetime information. You can hold a Zig pointer wrong, but you will hold a lying abstraction wrong. You will misuse it because it doesn’t do what’s written on the tin. You will write bugs with it.

And, LLMs will too. If they do not have the abstraction definition in their context, they also have no way to know the contract is lying.

If you meant they’re now better at mimicking compilers, sure, but they’re only mimicks.

Compilers are mechanical and engineered to produce a correct output. A compiler emitting incorrect machine code is exceedingly rare, and considered a bug. They have heuristics and probabilities in them, but those are to pick between a set of known-good outputs.

An AI is a bag of weights outputting a probability of the most plausible token that follows [1]. It is inherently probabilistic in nature and its output is organic (by design, they’re designed to mimic human speech), as opposed to mechanical like a compiler.

A compiler follows hard rules. An AI does its best.

And to be fair, AIs are no better than human in this regard: humans are pretty bad at generating correct code without mechanical tools to keep them in line (compilers, linters, formatters). It’s not a wonder we use the same tools to keep LLM output in line as we do humans. (And, to be fair, LLMs are better than humans at oneshotting valid code).

[1]: to those that tell me this vision of an LLM is outdated: nope. The heavy lifting is done in the probability generation. Debates about understanding are not relevant here, and the net output of an LLM is a probability vector over raw tokens. This basic description can be contrasted to a compiler whose output is a glorified Jinja template.

Oh well, just like caps lock can be remapped, so can my keycaps be swapped (perks of blank keyboards I guess), though it'd be even harder to use a keyboard that's not mine I guess.

I somewhat get the argument, but if you're writing code in the HN textarea you're doing something wrong (for code where tab/space matters anyways). Like, any code editor will use the tab key properly.

Though, it sills maddens me there's no somewhat universal tab-entry in OSes like we have with enter (somewhat because there's a mix of shift+enter, alt+enter and cmd+enter). All of shift/alt/ctrl tab are usually also hijacked.