HN user
Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go.
Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.
The problem isn't this weird gaslighting attempt that we just haven't let Claude in our hearts and souls yet which you seem to have determined is inevitable (spoiler alert, it is not),
I don't believe it's inevitable and in fact, I'm thoroughly against the use of tools like Claude.
My reference to "different stages of acceptance" was only to indicate that people have embraced these things to varying degrees, and it that it seems to be this difference which is causing conflict in discussions like this. (I doubt I will ever fully accept it. A lot needs to change for that to happen).
I didn't really have the "five stages of grief" in mind when I wrote it.
This is not okay.
Agreed. The way to address it though, is through calm analysis and reason. The emotional language from both groups is not helping.
If there's one problem with Claude et al, it's that it's all happened way too quickly for people to keep up. We're all at different stages of acceptance and I think that's what we're seeing manifest in the various discussions.
As a long-time open-source maintainer, I find all the second-guessing and armchair psychoanalysis here (not just in this comment, all over HN) about Tridge's motivations, state of mind, and so on incredibly off-putting.
Much of the language from both groups is incredibly off-putting, frankly. Tridge in his blog post describes people as "foaming at the mouth"?!
The rhetoric around this has gotten way too emotional from both groups.
I'm glad I'm just a hobbyist.
Ferrari have long worked with third-party coachbuilders such as Pininfarina. I'm not sure how much autonomy Ive had over the final design, but if it's anything like the relationship with Pininfarina, etc. the design would have been a collaboration.
Well, that and the fact that after the 48K beeper the 128K was never going to sound less than incredible
Some of the stuff people do with the 48k beeper is incredible though. Tim Follin's tunes for example are basically treating the beeper like a 1-bit DAC, with amazing results. https://www.youtube.com/watch?v=T42WuUpBuHE
That's not enough in this case. The suggested mitigation according to the Dirty.Frag github page is to blacklist esp4, esp6 and rxrpc
Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.
Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles.
Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.
I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.
Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).
Forks can be handled by people cloning the repository and uploading a new project.
I wrote a program similar to this for AmigaOS many, many years ago. I would have been inspired by ZoneAlarm or a program like it.
I've just found it and uploaded it to github. Looking at the code, I can see my horrible C style of the time. There's probably bugs galore.
https://github.com/JetSetIlly/Direwall
If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.
It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.
Some nice ideas but the regexes should include word boundaries. For example:
git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | sort -nr | head -20
I have a project with a large package named "debugger". The presence of "bug" within "debugger" causes the original command to go crazy.
Superb demos this year at Revision. Triplet by Otomata Labs for the Atari 2600 is exceptional
Original release video (probably running on Stella)
https://www.youtube.com/watch?v=aEJ0A8Wvdxs
And a video of it running on Gopher2600.
I agree. Dealing with different endianness has never been an issue so long as you're aware of where the boundaries are. A call to htons() or ntohs() (or the 32bit equivalents) was the solution. I would hope all modern languages have similar helper functions/macros.
I agree. The act of coding is when I do my thinking.
I really meant in the coding realm, but it's interesting that it created a bootable floppy. That wouldn't be trivial.
Questions: 1) Which AI platform did you use? 2) Did it create a binary image of the floppy disk (an ADF perhaps)? If not, what form did it take?
Farting around with Amigas in 2026 means actively choosing to make things harder for the sake of making things harder. Making that choice and still outsourcing the bulk of the craft and creative process is like claiming to be a passionate hobby cook while serving professionally catered dinners and pretending they're your own concoctions.
People wanting to explore the use of generative AI for vintage computers is happening not just for graphics but for code too.
I think in the case of code though, it's still interesting because I don't believe there's been any success yet. I hear of people having success with Claude in contemporary settings but it seems to fare less well when working for older computing platforms. There's a reason for that of course and it's worth exploring.
However, it will cease to be interesting as soon as the first person manages to create something substantial. At the point, the scene should probably shun it for the reasons stated in the quote.
I no longer drink in pubs but in my neck of the woods, the pubs that specialised in cask ale often had lined glasses.
The problem was that many people insisted on the glass being filled to the brim, because they felt they were being short changed. So it solved one problem but created another.
In that case I misunderstood.
It's an interesting idea. I think I prefer the exiftool syntax over what's suggested in the blog. Thanks for bringing it to my attention.
Yes, there are a few tools that do this. Looking at /bin and the softlinks that are there, the various xz tools do it (unxz, lzcat, etc.). Also, vim. vimdiff and view are just softlinks to vim.
The only difference is that those tools have chosen easy to remember names rather than embedding the arguments as metadata in the filename.
As a generalisation of the idea though, the blog post is neat.
Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.
Eternal LLMber
I think the split is between people who are in a hurry and those who are not. I'm not in a hurry and so choose not to spend money to get a quicker result.
Taking time to solve a problem myself is pleasurable and I make no apologies for that.
Horses for courses.
Cool. This is how I imagine the ants were programmed by the spiders in Children of Time.
I've heard people say that these coding agents are just tools and don't replace the thinking. That's fine but the problem for me is that the act of coding is when I do my thinking!
I'm thinking about how to solve the problem and how to express it in the programming language such that it is easy to maintain. Getting someone/something else to do that doesn't help me.
But different strokes for different folks, I suppose.
"Any terminal tool like Claude Code or Codex (I assume OpenCode too, but I haven't tried) can do it, by using as a prompt pretty much exactly what you wrote, and if it still wants to edit, just don't approve the tool calls."
I'm sure it can. I'd still like a single use tool though.
But that's just my taste. I'm very simple. I don't even use an IDE.
edit: to expand on what I mean. I would love it if there was a tool that has conquered the problem and doesn't require me to chat with it. I'm all for LLMs helping and facilitating the coding process, but I'm so far disappointed in the experience. I want something more like the traditional process but using LLMs to solve problems that would be otherwise difficult to solve computationally.
"All of them are moving into the direction of "less human involved and agents do more", while what I really want is better tooling for me to work closer with AI and be better at reviewing/steering it, and be more involved."
I want less ambitious LLM powered tools than what's being offered. For example, I'd love a tool that can analyse whether comments have been kept up to date with the code they refer to. I don't want it to change anything I just want it to tell me of any problems. A linter basically. I imagine LLMs would be a good foundation for this.
The golang.org/x/ namespace is the other half of the standard library in all but name. That gets iterated often.
For stuff in the standard library proper, the versioning system is working well for it. For example, the json library is now at v2. Code relying on the original json API can still be compiled.
"These things are not intelligent. They're just tools."
Correct. But they are being marketed as being intelligent and can easily convince a casual observer that they are through the confidence of their responses. I think that's a problem. I think AI companies are encouraging people to use these tools irresponsibly. I think the tools should be improved so they can't be misused.
"Incidentally, those structures are also the sorts of things that greatly benefit human programmers."
Correct. And that's why I have testing in place and why I used it to show that the race condition had been introduced.
"Okay. If you’re being vague, you get vague results."
No. I was vague and got a concrete suggestion.
I have no issue with people using Claude in an optimal way. The problem is that it's too easy to use in a poor way.
My example was to test my own curiosity about whether these tools live up to the claims that they'll be replacing programmers. On the evidence I've seen I don't believe they will and I don't see how Go is any different to any other language in that regard.
IMO, for tools like Claude to be truly useful, they need to understand their own limitations and refuse to work unless the conditions are correct. As you say, it works best when you tell it precisely what you want. So why doesn't Claude recognise when you're not being precise and refuse to work until you are?
To reiterate, I think coding assistants are great when used in the optimal way.