As expected Google completely forgets about it’s other language, Dart
Go is an ideal language for AI-assisted software engineering
481–490 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#482Earlier quoted context omitted.
Literally within this thread someone has already suggested using ruff instead of Black and nobody here are colleagues.
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.
Do you feel that this could equally apply to a Rust vs Go argument?
Re: Go is an ideal language for AI-assisted software engineering
#483Earlier quoted context omitted.
Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea
What is UB?
UB stands for undefined behavior—I've written about it in detail on my homepage[1]
[1]https://www.makonea.com/en-US/wiki/undefined-behavior
Re: Go is an ideal language for AI-assisted software engineering
#484My gut feeling would be that most of not all of the points apply to Rust as well, and even more so. Rust's compiler is famously strict, the whole language and tooling is designed to catch footguns early, and it's less verbose than Go, meaning you can fit larger codebases into a given context window.
Re: Go is an ideal language for AI-assisted software engineering
#485My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. 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 thi…
Python is great as a dynamic language, but I find very few things about are easy to reason conclusively about because the state of the running program can be so crazy (has pros and cons). But it probably depends at what level you are working in python and how deeply you understand it. Type checking and linting help a lot to keep the truly crazy contained, but it's just fundamentally a very difficult system to trust. Not to mention working around the GIL is fairly inefficient.
Re: Go is an ideal language for AI-assisted software engineering
#486It 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…
>> Nil and partially constructed structs
C# has "nullable reference types" and "required" keyword for that
Re: Go is an ideal language for AI-assisted software engineering
#487Earlier 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.
It was and is a logical argument. Both C and Rust are much harder to learn.
Considering the article was about usage for development by LLM, the learning difficulty should be a minor factor.
Re: Go is an ideal language for AI-assisted software engineering
#488Earlier quoted context omitted.
Having run a fleet of 100s of etcd clusters for 10000s of rps, and the fact that upstream runs tests similar to antithesis and recently partnered with antithesis [0], and jepsen has tested it long ago as well [1]. Etcd's raft algorithm is fine. Someone even did a TLA+ proof on it in the last couple years[2]. Yes there was a correctness issue a few years ago but otherwise the person you're replying to doesn't know wha…
doesnt raft have a problem that it assumes no hysteresis? and that in general you can construct a latency graph that deterministically causes a permanent lock in the leadership election phase?
I'm not sure I fully understand your question, but the heartbeat time outs and leader election time outs are static. And yeah if you make votes and heartbeats time out in a way that nobody can be elected, then raft can't make progress.
I've never had this be a problem in reality but AWS has a pretty good backbone. Maybe if you were running it over a pretty unreliable network this would be an issue?
Re: Go is an ideal language for AI-assisted software engineering
#489Earlier quoted context omitted.
Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
Not panicking doesn’t mean working as intended, the biggest issue with LLM generated code is that it will do something that’s subtly wrong not that it will crash. It anything LLMs are too careful with Golang code and litter useless nil checks everywhere e.g. for function calls with pointer receivers. That whole fear of panics is totally overblown.
Sure, rust has better memory safety than most languages, but it also has a strong enough type system that many other kinds of programming errors won't pass compilation.
Re: Go is an ideal language for AI-assisted software engineering
#490My calculus is very simple these days: If I care about performance, use Rust. If I care about iteration speed, use TypeScript. If I want a script or numerical code, use Python. LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrai…
You're not considering one of the important factors, token usage. Rust is a complex language and burns through tokens compared to Go.
Python is good with tokens, but why would you use an interpreted language when you don't write the code. Same with TypeScript. Compile it.
I see language choice as only two now: Go or Rust.
Go for most systems, Rust for high performance.