In my (not systems engineering) opinion, most time spent writing code is boilerplate and rituals; unit tests are pretty repetitive, creating a React component is a lot of repetition, etc. A LLM code assistant can do these boring things faster.
Yeah I agree with you on that, I'm just curious about the systems programming use case as in my experience you have to think deep about interactions and working with an agent blunts that
By most aspects the world of 1990 didn't change that much from today's world, with the exception of having computers in our pockets and some advances in medicine.
I used to work with a guy who would tell me that, except email, life didn’t really change since the 80s. All we did was stick a screen onto everything, whether we needed to or not.
I was only born in the 90s but I mostly agree that far back.
Reminds me of a line by John Maynard Keynes from 1919 about life before WW1 —
“The inhabitant of London could order by telephone, sipping his morning tea in bed, the various products of the whole earth, in such quantity as he might see fit, and reasonably expect their early delivery upon his doorstep”
Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds
That claim relies on an absurd "in the kernel" qualifier, making it difficult to agree with. Furthermore, your hypothesis is that "we all" agree with claims that rely on absurd conditions as a matter of course.
Sure this could happen but that seems like a very last resort. The only reason the US economy is still competitive is tech stocks so cutting off ~35% of your income seem like it would cause a lot of downstream effects
This a bit of a hollow article and kind of misses the point of Rob Pike's rant. This is a guy who care deeply about computing. He spent the first 20 years of his career working at Bell labs, building things like utf-8 (an amazing idea that everying easier for anyone who doesn't speak english!) and plan 9. Pike does not like resource wasting (part of the reason they built Go was to replace Python at Google) so yes, his point makes sense in that context
Sometimes certain containerized processes need to run according to a schedule, but maintainers also need a way to run them manually without the scheduled processing running or starting concurrently. A shared FS seems like the ”simplest thing that could possibly work” distribution method for locks intended for that purpose, but unfortunately not all cloud storage volumes are strongly consistent, even to the same user, and may take several ms for the lock to take hold.
Wouldn't a database give you better consistency guarantees in that case? NFS locking semantics are a lot more complicated than just a `SELECT .. FOR UPDATE`
Sure, but that would require a separate database for this one use case. Mixing infra concerns into an app db doesn’t sound kosher, either, and a shared volume is already available.
Seems easier to have a managed lockfile for each process, diligently checking that the lock has actually been acquired. Performance is not a concern anyway, as long as acquire takes just a few ms we’re golden.
Yeah it honestly feels like the problem here – it's a common pattern where someone tries several times at a promo, then transfers to another team and gets promoted immediately.
Waymo cars have been proven safer than human drivers in California. At the same time, 40k people die each year in the US in car accidents caused by human drivers.
I'm very happy they're moving fast so hopefully fewer people die in the future
reply