K0nserv

I don't usually check in compiled artifacts myself.

I feel it's a faux pas to pass off work entirely or partially done with AI as your own. I make sure I leave those lines in specifically for that reason.

I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder.

Of course Rust has a few footguns too, that's not my point.

There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic.

This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0].

It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt.

0: https://hugotunius.se/2026/06/15/the-sword-juggling-fallacy....

The Dunning-Kruger thing wasn’t meant to disparage the developer and certainly not to call them stupid. It’s simply a reflection on not knowing what you don’t know and thinking you know more than you do. Everyone goes through that.

It's not uncommon it's used in France, which has a population of 66M (also Belgium).

This is just a classic case of a developer situated firmly at the first peak of the Dunning Kruger graph.

with rust you have 2x more ways to shoot yourself in the foot.

The checking isn't how you shoot yourself in the foot, it's the absence of checking. Rust doesn't allow you to forget to check. This entire class of problems just disappears in Rust.

In this if the code needs a non-null redis client to work you take `RedisClient` not `Option<RedisClient>`.

You sound like people who claim AI is freeing because it has removed the gatekeeping of programming when programming was never gatekept, all you needed to do was dedicate time to learn.

Your premise doesn't even make that much sense given that Knockin' on Heaven's Door uses only the three chords(G, C, Am) and they are some of the most common chords in music.

That makes sense, but I would love to see the data on it. I don't doubt at all that capitalism in isolation is viewed more favourably in the US, but that doesn't preclude the intersection of AI and capitalism being viewed less favourably.

I suppose my comment should've said "views on AI aren't solely views on AI, they are views on AI as it intersects with capitalism"

I don't doubt that's true for everyone who reads HN, but having seen the other side there are loads of people who don't make the effort and could've found their own answer in the knowledge base.

I find LLM customer service to be better than the historic dumber stuff. In those you can usually say "I want to talk to a human" and it will escalate. The customer service bots of yore were far dumber and made it harder to escalate.

Agree. I actually think we'll see a resurgence in art and graphic design as a consequence. At least for now people can spot AI generated artifacts and many immediately have a negative reaction to it. I don't read blog posts that feature AI generated images, even though they are only slightly worse than stuff cribbed form Unsplash.

I don't like AI customer service either, but having seen the other side it cuts down huge amounts of inbound queries (where the answer can usually be found in knowledge bases) and provides an answer faster than a human would. As long as the escalation path to talk to a human isn't too arduous it's not too bad.

I think views on AI are not really views on AI, they are views on capitalism. People don't feel optimistic that AI's impact will benefit ordinary people because, even if works out, the benefit will accrue only to capital owners. This view feels pretty understandable to me, but is ultimately orthogonal to whether AI is useful and effective for the kind of tasks we want to leverage it for.

Unironically parroting uniparty lines is moronic. Sure there are problems with the Democrats, but both-sideism is at this point being wilfully blind.

As an external observer to US politics it would be great for the country to move past the two-party system, but to say they are the same is ridiculous.

The title is a little weird. The problems outlined are mostly about the community and governance, not the language.

To address at least one part of this: rewriting things in Rust. I think this is less about security and more about people wanting to scratch their own itch. Instead of improving existing tools, which is not seen as appealing, programmers write alternatives in Rust. You can flip this on its head and say that existing tools are not welcoming to new contributors and are failing to attract them.

But remember, C is simple.

I'm also curious about that. One thing to keep in mind: the invariants you have to uphold in unsafe blocks are quite stringent. I expect that in some instances the Rust code has new UB due to this.

If that was true, then I would expect followups to reduce UB and unsafe in general, or at least requiring a lifetime for caller-owned memory.

It's been like a day since the merge, presumably such followups are coming.

Sure, but that's kind of orthogonal. Imagine doing this by hand I still think going like-for-like with the Zig, even if that means a lot of unsafe, is a good approach.

But I suppose if you are already using LLMs it's more reasonable to try and go from Zig straight to Rust with no/minimal unsafe.

It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe.

Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.

It's not that strange. TURN has two main use cases: peer-to-peer when no viable direct path can be found and working around very strict firewalls. Based on the author's experience the first isn't relevant and the second isn't much of a concern for Twitch and Discord. For the latter case HTTP/3 is helping make TURN unnecessary because you can, as the author observes, run UDP over port 443.

Realised all of these examples are for async, but they apply equally for sync.

This is a great question and there isn't a definitive answer provided in the sources I linked.

Broadly I think there are three approaches:

1. For frequent and small CPU heavy tasks, just run them on the IO threads. As long as you don't leave too long between `.await` points (~10ms) it seems to work okay.

2. Run your sans-io code on a dedicated CPU thread and do IO from an async runtime. This introduces overhead that needs to be weighed against the amount of CPU work.

3. Have the sans-io code output something like `Output::DoHeavyCompute { .. }` and later feed the result back as `Input::HeavyComputeResult { .. }`, in the middle run the work on a thread pool.

I think you are correct, in so far that often N:M threading is overkill for the problem at hand. However, some IO bound problems truly do require it. I haven't kept up with the details, but AFAIK the fallout from Spectre and Meltdown also means context switches are more expensive than they were historically, which is another downside with regular threads.

I also want to address something that I've seen in several sub-threads here: Rust's specific async implementation. The key limitation, compared to the likes of Go and JS, is that Rust attempts to implement async as a zero-cost abstraction, which is a much harder problem than what Go and JS does. Saying some variant of "Rust should just do the same thing as Go", is missing the point.

There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`.

For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2]

I have my own writing on the topic[3], which highlights that the problem is wider than just async vs sync due to different executors.

0: https://github.com/rust-lang/effects-initiative

1: https://www.firezone.dev/blog/sans-io

2: https://notes.eatonphil.com/2024-08-20-deterministic-simulat...

3: https://hugotunius.se/2024/03/08/on-async-rust.html

Indeed, that's a much better formulation.

I built https://github.com/k0nserv/plid with Pgrx and had a great time. I did have to scale back some of the magic (dropping derive PostgresType etc), but even so the support pgrx provides is excellent. I also talked to the maintainers a bit in discord and they were super helpful.

The one downside of custom extensions is that you aren’t, AFAIK, able to use them with many hosted Postgres installs, notably AWS RDS.

The US spends the most per capita[0] on healthcare in the world, all to receive a healthcare system that still requires lots of citizens to carry private insurance. I've never dug deep into why, but it sure is noteworthy.

0: https://www.statista.com/statistics/283221/per-capita-health...

There are a few problems with how Trump is going about this:

1. The tariffs are too broad, they don't target a single or a few industries.

2. Trump has gone back and forth many times on them, using them as negotiating leverage, not as long term incentives.

3. They are on very shaky legal grounds and will likely end up getting reversed by either the Supreme Court or the next president.

If you want to use tariffs to encourage on-shoring you make them targeted and pass them with bipartisan support through congress. Companies need stability and long term guarantees for the kind of capital expenditure that is needed. Even better if you use a mix of carrot and stick, rather than all stick