These are great idioms for writing code in any language.
I'm no longer a fan of Go but still a fan of many of the people the work with it because they also value many of these things.
I'm no longer a fan of Go but still a fan of many of the people the work with it because they also value many of these things.
I invested a lot of time and work in the language (about 4 years professionally) but become disillusioned with it over time.
The big reasons for no longer liking the language stem from decisions made around the type system (this being the main reason), tooling (namely packaging, vendoring/modules bleh) and weariness with the verbosity and logic per line density.
So when would I still pick it?
I would pick Go if I specifically need to shuffle bytes between sockets with high I/O concurrency and don't need access to C libraries or any complex logic at all. The moment there is business logic I don't want to be writing Go anymore.
[1] https://github.com/kstenerud/go
What do you prefer for writing business logic type apps then?
In particular I find it's generics, data classes, infix operators and extension functions very useful for expressing business logic concisely.
These features let me write half (or less in many cases) the code I might need to in Go.
More importantly is Kotlin is much easier to refactor. Part of that is there is just less code to refactor, the other important piece is tooling and IDE providing awesome automatic refactoring tools.
Can you expand on your objection to the new Go module design?
Have you tried the "cgo" facility and found it lacking? If so, how?
Using cgo has been the source of near endless pain for me when writing systems software. It criples portability, drastically changes runtime behaviours and generally is best dealt with by CGO_ENABLED=0.