4 ms·

IMO Java has learned from the mistakes of C# as well. See Task<T> vs Loom's virtual threads. Brian Goetz (the Java language architect) himself even said they're

by vips7L 6y ago

IMO Java has learned from the mistakes of C# as well. See Task<T> vs Loom's virtual threads. Brian Goetz (the Java language architect) himself even said they're waiting to see how C#'s nullable types plays out before considering them in Java.

jayd16 6y ago
Async/await and implicit thread scheduling solve different problems. Loom is more about catching up to Go and Kotlin, no?
- anoncake 6y ago
  Not Kotlin, AFAIK Loom is about the JVM.
- tybit 6y ago
  They mostly solve the same problems, albeit in very different ways. Loom is primarily about making threads cheaper, async await is primarily working around threads being too expensive.
  - jayd16 6y ago
    Implicit scheduling like Loom doesn't solve the problem of working with thread based synchronization such as what you often see in UI. You want a paradigm that lets the user easily define what runs on the main/ui thread and what runs else where. Loom's goal is implicit suspension without thinking about threads. Its a different use case. Backend engineers seem unaware of the problems async/await solves.
    - thu2111 6y ago
      Using coroutines on a UI thread is a recipe for horrible bugs. I've done it, I wouldn't do it again unless I had to (i.e. all JS in the browser is forced to work this way so there it's pointless to resist). The right approach is what JavaFX or Swing do: make it easy to schedule a lambda onto the UI thread from any background thread. Whilst that lambda executes, events are not dispatched. Where things get painful is where you try to make a single chunk of code look blocking whilst it's actually not. The user can insert arbitrary events into the middle of your code the moment you do an 'await' and you have to plan for that. In practice, I've not found the typical UI toolkit paradigm to ever be a problem. If your UI starts to stutter, it's time to move something to a background thread. It forces you to admit that the UI and work are genuinely running in parallel and consider cancellation semantics, work/results handoff, etc. And of course you properly use multi-core systems.
      - jayd16 6y ago
        To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that thread. Not everything called a coroutine is designed for UI interaction. Kotlin's are better suited than Goroutines. As you admit your self, js and others have settled on this style and one has to assume its for a good reason. Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need. It'll be interesting when or if someone uses Loom in the UI space.
        thu2111 6y ago
        With JS the reason isn't really all that good - it's because it's expensive and difficult to make JavaScript and browser engines thread safe (or any dynamic scripting language). If it's hard to make the language genuinely multi-threaded then you end up stuck with callbacks and a standard library that uses a totally broken design to try and be as single-threaded as possible. It's basically Windows 3.1 all over again, but in 2021 instead of 1991. Quite sad :( Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.
lostmsu 6y ago
Yeah. It's kinda funny. Due to extensive F# -> C# -> Java feature bleed you can consider them beta channels of the same language. Java being LTS, C# - main, and F# - Dev Builds.
- pjmlp 6y ago
  C# keeps getting features from Java as well, e.g. default interface methods. And you are forgetting the ML -> F# / Scala part.
  - tejinderss 6y ago
    Would you choose java or C# if you have to pick one?
    - pjmlp 6y ago
      C#, because of better support for value types and low level coding. Also despite all its high and lows, the .NET story regarding desktop frameworks is much better than Swing/JavaFX, and whatever Google has butchered Java with. However I have never been a X Developer, I always have used both at my employers since they exist, alongside C++, depending on the project and customer requirements.

by vips7L 6y ago

jayd16 6y ago

Async/await and implicit thread scheduling solve different problems. Loom is more about catching up to Go and Kotlin, no?

anoncake 6y ago
Not Kotlin, AFAIK Loom is about the JVM.
tybit 6y ago
They mostly solve the same problems, albeit in very different ways. Loom is primarily about making threads cheaper, async await is primarily working around threads being too expensive.
- jayd16 6y ago
  Implicit scheduling like Loom doesn't solve the problem of working with thread based synchronization such as what you often see in UI. You want a paradigm that lets the user easily define what runs on the main/ui thread and what runs else where. Loom's goal is implicit suspension without thinking about threads. Its a different use case. Backend engineers seem unaware of the problems async/await solves.
  - thu2111 6y ago
    Using coroutines on a UI thread is a recipe for horrible bugs. I've done it, I wouldn't do it again unless I had to (i.e. all JS in the browser is forced to work this way so there it's pointless to resist). The right approach is what JavaFX or Swing do: make it easy to schedule a lambda onto the UI thread from any background thread. Whilst that lambda executes, events are not dispatched. Where things get painful is where you try to make a single chunk of code look blocking whilst it's actually not. The user can insert arbitrary events into the middle of your code the moment you do an 'await' and you have to plan for that. In practice, I've not found the typical UI toolkit paradigm to ever be a problem. If your UI starts to stutter, it's time to move something to a background thread. It forces you to admit that the UI and work are genuinely running in parallel and consider cancellation semantics, work/results handoff, etc. And of course you properly use multi-core systems.
    - jayd16 6y ago
      To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that thread. Not everything called a coroutine is designed for UI interaction. Kotlin's are better suited than Goroutines. As you admit your self, js and others have settled on this style and one has to assume its for a good reason. Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need. It'll be interesting when or if someone uses Loom in the UI space.
      - thu2111 6y ago
        With JS the reason isn't really all that good - it's because it's expensive and difficult to make JavaScript and browser engines thread safe (or any dynamic scripting language). If it's hard to make the language genuinely multi-threaded then you end up stuck with callbacks and a standard library that uses a totally broken design to try and be as single-threaded as possible. It's basically Windows 3.1 all over again, but in 2021 instead of 1991. Quite sad :( Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.

lostmsu 6y ago

Yeah. It's kinda funny. Due to extensive F# -> C# -> Java feature bleed you can consider them beta channels of the same language. Java being LTS, C# - main, and F# - Dev Builds.

pjmlp 6y ago
C# keeps getting features from Java as well, e.g. default interface methods. And you are forgetting the ML -> F# / Scala part.
- tejinderss 6y ago
  Would you choose java or C# if you have to pick one?
  - pjmlp 6y ago
    C#, because of better support for value types and low level coding. Also despite all its high and lows, the .NET story regarding desktop frameworks is much better than Swing/JavaFX, and whatever Google has butchered Java with. However I have never been a X Developer, I always have used both at my employers since they exist, alongside C++, depending on the project and customer requirements.