[nicodjimenez]

Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but doesn't make sense for most applications because it complicates the development experience unnecessarily and monoliths are also easier to debug.

I would not use Golang for a big codebase with lots of business logic. Golang has not made a dent in Java usage at big companies, no large company is going to try replacing their Java codebases with Golang because there's no benefit, Java is almost as fast as Golang and has classes and actually has a richer set of concurrency primitives.

[wanderlust123]

I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions.

I think go needs some more functional aspects, like iterators and result type/pattern matching.

[robryan]

Go does have iterators: https://pkg.go.dev/iter

[wanderlust123]

Thanks! Did not see this until your message, looking forward to make use of this

[nicodjimenez]

The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.

[jen20]

It’s really not though. Plenty of systems are built in Go, Erlang etc that do not have the architectual monstrosities which commonly show up in object-oriented code, especially when a Java or C# expert beginner has been let loose.

[grey-area]

Microservices are entirely unrelated to classes and in no way endemic to go.

Go’s lack of inheritance is one of its bolder decisions and I think has been proven entirely correct in use.

Instead of the incidental complexity encouraged by pointless inheritance hierarchies we go back to structure which bundle data and behaviour and can compose them instead.

Favouring composition over inheritance is not a new idea nor did it come from the authors of Go.

Also the author of Java (Gosling) disagrees with you.

https://www.infoworld.com/article/2160788/why-extends-is-evi...

[nicodjimenez]

Microservices in Golang are definitely related to classes due to the ergonomic aspects of a language. It takes a lot of discipline in Golang not to end up with huge flat functions. Golang services are easier to reason about when they are small due to the lack of abstractions, also Golang is very quick to compile, so its natural to just add services to extend functionality. Code re-use is just a lot of work in Golang. Golang is not monolith friendly IMO.

[grey-area]

It really doesn’t.

Structs and interfaces replace classes just fine.

Reuse is really very easy and I use it for several monoliths currently. Have you tried any of the things you’re talking about with go?