What's new in Java 12, 13 and 14

I agree that's nice to have - essentially announcing events as special in the type system.

> good for inline optimization

Any optimisation here should be possible with an ordinary implementation of the observer pattern, no?

> it also provides a standard, much more intuitive syntax using formal function delegate declaration

I'm not convinced that it does. Without events, we can still write:

    var h = () => { doStuff(); doOtherStuff(); };
    subject.registerObserver(h);

I suspect we're both right, then: events were introduced for a good reason, but now that C# has lambdas and such, they don't seem to add much.

Absolutely true. When I've looked at that research, I was really quite impressed by how little has gone into looking into it, considering how interesting the subject is to so many people. My guess would be that it's because it's prohibitively expensive to study. That said, there was one result that I believe was shown to be fairly robust, and independent of language: that bug rate and cost are both generally proportional to lines of code written.

To that extent that that may be true, while I certainly don't have a $500,000 study by a team of professors at Stanford to back me, there's at least a plausible basis for my own perception of doing better work in object-oriented languages that do or do not have some sort of mixin mechanism: I find that using them often lets me get the same job done in less code. (Without that, I admit I have to retreat to pointing out that absence of evidence is not evidence of absence.)

There's also the design damage thing. Some developers on my team are quite resistant to using streams instead of loops in Java, and it's precisely because of the poor ergonomics. If you need to do an operation that isn't built into the Java API, you have some sub-par options: You can implement a collector, which is justifiably criticized as being a hassle (6 methods to implement) that yields code that scans poorly (every other verb is "collect"). Or you can implement a function, but using that function requires breaking the flow of the stream code by creating a bunch of intermediate variables, or, worse, constructing a pyramid of doom. By contrast, when we're working in Kotlin, you can just write a function and deploy it the same way you'd deploy any other method in its equivalent APIs. It's less effort, it's less code (read: stuff to get wrong), and, perhaps critically, it's a lot less annoying.

I am a long time Java programmer that has mostly programmed C# lately.

I'm getting more conservative by the years but I still found myself liking modern C#.

The thing I miss from Java is the ecosystem:

- three top notch IDEs

- more mature ecosystem

- maven

- with objects you can easily add new types, but it's difficult to add functions (methods) dealing with these types

- with sum types you can easily add new functions, but it's hard to add new variants in the sum type

Is it possible to overcome these limitations? I first read about the expression problem in the excellent post "The Expression Problem and its solutions"[1] on Eli Bendersky's blog (discussed here[2] on HN); as the title suggests it does present interesting ways to "solve" the expression problem.

However he also points out that the chosen solution in a a typical programming language (visitor pattern) quickly becomes unwieldy. The second solution (multimethods) is much nicer to deal with, but requires support from the language.

[0]: https://en.wikipedia.org/wiki/Expression_problem

[1]: https://eli.thegreenplace.net/2016/the-expression-problem-an...

[2]: https://news.ycombinator.com/item?id=11683379