"Oreo cookies are the tastiest cookies currently in the market!" ~ Oreo cookie company.
Oreos are an ideal cookie in a milkshake machine fast food era
Go is an ideal language for AI-assisted software engineering
311–320 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#312I think the right language for agentic coding is something that brings in more ideas from formal verification, in a way where the spec and executable code live in the same world. I don't really know what that will look like but that's my gut feeling as a non-expert. Specs can be written in a higher level language (not english) that verifies the lower level code at compile time. I think Dafny might be the closest we have at the moment.
Re: Go is an ideal language for AI-assisted software engineering
#313Definitely 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 is heavily opinionated on style, design, and semantics. Its design was around being as concise as possible…which means token efficient.
Yeah Go is my preferred language to code with AI. Second up is type script. Followed by Java, then Python.
Re: Go is an ideal language for AI-assisted software engineering
#314Earlier quoted context omitted.
> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...] That's a pile of bollocks, pardon my French. Source/proof? And to the contrary: I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written. Over these last six months we had four use-after-free…
The problem with ownership tracking is that it's global. Humans are bad with global things, linters too, but LLMs are exceptionally bad at them due to the context window and (currently, at least) not knowing enough where to search. So yes I'd expect them to make the same mistakes as human and even more frequently.
I feel like LLMs and vibe coding have opened up rust to the kind of script kiddie who would previously have been begging for help on r/javascript or whatever.
If there is a problem with global lifetimes then the problem is certainly the person driving (or not) the LLM. Global lifetimes? FFS. Rust is hard because writing services that don’t have bugs is hard.
LLMs are not currently able to vibe a sophisticated application or service in rust. If it tells you it can do it in typescript or python, the it most likely certainly has not and you will have a wonderful time in production. Rust will burst that bubble.
Re: Go is an ideal language for AI-assisted software engineering
#315Seems to me the ideal language for AI has not been created yet.
Re: Go is an ideal language for AI-assisted software engineering
#316Earlier 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…
> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…
Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.
Re: Go is an ideal language for AI-assisted software engineering
#317Definitely 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 is heavily opinionated on style, design, and semantics. Its design was around being as concise as possible…which means token efficient. Yeah Go is my preferred language to code with AI. Second up is type script. Followed by Java, then Python.
Go design is not around being concise as possible, in fact it's the complete opposite.
One of the cores behind Go is to make language simple, even if at the expense of more verbose code.
Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
Re: Go is an ideal language for AI-assisted software engineering
#318Earlier 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…
The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…
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, and they can make mistakes in just the same way.
Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.
Re: Go is an ideal language for AI-assisted software engineering
#319Earlier quoted context omitted.
This is the actual link to the academic paper ( https://arxiv.org/pdf/2204.00764 )
Just reading the abstract, it talks about finding a number of bugs (across millions of lines of code) but I didn't see any claims that there would be fewer bugs in a different language. Go obviously does not stop you from writing buggy code. Neither does rust or zig or whatever. Does go make it more likely to have bugs? Or a specific class of bug? Like, the real world is about trade offs.
Uber has fairly large golang and java codebases so they have more of an apple to apples comparison here since they are both GC languages of a similar performance class. And if a large population tends to make more mistakes with 200hp sedan A vs 200hp sedan B, there is probably something up with the design of sedan A.
Re: Go is an ideal language for AI-assisted software engineering
#320Seems to me the ideal language for AI has not been created yet.
It's hard for me to imagine that the 'ideal' language for AI would even be readable by humans at all. Left to their own devices, these systems seem to make up their own way of communicating ideas.