alt Hacker NewsIt 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 squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache.
An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.
Replies
Good point.
It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.
With test, which LLM are good at writing, you can reduce this tremendously. Even Rust won't protect you in this case, remember the cloudflare outage. At the end it is not the language, it is you intrinsic ability to architecture well your software from there any LLM can do the work.
Very good point, thanks for confirming that! What is the reasoning behind the Go design choices you described?
So your problem is the default/zero values of properties?
In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties.
Also can't you build your own validator for that with the reflect package in the Add() method of your UI graph to prevent this sorta thing?
Fair criticism, it's my main gripe with Go as well - it's not strict enough when it comes to e.g. nil, enums, and type safety. Annotations are supported but they're just strings. Projects require additional tooling / linters to check for things like unchecked errors and many more "gotchas" that I think could (should?) be part of the compiler or standard tools. Trivial example, Go's compiler will error when you have an unused variable, but won't if you reuse and overwrite an error variable a dozen times and only handle it once.
But on the other hand, I suppose it makes it a bit more pragmatic - less checks makes for a faster compiler, and fast compilation was/is very high up in the language's requirements and motivation. If you want / need more strictness in your language, there's Rust, Java, C#, etc.