What about project loom? Will that not solve this case providing you start the server with a virtual thread pool?
I guess thats what he was getting at however, not having to do that.
I guess thats what he was getting at however, not having to do that.
Go’s library is sometimes overly terse, but after having experienced both in production, I much prefer Go’s style.
An example is one of the date parsing functions (I can’t remember details now) which will happily accept an invalid date string (eg 2021-02-35) and silently convert it to a valid date (2021-03-07) despite declaring a parsing Exception.
You see, you only get the exception if you call setLenient(false) or if the date string can’t be coerced. For the life of me, I cannot think of a use case for this behaviour, and it certainly violates the principle of least surprise.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
https://www.infoworld.com/article/2073649/why-extends-is-evi...
As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
From the article:
> Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
Key words: preferable, and whenever possible. It's sometimes preferable to have inheritance and not possible to leave it out without unneeded extra complexity.
Furthermore, nowadays interfaces in Java (as well as Kotlin, Scala, C# - all of which are much more expressive and have superior modeling capability than golang) can have default implementations, which increases their application even more and reduces the need for explicit inheritance. Not so in golang since interfaces cannot have default implementations there.
> As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
Not quite, it's just where having inheritance would have simplified the design, and improved readability.
Again on interfaces, sometimes less is more. Many people prefer the inverted interfaces of go, declared at point of use. It’s fine to prefer the opposite, but these are deliberate choices, not mistakes or failures.
Re inheritance simplifying a design, it does the opposite in my experience, unless by simplify you mean hide program flow and state.
At the end of the day, golang has classes also whether they care to admit it or not.
But yes, Go is definitely worse in that respect, not better.
Optimistically we may be able to answer op's question sometime in 2024.