3 ms·

> Replacing current courtoutine implementation to use Loom threads or inline classes to use Valhalla are both implementation details that should not at all chan

by pron 6y ago

> Replacing current courtoutine implementation to use Loom threads or inline classes to use Valhalla are both implementation details that should not at all change the user facing API and complexity. This is not accurate. Re Loom, the entire Java platform will be built around a "single colour" structure. Kotlin, like C#, is based on a split, two-colour, model. It is true that under the covers it could map both colours onto the same one, but that will mean that Kotlin adds a lot of unnecessary complexity, and possibly make it harder to target multiple platforms (i.e. a lot of Kotlin code that will work well on Java will not work well on Android or JS). Re Valhalla, it will allow multi-component inline types -- that's a user-facing change -- but those won't work on Android, at least not without significant overhead.

Nullabillity 6y ago
> Re Loom, the entire Java platform will be built around a "single colour" structure. Kotlin, like C#, is based on a split, two-colour, model. It is true that under the covers it could map both colours onto the same one, but that will mean that Kotlin adds a lot of unnecessary complexity, and possibly make it harder to target multiple platforms (i.e. a lot of Kotlin code that will work well on Java will not work well on Android or JS). Function colours are a useful modelling tool regardless of whether the underlying platform requires it. That's sort of like saying "everything is eventually just bytes anyway, so types are unnecessary complexity". Of course, there are languages trying flatten everything into a single type. But personally, I'd rather not be programming PHP when there are better options available. > Re Valhalla, it will allow multi-component inline types -- that's a user-facing change -- but those won't work on Android, at least not without significant overhead. Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android".
- pron 6y ago
  > Function colours are a useful modelling tool regardless of whether the underlying platform requires it. Without getting into the debate over what valuable information the "async" colour communicates on a platform where, unlike in JS, global state changes could occur at any time due to thread concurrency, any thread can be suspended by either the VM or the OS at any point for any duration, and "async" is no cheaper than "sync", the more practical problem is that Kotlin does not know what colour the platform's operations are. This means that some arbitrary mixing of colours would work on one platform but might not on another. I know some two-colour frameworks use BlockHound, a dynamic "colour detection" tool, but even as a dynamic tool and even today BlockHound sometimes gives wrong results because it doesn't keep up with the frequent changes to the platform. > Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android". Because it's not about libraries or versions you can upgrade but core language capabilities that differ by platform. It could be acceptable, but it means that there are different Kotlins for different targets. We get a language whose both syntax and/or behaviour differs by platform, and isn't a first-class citizen on any but one of them.
joshlemer 6y ago
I've never heard of this "single-colour" / "two-colour" distinction, do you have a link with more information? Thanks!
- ragnese 6y ago
  http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Async/suspend functions are one color, and "normal" functions are another.
  - reducesuffering 6y ago
    Further, from reading TFA, one colour would mean only "normal" functions, correct?
    - ragnese 6y ago
      That's my understanding, yes.
- deleted 6y ago
  [deleted]
jayd16 6y ago
Agreed, although I don't want to go so far as to say color is that intrinsic but they are different features with different goals. Loom is about many blocking green threads that are scheduled without you thinking about it. Coroutines are meant to support UI programming where you deal with a marshaling the app flow to and from a main thread. Coroutines are more verbose but they handle different use cases than Loom. That said, Kotlin coroutines are just a library anyway. Its a dependency change not a language change to swap out the implementation.

by pron 6y ago

Nullabillity 6y ago

> Re Loom, the entire Java platform will be built around a "single colour" structure. Kotlin, like C#, is based on a split, two-colour, model. It is true that under the covers it could map both colours onto the same one, but that will mean that Kotlin adds a lot of unnecessary complexity, and possibly make it harder to target multiple platforms (i.e. a lot of Kotlin code that will work well on Java will not work well on Android or JS). Function colours are a useful modelling tool regardless of whether the underlying platform requires it. That's sort of like saying "everything is eventually just bytes anyway, so types are unnecessary complexity". Of course, there are languages trying flatten everything into a single type. But personally, I'd rather not be programming PHP when there are better options available. > Re Valhalla, it will allow multi-component inline types -- that's a user-facing change -- but those won't work on Android, at least not without significant overhead. Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android".

pron 6y ago
> Function colours are a useful modelling tool regardless of whether the underlying platform requires it. Without getting into the debate over what valuable information the "async" colour communicates on a platform where, unlike in JS, global state changes could occur at any time due to thread concurrency, any thread can be suspended by either the VM or the OS at any point for any duration, and "async" is no cheaper than "sync", the more practical problem is that Kotlin does not know what colour the platform's operations are. This means that some arbitrary mixing of colours would work on one platform but might not on another. I know some two-colour frameworks use BlockHound, a dynamic "colour detection" tool, but even as a dynamic tool and even today BlockHound sometimes gives wrong results because it doesn't keep up with the frequent changes to the platform. > Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android". Because it's not about libraries or versions you can upgrade but core language capabilities that differ by platform. It could be acceptable, but it means that there are different Kotlins for different targets. We get a language whose both syntax and/or behaviour differs by platform, and isn't a first-class citizen on any but one of them.

joshlemer 6y ago

I've never heard of this "single-colour" / "two-colour" distinction, do you have a link with more information? Thanks!

ragnese 6y ago
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Async/suspend functions are one color, and "normal" functions are another.
- reducesuffering 6y ago
  Further, from reading TFA, one colour would mean only "normal" functions, correct?
  - ragnese 6y ago
    That's my understanding, yes.
deleted 6y ago
[deleted]

jayd16 6y ago

Agreed, although I don't want to go so far as to say color is that intrinsic but they are different features with different goals. Loom is about many blocking green threads that are scheduled without you thinking about it. Coroutines are meant to support UI programming where you deal with a marshaling the app flow to and from a main thread. Coroutines are more verbose but they handle different use cases than Loom. That said, Kotlin coroutines are just a library anyway. Its a dependency change not a language change to swap out the implementation.