I must say I find my colleagues who use AI instead of answering the damn question equally frustrating, and unfortunately they're in another country so I can't throw them into the ocean
With that modern LLMs are capable of I'n seriously considering investing in at least M-DISC storage or similar to store stuff I don't want to lose :). It's unlikely that both iCloud and Synology get hacked at the same time, but the probability is higher than I could imagine before.
I burned some optical installation media for OpenBSD and Linux for the first time in a long time to have some RO boot media if another Internet Worm comes around.
If you are concerned with durability mostly in terms of the next few decades, I think S3 deep archive would be difficult to beat. Your data is offline by default. It would be logistically infeasible for a rogue agent to physically mount every tape for purging before someone would notice and stop the tape library.
The risk with any cloud is that while your data might be physically intact, you can still lose access to it for a variety of reasons (e.g. being born in a wrong country)
Interestingly enough, the question "do we want to support it" has been the main one (not "can we write it") in any sufficiently large and mature project for as long as I remember.
Now, becoming large is now a solved problem essentially, but that's still only maybe 10-20% of the software engineering work in the long run. I'm grateful I can delegate some grunt work to LLMs, but, essentially, the main reason why large projects slow down development has never been due to inability to write lots of code quickly.
That's an interesting technique! I'd also like to point out that there's something odd with the page itself too, my phone got really hot while I was reading the page, and drained a significant amount of battery charge as well.
That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
Go was born into 64-bit era, I remember seeing many more bugs that only occur on 32-bit systems. I'm pretty certain the observation in the article is correct that no one at Google tests Go on anything apart from 64-bit ARM/x86 Linux
(That particular build dashboard just shows post-commit tests. '386' there is 32-bit x86, 'arm' is 32-bit ARM.)
I can't speak to what Google runs in production or what Google tests internally, but the Google-run CI for the Go project definitely does test 32-bit, and those tests essentially match the tests run against 64-bit.
Yeah that's quite odd that people somehow now think you can't reject a PR because you can't understand it -- but initially that was one of the reasons to have code review in the first place.
I believe what's being described in the article is the same reason why some shells like fish also use posix_spawn() on macOS instead of fork/exec. Not only is it much faster, but it's also effectively problem-free for multi-threaded applications
LLMs are scarily good at translation, whether between natural or between programming languages. Also very good at re-implementing the stuff that has been provably done before. And, arguably, 90-95% of writing code is exactly that.
In my experience they still struggle a lot though. They're great at 1 to 1 translations but they will fight the target language to get there tho. A lot of the rust rewrites I've seen done by AI contain a lot of patterns that any rust dev worth it's salt will scoff at.
Yes -- the bigger the difference between languages the worse they perform. However I'm not really expecting e.g. Claude to be able to port sync.Map from Go to Rust, because sync.Map relies on GC to do the hard work of cleaning up references to values no longer used by any goroutine :).
But in porting, e.g. from PHP to Go they're crazy good at, doing a much better job than any simplistic machine translation ever could
I'm no expert, but it feels like this exact thing is how it ends up eating itself. For two reasons.
- Eventually the universe of "provably done before" is now mostly LLM genned code. So the training data quality starts a slow decline.
- That it's "good enough" now for 90+% of the work kills the pipeline for any new human software experts. So they never gain the experience and insight to be able to steer the AI to produce ok-ish code. Existing experts age out. This cycles with the bullet above over time. And at some point we're stalled, all code is now mediocre at best and while output is high, innovation/evolution is low. Or whatever innovation we have is coming from a very small circle without much natural competition.
IMO that's precisely why software engineering is going to become even harder than it is right now -- all the "easy" stuff is semi-automated, so now you have to spend even more time and energy "drawing the rest of an owl" so to speak, doing the hard 10% yourself. And unless anything drastic happens in LLM development this last 10% isn't going to be automated away any time soon.
TBH Apple never should've been the one who makes the best CPUs -- that's not really their area of expertise historically speaking either. It just appears that everyone else did such a terrible job for so long that they caught up
reply