pornel

It's not worth it. The value of C is in compatibility, availability of compilers, and familiarity.

As soon as you change anything in a breaking way, start requiring your own compiler/transpiler, or introduce new idioms, you end up losing the things that keep C alive.

Users of C either like it exactly the way it is, or have to use a specific C version due to a vendor dependency or compliance.

An upgraded C not approved by the standards body gives you yet another niche language that is not C, but is still burdened with its old flaws.

I suspect fearless concurrency is another motivating factor. Better perf can be achieved by squeezing more parallelism, but without borrow checking it's difficult to do fine-grained parallelism correctly.

I don't trust agents writing specs without human approval.

I've been bitten by agent-written ADRs. Agents carelessly add extrapolated details and speculated nice-to-haves that I never asked for, and this becomes a source of bloat that keeps coming back like a boomerang.

Quality over quantity :)

The bar isn't getting it perfect. The bar is merely parity with the legacy C++ code that wasn't perfect either, which nobody wants to maintain either.

LLMs are fuzzy when generating, but such conversions aren't done one-shot. Review and test feedback loops are there to catch the random errors. The frontier models are getting good enough at this.

When LLM is instructed to generate idiomatic safe Rust (rather than literal 1:1 unsafe translation), it benefits from a lot of feedback from the compiler.

Whatever QA there was to ensure C++ was good enough can be applied to the Rust version too.

Blocking slop code, like `unwrap_or_default()` in Rust that agents use to weasel out of error handling.

/omfg automatically adds new rules, so I have plenty of project-specific enforcement (e.g. disallowing making certain fields public, which agents love to do to take a shortcut that ruins the architecture).

Rust already uses MIR-based libraries for LTO, and uses thinLTO by default.

ABIs won't help automatically. The overhead comes mainly from generics and macros. Cross-crate monomorphic generics and AST macros are impossible to express in an ABI. Turning them into polymorphic usually wouldn't remove the many abstraction layers that need to be peeled off, and only make them cost at runtime too.

So far MIR optimizations were helpful. Rust can simplify high-level MIR quicker than LLVM can simplify the same code after it's been lowered to lots of low-level instructions.

Subagents in OpenCode suck. They're blank-slate black boxes that block execution.

OMP spawns agents asynchronously, letting the main agent check on them periodically and even chat back and forth with the subagents to coordinate dynamically instead of losing control after initial prompt (it's also very amusing, like watching Sims play office).

OMP also has /tan tangential prompt which spawns subagents that reuse entire conversation prefix (cached), so you don't waste tokens on sending them a recap of the situation and them re-discovering the codebase themselves. OpenCode kinda does it with fork + switch of sessions, but a command inside one session is quicker.

Yeah, Advisor and "time-travelling rules" (TTSR) work great (they're injecting corrective prompts automatically either via another critic LLM or a bunch of regex rules, respectively)

It automates a lot of the babysitting of agents, and lets me use a couple of smaller models with safeguards instead of burning tokens on a galaxy brain just because it listens to instructions in AGENTS.md.

Zero-cost abstractions aren't zero cost in compilation time. High-level abstractions translate to a lot of boilerplate that the compiler has to optimize out.

In unoptimized builds often the linker is the bottleneck. Rust/Cargo can parallelize most of the build, generating tons of code and debug info, but then the poor linker has to consume all of it at once. The object/exe formats were designed in ancient times, so they're hard to build incrementally or in parallel (some linkers are trying).

Carbon's own docs say:

> Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.

So the reason for Carbon to exist is gone. C++ code can be migrated straight to Rust without Carbon's stopgap.

Yes, and it's easy to verify how much of the original capacity remains (95% typically).

The deprecation has very little to do with the cars themselves. It's mainly due to original prices being inflated during covid demand spike + chip shortage followed by releases of decent brand new EVs under £25K.

When you buy used, the depreciation works in your favour.

You can get a mint condition IONIQ 5 with 300bhp and 20-minute charging for less than a new Corolla.

10-year old Teslas are great, you just need a sticker "bought before Elon went crazy".

Just like we lost em-dash and bullet point lists, we're going to lose cards, pills, and small caps subheadings.

It sucks that LLMs took things that were good when used in human-authored content, and ruined it by vomiting back overused cargo-culted versions of it.

but the C for them is its own little world playing by its own rules, separate from C used everywhere else.

And I bet that when you have only 16 bits of address space, you care how many bits every integer has.

Competition is good. Without K3/GLM/DS4 etc. there would be no pressure on OpenAI to drop Sol's price.

But solar panels are dirt cheap. Just slap 8x more of them on earth.

It's nuts that it's supposed to be easier to send them to space than to truck them to a desert.

+100miles range in 10 minutes and 10-80% in 20 minutes has been available for 5 years now.

It's already practical IMO. Pushing it lower starts becoming more about removing excuses ICE drivers say, rather than solving problems that EV drivers have.

Toyota wants to show nobody wants EVs by making EVs nobody wants.

ESP32 boards are small and cheap adapters between Wifi (network APIs) and I/O pins for small electronics like LEDs and relays.

If you want a web API for something in the physical world, make ESP32 do it.

Charging at home is already more convenient and quicker (in human time) than driving to a gas station, and now they're optimizing the 30 seconds it takes to plug the car in.

This dreaming about roundabouts is as American as the fantasies about using metric one day.

or perhaps The Proper English has been adopted by LLMs, so now real people have to write like middle-schoolers to avoid being accused of publishing slop.

The big news here is they've replaced LLVM with MSVC's backend.

Throwing it as-is into a simple bayesian filter works great too - nobody honest writes fun&zwsp;ding.

Stellantis is still producing 400V EVs with below-average efficiency. Their cars display estimated range based on their marketing number rather than real battery condition and driving history, so the range drops by 1.6 miles for every mile driven.

A lot of range anxiety would go away if their EV tech wasn't crap.

> I fail to see how any sort of much lower level access to the machine would be portable across price ranges and microarchitecture generations

That's the assumption that can be removed. GPUs don't have stable ISAs, and their assembly-like code gets recompiled for each microarchitecture.

In the Intel's world of prebaked machine code adoption of a wider set of SIMD instructions takes a decade+. In GPUs it's just a driver update.

Modern CPUs hide so much logic that the assembly language is an abstraction itself. CPUs have many times more registers than their assembly language, execute instructions speculatively and out of order. Multiple layers of caches are synchronized in complex ways. There's an invisible complex work scheduling algorithm that can even make one CPU core interleave work of two (hyperthreading).

GPUs can expose more of their internals thanks to shader compilation. They don't have to emulate previous-gen chip, and instead every chip can expose exactly what it supports and rely on software being recompiled for it.

Apple would have probably lost more customers if it didn't also create a hard-to-leave lock-in ecosystem.

Lots of people use old iPhones and don't care about some "up to" benchmark bumped every year, but are stuck with iMessage contacts, their stuff in iCloud, Apple Watch or apps that are not allowed by Apple to even mention they have Android versions.