@mrudokas @didier And that's why I avoid #Java. Even #Kotlin and #Scala already has way less boilerplate (but I still dislike it). Part of the problem is the language, other parts is the libraries - and the alternative #JVM languages only change one part of the equation.
Now you know why I prefer even #C++ over those. In C++ there's already way less boilerplate, and thus also way less efficiency of such tools. In fact I only ever get useful matches at all when writing code for a batch processing framework similar to #ApacheBeam.
Which has a REALLY nice #Go interface where stateless parallel functions can just be Go functions. No class/struct/whatever around it, no extra methods, no weird context objects, just pure functions from type A to type B. That's how I want things to be.
#Haskell also is a very good example, and in fact one of the languages with least amount of boilerplate I know.
Otherwise, the point is "my team does not have the power to change the existing ecosystem". We have projects to deliver, can't spend too much resources in creating better APIs to existing systems. We can do incremental improvements though - in C++ that is possible, in Java it is a lost cause.
