3 ms·

I think you might be right. But isn't this just the general risk of dealing with a "stagnated language/tooling"? Either you wait for it to go out of sleep mode

I think you might be right. But isn't this just the general risk of dealing with a "stagnated language/tooling"? Either you wait for it to go out of sleep mode and catch up. This might never happen, and is thereby a risk. Or you fork off to your new system which attempts to fix the issues you observed. This might require a serious investment. And maybe it's not useful in the future, since the original tool might catch up and most of the people will stick with it. So now you evaluate the 2 options in terms of risk and short/mid/long-term benefits as usual. And I think the Kotlin designers and all users which jumped onto the platform made a sensible choice. I really love the idea behind loom - but it's still not generally available. Kotlin coroutines are, and imho solved sane concurrency for mainstream users. If I would have to write a massively concurrent application on the JVM about 1-2years ago, Kotlin could certainly have been my way to go. In 1-2 years it might be Java+Loom. Last but not least I would like to point out that Kotlin is extremely well designed. Imho it's coroutine system is the best in industry right now. It's extremely configurable, and the inclusion of structured concurrency right from the start to encourage good designs makes a lot of sense! I would not be suprised if Kotlins designers already have decent plans on "what do we do if Java integrates Valhalla/Loom/etc"? And I think it's pure existence pushes the standards, and has a positive impact on the design of Java and other languages.

pron 6y ago
> And I think the Kotlin designers and all users which jumped onto the platform made a sensible choice. Oh, absolutely! And don't get me wrong, I think Kotlin was the right thing to do ten years ago -- Java was not in a great shape back then (in fact, Sun drastically cut investment in the core platform) -- and maybe even five years ago. I also think it was very well designed -- very much in the "Java spirit" -- although I think it's taken things a bit too far recently for my taste. > Imho it's coroutine system is the best in industry right now. I think that coroutines for a platform that's already designed around multi-threading are a bad idea altogether (this goes for C# as well) unless the language has some very specific constraints, like C++/Rust. Some might disagree, but I don't think those would be people who've had experience with Erlang or Go (although those platforms, like all platforms -- including Java, of course -- have their own problems). Nevertheless, for quite a few it's certainly better than nothing. > I would not be suprised if Kotlins designers already have decent plans on "what do we do if Java integrates Valhalla/Loom/etc"? I'm sure they do, and I'm sure their solutions would be great, but they'll need to sacrifice some of their goals. In any event, it is no longer the "there's nothing to lose" proposition it used to be. > And I think it's pure existence pushes the standards, and has a positive impact on the design of Java and other languages. Maybe, although Java (the language) has so far taken little if anything from Kotlin (most of the inspiration to recent work has come from ML, and even Scala to some degree). If there is one Kotlin feature that I think might ultimately make its way to the Java language it would probably be nullability types; I think that that's its most impactful contribution to the design of other languages, too. What mostly pushed Java forward in recent years is the increased investment by Oracle, and competition from other platforms. If I were to pick a positive impact Kotlin has already had on the Java language, it is perhaps demonstrating that there is appetite among programmers in more conservative languages (as opposed to Scala and Haskell programmers) for new language features beyond lambdas.
- Matthias247 6y ago
  > I think that coroutines for a platform that's already designed around multi-threading are a bad idea altogether (this goes for C# as well) unless the language has some very specific constraints, I would actually go one-step further on this: Async processing on a platform that is designed around multi-threading is a bad idea. I think pure multithreaded programs are fine (although data-race and deadlock prone, but tooling like thread-sanitizers and Rust can help here). Pure async (something callback-like) programs are fine. The mixture is pure hell. If I see a multithreaded library which takes a callback, I'm sure 95% of its end users are using it wrong, and are not even aware on which thread the callback will be invoked. This number is based on publishing such libraries, as well as leading teams with junior engineers trying to use them. So it would be great to avoid to use that idiom at all. However the reality is that on platforms like Java and C# those are already reality. We have mainloops, GUI eventloops and networking eventloops where all code is bound to a certain thread and can not be executed somewhere else. So either we rewrite those, or we find a paradigm which makes life somewhat easier for them. And I think coroutines do that - at least you are sure the continuation brings you back to the same thread/execution-context you can been before (unless you overwrite it with one of the million and sometimes non-obvious settings). Therefore I think they are beneficial. It might be nicer to get rid of async-processing at all, but that would require the development of new UI frameworks which follow different idioms. One interesting question is however: Are they actually a good fit for Rust - where common async idioms don't fit well anyway due to borrow-checking, and the main use-case at the moment are request-based network applications instead of UI frameworks. I don't have a clear answer for that one yet. I think in a lot of ways stackful coroutines (virtual threads) might have been a lot easier to deal with. But I also understand the desire to not to have a runtime.
  - pron 6y ago
    C++ and Rust are low-level (or "high control") languages with constraints and goals specific to such languages. For example, they frequently interact with C and so they leak implementation details (like stack addresses); they have lots of pointers into the stack; heap allocation is relatively costly and requires explicit bookkeeping and management; they prefer constructs with well-known worst-case costs even for the price of having low abstraction (“high abstraction” being representing many similar things with one construct, even if they differ in implementation). My point being that the design constraints for low-level and high-level languages are very different, and what's good for one is often bad for the other.

pron 6y ago

> And I think the Kotlin designers and all users which jumped onto the platform made a sensible choice. Oh, absolutely! And don't get me wrong, I think Kotlin was the right thing to do ten years ago -- Java was not in a great shape back then (in fact, Sun drastically cut investment in the core platform) -- and maybe even five years ago. I also think it was very well designed -- very much in the "Java spirit" -- although I think it's taken things a bit too far recently for my taste. > Imho it's coroutine system is the best in industry right now. I think that coroutines for a platform that's already designed around multi-threading are a bad idea altogether (this goes for C# as well) unless the language has some very specific constraints, like C++/Rust. Some might disagree, but I don't think those would be people who've had experience with Erlang or Go (although those platforms, like all platforms -- including Java, of course -- have their own problems). Nevertheless, for quite a few it's certainly better than nothing. > I would not be suprised if Kotlins designers already have decent plans on "what do we do if Java integrates Valhalla/Loom/etc"? I'm sure they do, and I'm sure their solutions would be great, but they'll need to sacrifice some of their goals. In any event, it is no longer the "there's nothing to lose" proposition it used to be. > And I think it's pure existence pushes the standards, and has a positive impact on the design of Java and other languages. Maybe, although Java (the language) has so far taken little if anything from Kotlin (most of the inspiration to recent work has come from ML, and even Scala to some degree). If there is one Kotlin feature that I think might ultimately make its way to the Java language it would probably be nullability types; I think that that's its most impactful contribution to the design of other languages, too. What mostly pushed Java forward in recent years is the increased investment by Oracle, and competition from other platforms. If I were to pick a positive impact Kotlin has already had on the Java language, it is perhaps demonstrating that there is appetite among programmers in more conservative languages (as opposed to Scala and Haskell programmers) for new language features beyond lambdas.

Matthias247 6y ago
> I think that coroutines for a platform that's already designed around multi-threading are a bad idea altogether (this goes for C# as well) unless the language has some very specific constraints, I would actually go one-step further on this: Async processing on a platform that is designed around multi-threading is a bad idea. I think pure multithreaded programs are fine (although data-race and deadlock prone, but tooling like thread-sanitizers and Rust can help here). Pure async (something callback-like) programs are fine. The mixture is pure hell. If I see a multithreaded library which takes a callback, I'm sure 95% of its end users are using it wrong, and are not even aware on which thread the callback will be invoked. This number is based on publishing such libraries, as well as leading teams with junior engineers trying to use them. So it would be great to avoid to use that idiom at all. However the reality is that on platforms like Java and C# those are already reality. We have mainloops, GUI eventloops and networking eventloops where all code is bound to a certain thread and can not be executed somewhere else. So either we rewrite those, or we find a paradigm which makes life somewhat easier for them. And I think coroutines do that - at least you are sure the continuation brings you back to the same thread/execution-context you can been before (unless you overwrite it with one of the million and sometimes non-obvious settings). Therefore I think they are beneficial. It might be nicer to get rid of async-processing at all, but that would require the development of new UI frameworks which follow different idioms. One interesting question is however: Are they actually a good fit for Rust - where common async idioms don't fit well anyway due to borrow-checking, and the main use-case at the moment are request-based network applications instead of UI frameworks. I don't have a clear answer for that one yet. I think in a lot of ways stackful coroutines (virtual threads) might have been a lot easier to deal with. But I also understand the desire to not to have a runtime.
- pron 6y ago
  C++ and Rust are low-level (or "high control") languages with constraints and goals specific to such languages. For example, they frequently interact with C and so they leak implementation details (like stack addresses); they have lots of pointers into the stack; heap allocation is relatively costly and requires explicit bookkeeping and management; they prefer constructs with well-known worst-case costs even for the price of having low abstraction (“high abstraction” being representing many similar things with one construct, even if they differ in implementation). My point being that the design constraints for low-level and high-level languages are very different, and what's good for one is often bad for the other.