Given the site where this is posted and the screenshot, is the author an engineer turned fiction writer? Kudos if true. Posting these must take a lot of courage.

As a former employee, the engineering culture at Google gives me old-school hacker vibes, so users are very much expected to “figure it out” and that’s somewhat accepted (and I say this with fond memories). It’s no surprise the company struggles with good UX.

> users are very much expected to “figure it out” and that’s somewhat accepted

That sounds like a really fun place to work but a really awful business to be a customer of.

LLMs are good at in-distribution programming, so inventing a new language just for them probably won’t work much better than languages they were already trained on.

If you could invent a language that is somehow tailored for vibe coding _and then_ produce a sufficient high quality corpus of it to train the AI on them, that would be something.

This is painfully clear once you’ve worked in a non-first-world country. Everybody is just working a job.

Interestingly it became most painfully clear to me once I started working in an office in a developed country. Something about seeing the scale of it all. But I take your point.

> The guy is a coder through and through.

I’d be proud if someone says that about me one day. Hope Mitchell will share the sentiment.

Some juniors do figure it out, but my experience has been that the bar for such juniors is a lot higher than pre-AI junior positions, so there is less opportunity for junior engineers overall.

It’s possible to build this around protobuf. Google has a rich internal protobuf ecosystem that does this and supports querying large amounts of protobuf data without specifying schemas. They are only selectively open sourced. Have a look at riegeli if you are interested.

https://github.com/google/riegeli

I don’t understand this argument. It seems to originate from capnp’s marketing. Capnp is great, but the fact that protobuf can’t do zero copy should be more an academic issue than practical. Applications that want to use a schema always needs their own native types that serialize and deserialize from binary formats. For protobuf you either bring your own or use the generated type. For capnp you have to bring your own. So a fair comparison of serialization cost would compare:

native > pb binary > native

vs

native > capnp binary > native

If you benchmark this, the two formats are very close. Exact perf depends on payload. Additionally, one could write their own protobuf serializer with protoc they really need to.

I like this (paid) blog for its technical dives and HFT expertise, but the programing language opinions are a little click-baity and not worth the time.

Not giving up the address space feels like an anti feature. This would mean, among other things, that access to the DONTNEED memory is no longer a segfault but garbage values instead, which is not ideal.