Both languages are extremely readable, even when looking at unfamiliar code.
The Zig standard library is small, yet covers a lot of common tools and structures. Every file contains implementations of one particular thing, so you can casually browse random files and understand what's going on without having to understand the entire context.
Couldn't disagree more in the Go case. Folder-level namespaces (rather than file-level) makes Go exceptionally annoying to navigate, and interfaces heavily obscure the.. interface between abstractions and implementations.
I'll +1 Zig code, but I came here to say this about Go as well. Once Go codebases creep past medium sized (25-50k LOC perhaps) into large I find them to be inscrutable. I've noticed this even in projects that people in the community point to as the gold standard such as the various HashiCorp tools.
I don't write much Go anymore but my hunch is that it's a combination of the package layout and auto method delegation for embedded structs. Even Java does a much better job of helping the developer at obviating the interfaces between different subsystems.
> Java basically does the same thing and I've never heard anyone complaining about that.
I don't love dealing with Java, but it has none of these particular issues. It's easy to find the definition of a class, because it enforces that the file path must match the fully qualified class name for all public classes (and this tends to be followed for privates as well in practice). Finding the implementation isn't quite trivial, but if you know a class in the tree then you can easily find the whole parent tree by following the "extends Foo" clauses, or find subclasses by grepping for it instead.
In my experience gopls hasn't been useful for much more than crashing.
But that aside, Go's incessant insistence on structural typing makes it impossible for any tool to generate a list that is both complete and free from false positives.
This is a massive generalisation. It is very easy to write bad code in any language.
Well, bad on a large scale. Go in particular has some nice tools to ensure code at a small scale is always good (enforcing syntax style), but no language can stop you from having a bad project architecture.
Go basically codifies a lot of best practices for writing C++ at Google, but I wouldn’t say it always teaches good code. Good Go would definitely help you learn how to write good systems code in any systems programming language though, and to be explicit/clear instead of terse.
But you can easily code yourself into a corner with Go too. If someone doesn’t know how to use concurrency well they can do bad things like overcreating goroutines or making a mess with channels. And some of the common patterns (particularly excessively overriding things) can be considered an anti pattern in terms of understanding (IMO)
Both languages are extremely readable, even when looking at unfamiliar code.
The Zig standard library is small, yet covers a lot of common tools and structures. Every file contains implementations of one particular thing, so you can casually browse random files and understand what's going on without having to understand the entire context.