I initially liked the idea of adding functional paradigms to the language, when the dust has settled all it does is create a sort of nasty Cronenberg language with most the drawbacks of both paradigms and few of the benefits of either.

Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support.

Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so.

The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).

Never blame people who try to solve real problems with your stuff. Better get your ego out of their way.

On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.

An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V>

Record types does make that a lot easier. They aren't quite as ad-hoc as in other languages, but this:

  record Foo(int a, String b) {}

  static final class Foo {
    private final int a;
    private final String b;
    public final Foo(int a, String b) {
      this.a = a;
      this.b = b;
    }
    public int a() {
      return a;
    }
    public String b() {
      return b;
    }
    public int hashCode() {
      return Objects.hashCode(a, b);
    }
    public boolean equals(Object o) {
      if (o == null) return false;
      if (o == this) return true;
      if (o instanceof Foo f) {
        return a == f.a && Objects.equals(b, f.b);
      }
      return false;
    }
    public String toString() {
      return getClass().getSimpleName() + "[ a = " + a + ", " + "b = " + b + "]";
    }
  }

What indeed caused breakage was the encapsulation effort that blocks unrestricted access to JVM internals, and that one was not even fully and forcibly turned on until Java 17.

You can see how such features are not super popular to the extent of widespread non-adoption of Java 11 even 10 years after its release.

Because FP is hard, and because it's easier to get 1000 Python monkeys to shit out half-baked garbage than it is to get 10 Haskell developers to agree on a set of blessed language extensions.

But when you get it right, your shit stops chewing a hole in itself in prod, and you can sleep at night and leave Slack alerts off over the weekend.

It's fine. Y'all can have your half-baked tire fires. "Industrial success" is a broken metric for "whether or not something is going to create real value for your product". We'll just keep shipping. And sleeping.

What a nice quote this will make :-)

PM me the name of who I should attribute this too.

Don’t get me wrong, I like Haskell and it is a more than fine language. Nonetheless, it doesn’t have anywhere close to the tooling Java has, and lazyness/FP is quite unintuitive regarding performance. And pure FP in itself is not guaranteed to result in better results by any form of evidence we have today, and doesn’t defend against logic bugs in any shape or form over what Java can do.

Also, it’s very unprofessional to look down on software engineers using different languages then you do..

it's a major red flag for me when giving or taking interviews.

Okay, when FP people get it right, they can let the rest of us know and we'll jump on the bandwagon.

Until they get it right[1], let the enterprise devs do what they need to without pouring scorn on them.

[1] For whatever meaning of "right" you have.

> monkeys to shit out half-baked garbage

> your shit stops chewing a hole in itself

> half-baked tire fires

Awesome. Terrifying, but awesome.

When do you actually ship though?

You kidding? The industrial success of the pure FP approach inspired by Haskell is that it has dragged all the other significant languages and frameworks to work in a more functional way, adding the constructs they lacked and popularizing the basic techniques.