Hacker News: nasretdinov

New comment by nasretdinov in "How employment is changing at Anthropic"

nasretdinov — Sun, 18 Oct 2026 13:38:37 +0000

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.

New comment by nasretdinov in "How employment is changing at Anthropic"

nasretdinov — Sun, 18 Oct 2026 12:13:23 +0000

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...

New comment by nasretdinov in "Better HTTP/1 connection reuse in Go 1.27"

nasretdinov — Wed, 14 Oct 2026 19:01:02 +0000

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

New comment by nasretdinov in "Better HTTP/1 connection reuse in Go 1.27"

nasretdinov — Wed, 14 Oct 2026 17:45:08 +0000

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.

New comment by nasretdinov in "Postgres isn't slow, your storage is"

nasretdinov — Mon, 12 Oct 2026 08:09:33 +0000

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...

New comment by nasretdinov in "A 40ms Go garbage collector pause caused by swap"

nasretdinov — Tue, 06 Oct 2026 09:23:45 +0000

Copying GC will make swap even less efficient, no?

New comment by nasretdinov in "A 40ms Go garbage collector pause caused by swap"

nasretdinov — Mon, 05 Oct 2026 06:34:01 +0000

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.

New comment by nasretdinov in "Firebase SDK is CRASHING ALLLL iOS Apps, since today morning"

nasretdinov — Tue, 29 Sep 2026 10:45:22 +0000

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...

New comment by nasretdinov in "Firebase SDK is CRASHING ALLLL iOS Apps, since today morning"

nasretdinov — Tue, 29 Sep 2026 09:16:28 +0000

If only there was any way to avoid this, right..? (I don't mean from Google's side, that as well, but that's not the point)

New comment by nasretdinov in "Kids go from curious to frustrated playing with AI-stuffed toys, UW study finds"

nasretdinov — Thu, 03 Sep 2026 09:11:45 +0000

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

New comment by nasretdinov in "Physically Immutable Optical Archive Libraries"

nasretdinov — Wed, 02 Sep 2026 10:12:17 +0000

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)

New comment by nasretdinov in "Physically Immutable Optical Archive Libraries"

nasretdinov — Tue, 01 Sep 2026 17:56:36 +0000

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.

New comment by nasretdinov in "AI-written code is still your code"

nasretdinov — Mon, 31 Aug 2026 13:05:05 +0000

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.

New comment by nasretdinov in "Breaking Claude Code Opus 5 Auto Mode"

nasretdinov — Mon, 31 Aug 2026 10:34:00 +0000

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.

New comment by nasretdinov in "Bug Blindness"

nasretdinov — Sun, 30 Aug 2026 06:22:33 +0000

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.

New comment by nasretdinov in "Hunting Down a Go Runtime Bug on 32-Bit Embedded Systems"

nasretdinov — Sat, 29 Aug 2026 16:20:29 +0000

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

New comment by nasretdinov in "The "I don't know, Claude wrote this" pandemic"

nasretdinov — Fri, 28 Aug 2026 06:26:19 +0000

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.

New comment by nasretdinov in "fork() Considered Harmful in macOS"

nasretdinov — Wed, 26 Aug 2026 17:37:29 +0000

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

New comment by nasretdinov in "The End of Programming"

nasretdinov — Wed, 26 Aug 2026 10:17:37 +0000

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

New comment by nasretdinov in "The End of Programming"

nasretdinov — Wed, 26 Aug 2026 10:06:13 +0000

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.