i thought we all landed on Python.
brb, rewriting backend
Go is an ideal language for AI-assisted software engineering
291–300 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#292Earlier quoted context omitted.
Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…
You seem to be implying, based on the rest of the thread, that Go has some sort of special defect that keeps it from implementing Raft correctly. But the "special defect" that Go has is that it in practice implements the same primitives in practice that almost every other mainstream language does, rather than implementing some sort of super-safe concurrency primitive like Erlang or Pony, or being immutable like Haske…
Also, wasn’t this about concurrency? You could, if you really wanted, write a paxos or raft implementation with no concurrency.
Re: Go is an ideal language for AI-assisted software engineering
#293Earlier quoted context omitted.
Yes, this. =) I talk to Go users around the company all the time. Their feedback has been in this direction for a bit now.
But isn't this expected from users that like a certain language? Won't you also hear this response from Rust users that like Rust?
Exactly. I only count opinions from people who have deeply used the two langs they're comparing and can express what exactly was wrong with one of them for their task.
Re: Go is an ideal language for AI-assisted software engineering
#294Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…
I assume it's because Go is so opinionated? I experimented with it and found it almost boring to write, but I strangely loved it. Now in the AI era I crave the forced uniformity.
Re: Go is an ideal language for AI-assisted software engineering
#295Earlier quoted context omitted.
fwiw I have a bunch of LLMs writing first Lean code and now Agda code. My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked the…
>fwiw I have a bunch of LLMs writing first Lean code How do you bridge the mental gap? The gap between me writing high quality rust do this steps and something being logically sound seems enormous to me Maybe I'm misunderstanding things but I just can't articulate my ideas in casual lean4. But i can do casual rust spec
As someone experimenting with this, it's definitely very difficult to articulate your ideas using advanced type systems. At the same time, the process of doing it often forces me to seriously think through what I want the code to do, which I've noticed qualitatively improves the end result and my understanding of it.
My advice is to be okay with starting small: don't go for full end-to-end correctness or anything like it. Just think of simple properties you want like 'the list returned by this endpoint should always be sorted in ascending order' or 'this operation should be idempotent' and go from there. Use your favorite LLM to help come up with example specifications from natural language, as a starting point, and try hard to fully understand those.
This kind of work does operate at the frontier of what LLMs can do, so expect to run into roadblocks (wasting tokens proving accidentally hard properties, etc).
Re: Go is an ideal language for AI-assisted software engineering
#296Earlier quoted context omitted.
> I didn't want to do it in C, and I didn't want to learn Rust. Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.
Retro-justification is not some flaw it is most common way people choose tech stacks. The only logic that matters most of time is business logic of solution serving problem statement and not logic of choosing a technical stack.
Post hoc rationalization
The choice we made for other reasons is the best one for these constructed reasons that didn't exist until later.
https://en.wikipedia.org/wiki/Choice-supportive_bias
Measuring and Mitigating Post-hoc Rationalization in Reverse Chain-of-Thought Generation https://arxiv.org/abs/2602.14469
Re: Go is an ideal language for AI-assisted software engineering
#297Earlier quoted context omitted.
I think you're projecting. You wrote > Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted > "we’ve found bugs in every Raft implementation we’ve tested, ..." which says that there aren't any correct ones. You then wrote > I didn't say other languages don't h…
The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.
Lol "I swear have a girlfriend, she just goes to a different school"
Re: Go is an ideal language for AI-assisted software engineering
#298In the last few days I've heard this same claim regarding other languages like Gleam and Rust for one reason or another that I don't know who to believe.
Re: Go is an ideal language for AI-assisted software engineering
#299This would have been more credible coming from someone other than the creator of the Go language. I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not. So a…
fwiw I have a bunch of LLMs writing first Lean code and now Agda code. My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked the…
> My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code.
A bit funny, because I thought... Hmm, so LLM's find Agda natural?
My point being... It's a matter oh habit. After writing C firmware for more than a decade, I can read C easily. I might have to think of some parts and trace the code. But I can grokk it and hold the thing in my head. With Rust on the other hand, I just don't feel it as well. I am afraid writing C gave me brain damage and restricted the lens I can see the world through.
Re: Go is an ideal language for AI-assisted software engineering
#300Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…
Go wins for simplicity. however what I have seen is companies end up going with Java coz it's simple enough - not simple as Go, but simple enough + fast enough. though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
Go's big advantage was M:N threads. Java's biggest flaw has been the lack of cooperative multitasking, which people worked around by mangling their code with promises. Now Java has M:N threads too thanks to Project Loom, but there's so much code written before that will never really go away.