Yes, as long as a senior SWE guides AI agents properly.
Go is an ideal language for AI-assisted software engineering
541–550 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#542I 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…
Can't edit now but somehow I forgot to mention LISP/Clojure - I think it might be very interesting choice for LLMs because of the macro system and overall expresiveness.
Also, Clojure specifically is mem-safe because of the host VM and concurrency saf(ish) thanks to persistent data structures and core.async. It might be somewhere between 3 and 4, maybe together with Elixir. Unfortunately I never had enough time to play with it but I definitely will.
Re: Go is an ideal language for AI-assisted software engineering
#543Earlier quoted context omitted.
Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source...
Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
Nope, it is a matter of skill as well.
Re: Go is an ideal language for AI-assisted software engineering
#544Earlier quoted context omitted.
> For a language team, Go is a dream. I agree very strongly. There's no debate about things that have 1000000 permutations in other languages. e.g. The correct format can always be checked by `go fmt` with no real config options. the end.
I mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black)
And I'm thankful that they do, but also, Go was one of the first languages that really pushed for a standard code format - I'm actually surprised this wasn't a thing before. Or I suppose there was, like Checkstyle for Java or ESLint for JS, but they were not strongly opinionated or pushed by the core team.
Re: Go is an ideal language for AI-assisted software engineering
#545Earlier quoted context omitted.
>> ...there is no debate... > ...And so many languages have an opinionated formatter these days The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.
As if projects haven't used to have a coding style. What's so hard in saying that code should be formatted with Black, yapf, ruff etc, beats me.
It's not hard, but when you go from project A to B you'll have to check which formatter is used; this is additional setup / overhead, plus context switch. With Go, there is no additional setup / overhead / context switching, all Go code is formatted the same way with the same tools.
This is important when dealing with large code bases and many projects, it lowers the barrier to entry by a lot. A common anecdote from Go developers is how easy it is to drop into a random codebase and just be able to read/comprehend it and work in it right away, and the ecosystem-global code style is an important aspect of that.
Re: Go is an ideal language for AI-assisted software engineering
#546Earlier quoted context omitted.
It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard. The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.
> It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas Guess what other low-level bike-shedding argument 'go fmt' obviates? That's right - tabs vs spaces! > If it isn't the end of it you've got a talent issue. I know you meant this as a slur, but the implication is Go works better than other languages for those who have what you call "a talent issue"
> Go works better than other languages for those who have what you call "a talent issue"
This is actually true and by design; a bit more nuanced from [0]: "Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
Talent is important, but doesn't scale. You can have the best of the best software developers but it's a moot point how talented they are at industrial scales (hundreds of applications, tens of millions of LOC, thousands of developers, tens of thousands of features, decades of work, etc)
Note that "early in their careers" from the perspective of the author is basically [0] https://go.dev/talks/2012/splash.article
Re: Go is an ideal language for AI-assisted software engineering
#547Earlier quoted context omitted.
> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.
If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.
They're also a "thinking error"; most errors are not exceptional and should instead be part of the regular flow of your application. But in 90's/2000's languages like Java and C#, they consider "this file does not exist" as an exception. Second issue is that they include a call stack and are generally pretty expensive to construct.
To circumvent this, a lot of exception languages are written in a more defensive style.
Re: Go is an ideal language for AI-assisted software engineering
#548Definitely 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.
The other reason why Java is preferred is the hiring pool - there's 10-100x as many Java developers out there than Go developers. It's almost a guarantee that you'll find people, which is arguably more important than what language you use.
Re: Go is an ideal language for AI-assisted software engineering
#549Definitely 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.
Boring is a feature, although it's understandable why people don't like that.
But, major software (maintenance) issues have been caused by people writing interesting code. It's gratifying and fun for the individual, but detrimental to the application / codebase / business.
Re: Go is an ideal language for AI-assisted software engineering
#550Earlier quoted context omitted.
Likely because Netflix relied on Silverlight for video playback early on. I'd be surprised if they still had C# in their front-end stack (and I say that as a general C# fan, though I use it on the back-end).
My favorite thing about it having Silverlight is Silverlight actually worked on Linux better than Flash did. I think I used the Mono version of it though, I don't remember?
I remain of the opinion that there was nothing wrong with Flash or Silverlight, and the only reason it fell out of fashion was that Apple refused to support it on iOS.
Don't care about losing Java applets though, those things were too heavyweight for what they did. And more advanced stuff like Windows Update running through a browser was major security incidents waiting to happen.