Hacker News Reader

Comment by moomin | Hacker News Reader

The authors make some good points: compile time and test speed matter, platforms matter. But they really dodge the whole “guardrails matter” thing. And guardrails are going to win long term.

As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour.

View on HN

> "guardrails matter" This thing has been solved in the 70s. Basically, have a powerful type system, and a compiler that beats you into submission when you try to stray from the straight and narrow. Languages like (S/OCa)ML, Haskell and Rust will bring this to you. As a consequence, you fight the compiler, and once it submits, you have a good chance it's going to work. The compiler is also the ultimate refactoring tool here. Change the concept? Just change the type in the code and follow through by fixing the error messages the compiler spits out.

Of those, the weakest points for Haskell and the MLs is the platform and documentation. However, I don’t know if we can call this solved just yet. We may need to invent whole new types of guardrail.

> As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour.

There's just not many ways of writing Go. It's a very dull language. It was designed to be dull and easily understandable.

but there are a whole lot of ways you can mess up a dull language, like shitty variable names, bad code organization, etc.

if an llm has learned dumb things from dumb users it could disproportionately cause provlems versus other languages, just by being "in a sloppy mood" when writing go.

Reply on news.ycombinator.com