…in the calling code, not the implementing code. Which is why I provided a minimal implementation just to prove that eliminating any boilerplate in the calling code is possible to the same extent like in C#. I explicitly made it a point to describe my implementation as “extremely basic”, I honestly didn’t think that anyone would expect a fully fleshed-out, production ready library there.
Yes, anything Kotlin does can be achieved with pure Java somehow, but only by jumping through lots of hoops and drastically reducing readability and maintainability. In the case we’re discussing, additional language support could not give us a much more readable syntax for events than libraries written in pure Kotlin can.
You’ll do that anyway. As you yourself say in the next paragraph:
And those who want something else will be plenty, even with existing language support. There will still be lots of Rx you’d need to connect to, other Reactive Streams implementations, event busses, callback-based libraries etc. Those aren’t going away by introducing language-level support, if anything, it’s going to get worse. Reminds me of this relevant xkcd.
Nope. Well, yes, but the way it is now, those are usually things the Framework you’re working in already provides. Android has it’s OnClickListeners, JavaFX has EventHandlers. And as long as you’re not looking at Kotlin-only frameworks, none of them will use a language-level events-system unless JetBrains outdo themselves and provide excellent interop with Java for them. And even if that was the case, the chances of existing frameworks to switch over are pretty slim. So again, that would leave us with just another events-system that needs to be bridged into all the other ones already existing. I agree the existing solutions, like Android, are a mess for the most part, but language support in Kotlin won’t help that for the foreseeable future.
Yeah, I’ll give you that, performance definitely is a thing to consider with Rx. But you could easily use a much more barebones and lightweight events library and would come pretty close to a language-level implementation. Anything beyond that would be premature optimization in all but the most performance-critical applications, and at that point, you should probably be asking yourself if the JVM is the right platform to develop your application on.
While coroutines themselves are irrelevant, the approach taken in their design as a language feature is indeed very relevant, I think.
To summarize: Right tool for the right job. No point in building a 5mm crosstip screwdriver into the language, when lots of users will need a 2mm or 9mm, or even a slotted or double-square.