Wait until management learns that code itself also is geberally a liability and requires maintenance, is a source of bugs, etc. That's basically why measuring lines of code has been frowned upon for a long time as a measure of developer productivity.
I wonder if you have a lookup table for values that _rarely_ change you could use the same approach (with maybe one caveat that you'd need to track the lifetime of the old variant of the hash table)
Well I'm obviously not comparing to average human intelligence (and negligence), but that's actually a good reminder about one other important aspect of how living organisms are very different from machines -- humans have very high range of intelligence, strength, etc, and the best humans are usually much better than the average in all areas of life. Computers and software are much less diverse.
Unless something dramatic changes and it'll become cheap to "constantly re-educate" the models to learn the new fundamental facts about the system (ideally with a small lag of maybe a few days like with humans) I see no reason to think that LLMs can have a profound understanding of how business systems work of a remotely comparable quality to humans. Just adding the context about the system already reduces it's capacity significantly according to what I can tell. Not having large context helps somewhat at a cost of having to explain lots of task-relevant things to LLM over and over again...
If you don't need SSL you can't use HTTP/2 or HTTP/3. It doesn't make sense for externally facing services but sometimes is ok or even unavoidable for local networks
It sucks that this changes the behaviour under the hood that you previously coukd rely on the fact that closing the response body lets you skip downloading the HTTP body entirely, but I do like the tradeoff here, since it also limits the download time to just 50ms you'd not get overwhelmed if your network can't keep up with all the cancelled HTTP bodies, you'll just wait a little bit of traffic instead.
Honestly the network-attached storage only ever made sense with HDDs, it's ridiculous to have to pay 10x penalty for both iops and latency just for some "operational flexibility". You get way simpler and much more robust architecture if you just stick to local NVMe and replication -- not that you can forgo one in the (also replicated) network block storage solution anyway...
Unfortunately that's somewhat expected - regardless of implementation, the sole fact that the GC needs to somehow walk the entire tree to trace still referenced sections makes swap highly impractical -- even if you had not had 40ms stop-the-world pauses the LRU cache used by swap would get thrown away at every GC.
I believe that's actually the same reason why Apple stopped using GC in their frameworks in favour of automatic reference counting.
Well, you don't have to use the proprietary third-party SDKs in your apps... If you want analytics you can either implement your own, or use some open-source ones that aren't dependent on some third party backends switching some features on for everyone all at once...
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
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)
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.
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
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
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
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.
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.
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