The biggest win for Go is its approach based on composition rather than inheritance.
There isn’t any “architect engineer” building cathedrals with interfaces and abstract classes. There’s no cult behind needing to follow DDD in an event-driven architecture powered by a hexagonal architecture in all projects, or you are tagged as a bad engineer. We don’t have thousands of traits to define every possible code interaction, yes. From a type system point of view, Go is lacking compared to HM based type system, yes. Yes, it’s all pros and cons with this decision. We can agree on that.
I’ve seen that the predominant enemy for a software project is software engineers. Go keeps them in line for the sake of the project.
> There isn’t any “architect engineer” building cathedrals with interfaces and abstract classes. There’s no cult behind needing to follow DDD in an event-driven architecture powered by a hexagonal architecture in all projects, or you are tagged as a bad engineer.
Isn't Go the big driver of Kubernetes? It feels like overarchitecturing is still there in Go projects, they've just made it distributed.
I’ve read comments from people before about how go’s lack of generics has caused significant amounts of extra code to be written in the K8s codebase. I do wonder if we could snap our fingers and magically have a K8s written in Rust, a lisp, Zig tomorrow, what that would look like, what it would be like to maintain and build and what the codebases would be like in comparison. Would make an interesting intellectual exercise.
> There isn’t any “architect engineer” building cathedrals with interfaces and abstract classes. There’s no cult behind needing to follow DDD in an event-driven architecture powered by a hexagonal architecture in all projects, or you are tagged as a bad engineer.
My experience is that you can also write simple non-over-engineered code in other languages too. Yes, it can require pushing against the wind of the prevailing culture sometimes but it's not, like, impossible.
If one chunk of code depends upon one and only one other chunk of code, then forcing the programmer to put an interface between them for unit testing does a disservice to the programmer.
I really do prefer languages that make it easy to write unit tests.
There isn’t any “architect engineer” building cathedrals with interfaces and abstract classes. There’s no cult behind needing to follow DDD in an event-driven architecture powered by a hexagonal architecture in all projects, or you are tagged as a bad engineer. We don’t have thousands of traits to define every possible code interaction, yes. From a type system point of view, Go is lacking compared to HM based type system, yes. Yes, it’s all pros and cons with this decision. We can agree on that.
I’ve seen that the predominant enemy for a software project is software engineers. Go keeps them in line for the sake of the project.