3 ms·

I'm looking forward to Java getting Project Loom for the concurrency aspect inspired by Go I believe. It will be a nice middle ground between the extremes of Py

I'm looking forward to Java getting Project Loom for the concurrency aspect inspired by Go I believe. It will be a nice middle ground between the extremes of Python and Go.

hactually 5y ago
Been hearing about loom for what seems like years. Keen to know what extremes you're seeing in Python and Go unless you're referring to the static vs dynamic typing?
Cthulhu_ 5y ago
The thing with Java - and by extension Scala - compared to Go is that Loom adds yet another concurrency and language mechanism - so developers have yet another thing to decide and choose from, and a risk of mixing styles together. Whereas in Go there's only one way and that's it. pretty much. Oversimplified maybe, but my point is, 'bigger' languages offer options, and options increase overhead. I support having simplified subsets of languages - or rules in a company, whatever - that sets standards as to which language, stdlib and library features to use. Less options reduces complexity. At the cost of code volume maybe, but code volume is not and never has been the problem - complexity is.
- solaxun 5y ago
  I think the idea with Loom is that you won't have to deal with the red/blue pill bifurcation of sync/async code anymore. It's a return to basics where everything is once again a thread and can be written synchronously, with the runtime handling the scheduling of the userspace threads. In theory this would be very similar to what Go offers, in practice I guess we'll see once it's released, whenver that is.
- eweise 5y ago
  Loom is just lightweight threads so you don't have to use third party async libraries to get better performance.
throwaway894345 5y ago
I'm not super familiar with Loom, but I will say that unless Loom transparently converts all sync API calls to async API calls, it will probably suffer similar problems to Python's async framework.
- eweise 5y ago
  You can have millions of loom threads. Why do they need to be async?
  - throwaway894345 5y ago
    The question is how do those loom threads map to OS threads. If blocking I/O calls aren’t parked on designated OS threads then other work on those OS threads can’t progress.
    - eweise 5y ago
      That's the low level details loom takes care of for you. It maps the fibers onto threads and keeps the os threads active even if your fiber is blocked.
tandr 5y ago
I keep hearing about this project over and over again. Do you know what is the current status of that project?

I'm looking forward to Java getting Project Loom for the concurrency aspect inspired by Go I believe. It will be a nice middle ground between the extremes of Python and Go.

hactually 5y ago

Been hearing about loom for what seems like years. Keen to know what extremes you're seeing in Python and Go unless you're referring to the static vs dynamic typing?

Cthulhu_ 5y ago

The thing with Java - and by extension Scala - compared to Go is that Loom adds yet another concurrency and language mechanism - so developers have yet another thing to decide and choose from, and a risk of mixing styles together. Whereas in Go there's only one way and that's it. pretty much. Oversimplified maybe, but my point is, 'bigger' languages offer options, and options increase overhead. I support having simplified subsets of languages - or rules in a company, whatever - that sets standards as to which language, stdlib and library features to use. Less options reduces complexity. At the cost of code volume maybe, but code volume is not and never has been the problem - complexity is.

solaxun 5y ago
I think the idea with Loom is that you won't have to deal with the red/blue pill bifurcation of sync/async code anymore. It's a return to basics where everything is once again a thread and can be written synchronously, with the runtime handling the scheduling of the userspace threads. In theory this would be very similar to what Go offers, in practice I guess we'll see once it's released, whenver that is.
eweise 5y ago
Loom is just lightweight threads so you don't have to use third party async libraries to get better performance.

throwaway894345 5y ago

I'm not super familiar with Loom, but I will say that unless Loom transparently converts all sync API calls to async API calls, it will probably suffer similar problems to Python's async framework.

eweise 5y ago
You can have millions of loom threads. Why do they need to be async?
- throwaway894345 5y ago
  The question is how do those loom threads map to OS threads. If blocking I/O calls aren’t parked on designated OS threads then other work on those OS threads can’t progress.
  - eweise 5y ago
    That's the low level details loom takes care of for you. It maps the fibers onto threads and keeps the os threads active even if your fiber is blocked.

tandr 5y ago

I keep hearing about this project over and over again. Do you know what is the current status of that project?