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.
/s
It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
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.
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.
For me it helped a lot to try to make containerized end-to-end tests and a custom TestMain for this, where I am using podman to run the integration tests. This way the end-to-end tests are forced to be on network level, and you can test protocol and API quirks much easier with LLMs.
Also, never forget to write a bootstrapping docs/ folder so that you don't have to re-explain these things all the time.
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?
But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}.
> can't you build your own validator for that with the reflect package in the Add() method of your UI graph
Besides the fact that that would almost certainly significantly hurt performance, how would you be able to differentiate between unitialized data and data that was intentionally set to the zero value?
Static analysis tools can catch this, no?
The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid criticism of the go type-system and language, and your comment doesn't hit on a valid solution.