I will leave this prediction here and maybe come back in few years: 1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md 2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smal…
I mostly use Elixir and JS, and I'm constantly surprised by how much easier and better the code quality is in Elixir, especially given the much smaller training data. I've started to use it for all my personal projects. I think Elixir's terseness, introspection capabilities, and strong ecosystem-wide quality guards really help. At work, we use C#. I'm shocked at how much worse it is. I've also used a bunch of Python,…
Go is an ideal language for AI-assisted software engineering
451–460 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#452Earlier quoted context omitted.
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.
Java already had M:N threads in the early days, aka green threads, because the JVM and Java specifications did not assert what kind of threading was to be provided. Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations. With Project Loom now both models are officially supported and part of the specification.
Re: Go is an ideal language for AI-assisted software engineering
#453It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Re: Go is an ideal language for AI-assisted software engineering
#454Earlier quoted context omitted.
Java and C# (JVM and .NET in general) are favorable here.
Uh at the very least Java is bad. the java programs we run take 4 gigs and burn my entire compute. Every1 used spring or guice and the di runtime, so tests are expensive for e2e with mocks. There’s no scrutable way I can run more than 2 or 3 on a standard laptop without burning out the thing. Go can.
Re: Go is an ideal language for AI-assisted software engineering
#455Earlier quoted context omitted.
Surely the King is doing it, so that must be the correct way. Look, the King even wears clothes and is totally not naked at all. That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement. No matter who you look at, they're just cooking with gas like you do,…
It's not even a qualitative statement about Kubernetes.
Re: Go is an ideal language for AI-assisted software engineering
#456It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
Re: Go is an ideal language for AI-assisted software engineering
#457Earlier quoted context omitted.
Java and C# (JVM and .NET in general) are favorable here.
Uh at the very least Java is bad. the java programs we run take 4 gigs and burn my entire compute. Every1 used spring or guice and the di runtime, so tests are expensive for e2e with mocks. There’s no scrutable way I can run more than 2 or 3 on a standard laptop without burning out the thing. Go can.
Re: Go is an ideal language for AI-assisted software engineering
#458It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
Re: Go is an ideal language for AI-assisted software engineering
#459It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
But on the other hand, I suppose it makes it a bit more pragmatic - less checks makes for a faster compiler, and fast compilation was/is very high up in the language's requirements and motivation. If you want / need more strictness in your language, there's Rust, Java, C#, etc.
Re: Go is an ideal language for AI-assisted software engineering
#460It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…