You can’t do both in a single session, because LLMs will write weaksauce tests to make its code look good.

It works better if you start a new session and give it a goal to find bugs in the code and prove that via tests.

score 1 · canonical

I doubt that the causality is that simple. 80’s and 90’s saw explosion of underground music that succeeded despite lack of access to record labels and professional studios. There were multiple genres of music created by amateurs playing with 2nd-hand synthesizers. Meanwhile there was a lot of mass-produced pop, you just don’t remember more than the top few, because it wasn’t memorable!

score 1 · canonical

It’s also amusing that float to int conversion in C is UB on overflow. It’s actually exploitable in LLVM. Rust had to inject range clamping into its float casts to prevent it.

score 1 · canonical

I suspect frontier labs see harnesses as just an LLM-to-bash adapter. You won’t see smart harness features from them, because everything a harness could help with, they hope to RL-train into their next model.

score 1 · canonical

Code can be art, but most code exists only to solve a problem.

Paint can be used to create an artwork, but most paint in the world is used for weatherproofing and uncreative solid surfaces.

score 5 · canonical

We’re on a programming forum, so it’s a given that people here care about the craft itself.

But there are people who don’t want to program. To them software is just a hassle standing between them and their goal.

That’s normal. Not everyone wants to cook fine cuisine, many people get fast food. Not everyone wants to make custom furniture from the finest oak, plenty are happy with IKEA, etc.

And now software is moving beyond artisanal passionately crafted projects, and machine-extruded code nuggets are on the menu.

score 1 · canonical

Open Source became annoying for maintainers, but ironically agentic coding made it awesome for end users. For non-programmers, the benefits of open source used to be mostly indirect and/or theoretical, because they couldn’t actually modify the software themselves (learning to program is a major investment of time and effort, and a big barrier when someone just wants to avoid a bug or tweak a feature). But now users can say “Claude, fix it” and it tends to work well enough for a single user.

score 1 · canonical

There is no programming language that can’t have bugs, so such argument doesn’t state anything useful. It’s an empty truism.

OTOH the whataboutist/defeatist responses create a false equivalence. Even though both languages may have bugs: (P(bug | C) > 0) == (P(bug | Rust) > 0) stating it that way obscures the major difference in likelihood of the bugs: P(bug | C) >> P(bug | Rust).

score 1 · canonical

It’s really really hard to make an off-by-one error in Rust that turns it into a JIT or scripting language.

When a language has an API for executing arbitrary code, misuse of that API leads to arbitrary code execution, duh. That still fits under “the danger is roughly limited to what the code is supposed to do”. But you’re missing the point that in C you don’t need an API for RCE get RCE. In C you have a much larger problem of memory unsafety and UB turning potentially any API into an arbitrary code execution gadget.

score 1 · canonical

The platform is often all-or-nothing, so when the built-in behavior isn’t perfect - in all browsers - the devs are forced to reinvent the thing from scratch. The date picker is most hopeless of them all. Sometimes it’s due to some detail, like a weird line-height or small tap area, or animation that is too fast/slow/not in sync with some custom element.

I also expect that devs who got burned by some buggy or non-customizable detail don’t even try to use the platform next time, and go for having full control from the start to avoid disappointments later.

score 1 · canonical

I’d expect #[inline] on Ord and Eq, maybe Clone, but having it on Debug is surprising. I put #[cold] on my fn fmt implementations!

score 2 · canonical

1. Unsafe languages need to deal with all the same high-level bugs (like access control or SQL injection) in addition to memory safety bugs. C is not trading memory unsafety for some other safety, it’s strictly more unsafe. Rust does a lot to prevent logic bugs, e.g. error handling can be enforced by the compiler, while C can’t even decide whether returning 0 means OK or false.

2. Memory unsafety vulnerabilities are exceptional in their unbound scope and severity.

Without arbitrary code execution, the danger is roughly limited to what the code is supposed to do, and plenty of programs have lots of boring code that doesn’t touch anything sensitive. Even if you’re implementing access control, the worst case without RCE is failing open on that endpoint, rather than enabling installation of a rootkit or such.

A memory-safe JSON parser can at worst give you garbage data or heat your CPU or eat your RAM, but it won’t run arbitrary attacker-supplied code. If you’re implementing a widget that queries the current weather, the the worst case is not getting the weather info. In C, the worst case is getting the whole system pwned through a weather info widget. It’s a massive difference in the attack surface.

score 2 · canonical

The explanation why the macro is necessary seems tautological - certain syntax won’t work without the macro or macro-equivalent sugar, because it requires the macro. But why!?

I presume the macro has been invented as a hack to prototype the feature, and now the implementation is stuck with it, but what’s the theoretical type system problem that prevents a clean hack-less implementation?

And why isn’t existing {} or const {} sufficient? I thought this syntax has been reserved for const-evaluated values in types.

score 1 · canonical

I’ve had to rename new() to empty_object_reset_to_zero() to stop clankers calling Context::new() whenever they needed one.

But sometimes they don’t get the hint and diligently document // Instantiate StupidHack with shitty_workaround_deleteme()

score 1 · canonical

I understand that. But it matters whether the ideal implementation will end up being 5x or 2x or 1.2x slower than the unsafe baseline. The farther it is from 1x the more alternative solutions are available.

score 1 · canonical

An overflow-checking zalloc and hardened allocator is a good idea, regardless of the rest of the solution. It’s also cheap to implement with plain old unsafe C pointers.

However, I don’t think the speed overhead, and code changes required can be completely handwaved. In the end it has to win over other solutions, like compiling to WASM+WASI, or running with LLVM sanitizers.

score 3 · canonical

There’s probably a bunch of startups being created for this now, if there aren’t such already.

If it becomes a major problem, maybe there will be a GDPR-like legislation that gives a right to purge domain’s history.

score 1 · canonical

I think it’s more because of how it works: it’s an autocomplete based on previous tokens, so when adding text after an answer, it already has it as a reference and it influences the prediction. Not that it causes itself to emulate humans explaining themselves, but rather that there are already topics and statements to talk about.

score 2 · canonical

M4 is awful and needs to be buried. Macros are useful as a concept, but M4’s take has no redeeming qualities. Whatever DIY thing you invent in 5 minutes is likely to be more intuitive and less fragile.

Unix has so much crappy stuff that got in 40 years ago on a whim, and we just keep rolling with it because it’s already there. The ossified base also makes getting updated tools and libraries cumbersome, perpetuating the problem.

score 1 · canonical