Javaslang VS StreamEx

If you want to cut down on code verbosity in Java, I recommend instead looking into using Java 17 (records), and/or the Vavr library (port of some Scala standard library approaches to Java). https://github.com/vavr-io/vavr

If I managed to gain you interest you can take a look at one of the following libraries like cats, scalaz for scala and vavr for java which contain type class definitions and implementations for common types.

I'm aware not everyone likes it, but vavr has these.

https://github.com/vavr-io/vavr/releases showed Vavr 0.10.4 from July 2021 as latest release. 🤷

I would like to see a more fully-functional tool set available in Java itself. (Functors, Applicatives, Monads, Arrows, and more) Vavr is kind of doing that, but also kind of not really. Scala has all of that, and Scala is fun for sure, but it brings in a lot of baggage for interop. (Sometimes that's not a great choice, e.g. for an old legacy project)

Functional Programming is becoming more and more popular. Spring provides a couple of DSLs for the Kotlin language. For example, the Beans DSL and the Routes DSL allow for a more functional approach toward Spring configuration. On the type side, Vavr (previously Javaslang) is pretty popular in Java, while Kotlin has Arrow.

Or perhaps they could implement it like String. String has mutators but they don’t change the original value. To get the modified one, assign it to another variable. Another example is the collection framework of vavr.

I really like StreamEx. I do not know why people do not use it often, the syntax is just wonderful.

It gets more perverse if you need to flatMap, or transmute components of map types, etc. If you want even more power, take a look at https://github.com/amaembo/streamex. This sort of container manipulation bread and butter for business processing. I use it every day, sometimes with a dozen operations. This (with liberal use of `final` values) makes for some pretty functional-looking code.

I'll grant you the Kotlin or Scala version is slightly more compact. But not fundamentally different, like the Go version.

I (and the pretty much every language designer in the post-Java era) disagree with you about checked exceptions, but that's a whole different thread...