I do not know about go ecosystem, but java and spring have mature solutions that cover the most advanced use cases.
But that's the thing with Java, yes there are libraries for everything and one could see that as a problem actually.
Spring was mentioned before, but it's the perfect example of an overengineered/ heavy library that does a lot of black magic.
Just the other day I ran across an issue where spring was wiring things up correctly on Linux but not Windows.
The pagination object is bulky and unnecessarily complex, where a simple offset/limit is enough (and a nextUrl for cursor-based access).
When we looked into cluster locks, they’re not even released if one node goes down. I mean, who would need a lock implementation that just stores a line in a DB? And the doc doesn’t even warn about it.
Apache contributors were much better-skilled.
Apache contributors were much better-skilled.
That is quite a broad statement. Two negative points about Apache Java libraries I can think of: The original "lang" libraries have not aged well at all. Also: The HTTP client libs are a fiasco. Very challenging APIs and weak documentation.With regard to this:
> But most enterprises that have a non-software focus generally prefer languages that have been around for a while and are known by lots of people.
I know developers who work for large blue chip financial sector and other traditional sectors. They’re on the same React/Vue/Webpack/whatever treadmill as all the frontend devs devs working at web dev agencies. And they’re often compiling it down from TypeScript, which has not been around for a very long while at all and is not known by lots of people (relative to the size of the JS community.
Swinging a bit of Go for a service in an environment like that isn’t really that hard.