41–50 of 586 posts
And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program.
The first tests I have seen seem to confirm this. One recent example:
Earlier quoted context omitted.
I have a question: why do you think Go is better compared to other languages? After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously. My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I…
> why do you think Go is better compared to other languages? I didn't say that. :) > where do the results claiming that AI agents generate superior Go code actually come from? Like I said - reports from users. > Is it a fair, apples-to-apples comparison? No - these are reports from users, not a systematic analysis.
As a lead I'd love to use rust, I will put in the time on my own, my team won't or can't. They treat this like any other job they signed up to deliver value with what they know. For hiring not everyone has the talent pool and fund access to get the goat-ed engineers that congregate to tech hubs for maximizing their income. Then if you get through that cherry on top is LLM's are only as smart as you guide it to be. There is probably a staggering amount of ways to write 1 approach to business logic, you may not know the ideal pattern so you'll commit to a worse one on the company dollar.
I'm moving my team's projects slowly to go because, its easy to go from novice to advanced in terms of code writing,legibility and patterns. We also don't have deep ecosystem requirements to ts/python in most of our work. It is verbose but I don't mind that on token spend if it gets done with with validation/error handling which it obnoxiously enforces. It runs cheap, ecosystem is good for platform eng, standard library does a ton out of box.
Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.
except Rust is HARD while GO is super easy.
Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.
Earlier quoted context omitted.
Personally I find Rust a lot harder to read than Go. If you're going to have an agent write most of your code readability is very important.
I'll qualify this from my POV (which may be different than GP's). Go's historic maintainability strong suit has been its simplicity and consistency. The syntax is, relatively speaking, lightweight, the language invites complexity through composition, and information density for any unit of code is typically quite low (which isn't necessarily a bad thing). In my opinion, though, these are all drawbacks, and Rust addre…
Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LL…
| Go is Readable / Go is Maintainable
It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.
But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.
Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.
While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.
Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to cr…
- LLMs have clearly been trained on a lot of Rust as well
- Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build.
- If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than borrows, which makes most code dead simple.
- For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.