> Golang

golang is probably a good contender for business logic code where Java is widely used, but I feel ecosystem (libs, integrations) is not comparable to Java, so you take some risks while choosing golang.

I have not used Go generics, but it's viability as a business logic language would depend on that.

Wait, what?

Generic programming is a perfectly valid style, but are you saying it's essential to implement business logic?

Because, like, the last 3 languages that got adopted as the default business logic language didn't have them (Java pre 1.5, C, and Cobol).

and during last 20 years consensus has converged to the view point that generics are essential.

Huh. Guess I'm heterodox, then.

I mean, don't get me wrong. It's quite useful once in a while, especially when working with containers, but I don't think of it as essential.

But I'm fine with it as long as people don't overdo it.

Rolling your own containers really really sucks. Sucks enough to the point that it is essential, in my books.

Maybe I should be more clear.

This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language.

Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything.

Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.

It is not essential, but without it, it is much more cumbersome. I programmed it with Java so I know it can be done but I would not choose a language without it if I could.

It is absolutely necessary nowadays, yes. Our applications are often more complex than what people did in Java 1.5, Cobol, or C, and definitely need to be developed at a faster pace.

they have generics now, but there are other conceptual shifts:

- no inheritance

- error codes with explicit handling everywhere

no inheritance but there are interfaces to be able to provide alternate implementations. Similar to traits in Rust. If it quacks like a duck, has feathers like a duck, swims like a duck…

Go just assumes if you satisfy the interface, you’re good.

maybe, it is just some effort for someone who coded in classic OO for last 20 years to wrap head around this new concept fast and judge if it will satisfy all/most use cases.

Yes those are also drawbacks

And it is much more verbose, it is not even comparable in observability and on real world big applications (especially enterprise) you can't get away with value types and slowing down the threads to let the GC keep up with them -- Java definitely shines in these kind of conditions (GC-wise the only competition Java has is different Java GCs, really).

> you can't get away with value types and slowing down the threads to let the GC keep up with them

I am not Go expert, but to me this is Go's big advantage: you can chose you want to have object GC controlled or be on stack and copied everywhere. GC controlled objects add lots of overhead, because malloc is expensive, and require lots of memory per object to track state and synchronize between thread, and that's why JVM tries to adapt something similar: https://openjdk.org/jeps/8277163

Sure, value types are a good thing, but they are no panacea in and of itself.

Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.

> they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it

yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all.

With value objects you have full control and bare-metal-native performance without compromises.

> you have full control and bare-metal-native performance without compromises.

Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.

as soon as you copy your struct by value around, it is easy task for escape analysis to decide to put struct on stack.

also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.

Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways.

Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.

> Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways.

I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap.

> Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.

Thank you, good to know, looks like big pros in favor of rust as lang for my next project.

golang is a simplistic language which lacks the modeling capability of Java, so it won't do well in large business code.

TIL that projects like terraform are - apparently - not "large business code".

You can write basically anything in any Turing complete language, doesn't mean it's a good idea.