7 ms·

Unlike goroutines, seems here you have control over the execution schedule for the virtual threads if you provide an executor. This is pretty great. Think this

Unlike goroutines, seems here you have control over the execution schedule for the virtual threads if you provide an executor. This is pretty great. Think this will obsolete go over the next few decades.

didip 4y ago
Java moves a lot slower so I don't think it will obsoletes Go. If anything, if Loom is great, then it will keep Go on its toes and hopefully Go will also evolved due to external pressure.
- slantedview 4y ago
  I beg to differ. Go has been moving at a glacial pace. Generics took forever to implement, aren't even feature complete (no type parameters on methods), and have no integration with the standard lib. Meanwhile Java is adding lots of new features and versions at a quick pace.
cogman10 4y ago
Not on the first go around. AFAIK, they are looking at exposing more of the internal scheduling API but that's likely not going to be a part of the initial release. The executor services referred to in the blog are for the order of execution of tasks on the virtual thread pool. For a "virtualThreadExecutor" service, every task will get a virtual thread and scheduling will happen internally. You can still use a fixed thread pool with a custom task scheduler if you like, but probably not exactly what you are after.
- CHY872 4y ago
  This blogpost does rely on plugging in an executor. While the API was removed, it’s one private variable away (documented in footnote). As you say, it seems like it’s an ‘on the way, but later’ thing - the last Loom preview I used (a while ago) actually had the API so when I started drafting this post I was unhappily surprised!
  - cogman10 4y ago
    IMO, they are focusing on the right thing here. Getting a good virtual thread API GA will be paramount in the decisions around scheduling and continuations in the future. Maybe a little disappointing for low level nuts and other languages like kotlin, but the right move IMO. Virtual threads alone will be a huge benefit to the ecosystem. The other stuff will help, but won't have near the same impact.
    - CHY872 4y ago
      Agreed. And the pluggable scheduling is still a key part of it, just doesn’t need to be a thing to get right out of the gate. I’m honestly mega excited that Loom is even a real thing that exists and that you can use.
  - pron 4y ago
    Right, custom schedulers aren't quite ready for release yet -- there's a small missing piece in the VM that's required to fully preserve the spec, and they need a lot of testing that we don't yet have -- so we decided to go ahead without them and add them later.
    - CHY872 4y ago
      What’s the missing piece?
      - pron 4y ago
        A technical detail. Monitors (synchronized) record their owners as the OS thread, which makes the VM not know whether the carrier or the virtual thread owns a monitor, as they both share the same OS thread.
        CHY872 4y ago
        For any future readers, I think this is the bug: https://bugs.openjdk.java.net/browse/JDK-8281642 https://bugs.openjdk.java.net/browse/JDK-8281642
jjice 4y ago
I don't think it will. If everyone was clamoring for Java and settled on Go only because of goroutines, then sure, but I think Go was liked for a lot of reasons aside from that. I also don't often see people complain about wanting more control over the scheduler for Go (could be that I just miss those). I'd be surprised if Go adoption plummeted because of this, but who knows, I sure don't have a crystal ball.
- lostcolony 4y ago
  Sane concurrency is -one- of the reasons people reach for Go, and sure, that may no longer be a differentiator. But it's definitely not the only one I've heard people toss around (and, agreed, I've never heard anyone bemoan the lack of control of the scheduler). In fact, the introduction of virtual threads and no new memory semantics I think means it still fails one of the main benefits of goroutines (channels and default copying semantics); everything in JVM land by default is still going to use shared memory and default pass by reference semantics. I think it's all a moot point though, as it basically just demonstrates the next iteration of Paul Graham's Blub Paradox. With every iteration of new improvements for the JVM it reinforces the belief of many that the JVM is the best tool for every job (after all, it now just got cool feature y they just now learned about and can use and OMG Blub-er-Java is so cool, who needs anything else?!), and reinforces the belief of many others that the JVM is playing catchup with other languages (it only just -now- got feature y) and there are often better tools out there.
  - erik_seaberg 4y ago
    Go structs are copied but not deeply; collections are inherently passed by reference and everything is mutable. Scala and Kotlin get immutability right and Java is getting there with unmodifiable collections and records.
    - lostcolony 4y ago
      I don't know that I'd say Scala gets immutability right in that it still provides you equal access to the mutable collections (and I have basically no experience with Kotlin), but I cede the point it's way better than either Go or Java here. I readily admit Golang gets this wrong, just, -slightly- better than Java. I'm coming from an Erlang background, and that's the main influence I'm looking at concurrency from; the JVM as a whole gives me a sad when it comes to helping me write correctly behaving code.
kjeetgill 4y ago
One of the unsung heroes of go is how goroutines sit on top of channels + select. Blocking and waiting on one queue is easy, blocking and waiting on a set of queues waiting for any to get an element is a good deal trickier. Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. You can kinda do this with futures but I suspect it'll be wildly inefficient. I really hope Java get's something to fill this niche. We already have a menagerie of Queue, BlockingQueue, and TransferQueue implementations. What's a few more?
- sudarshnachakra 4y ago
  I guess the Structured Concurrency JEP below addresses the problems you'll get to solve. It'll enable things like AND / OR combinations of virtual threads which IMHO looks like a better way to solve this rather than having a special syntax for select. https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 But frankly I'm afraid of how these changes affect garbage collection since more and more vthread stacks are going to be in the heap (I hope they are contemplating some form of deterministic stack destruction along with the above JEP).
- ackfoobar 4y ago
  > Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. Kotlin coroutines have the bare minimum in the language, and implement the rest (e.g. channel, select, `go`/`launch`) in libraries. Could you explain what the dividends for Go are?
- MrBuddyCasino 4y ago
  Channels on the JVM would be sweet. You can do the same with Futures, and its probably not even slower, but it is a lot more clunky. I suspect its never gonna happen, too big a change. Maybe Kotlin will do it.
  - native_samples 4y ago
    Kotlin already does it: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.selects/select.html https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutin...
Thaxll 4y ago
Go does not need 128MB of memory to run hello world in a container. People don't pick up Go over Java because of goroutines, Java is still and will forever be an "enterprise" language behind many layers of abstractions.
- kaba0 4y ago
  Low memory consumption also has a price in this case. On a 1 TB server machine guess which platform will have better throughput by far? Go’s GC will die under that load. Writing a “hello world”-scoped microservice is a tiny niche.
  - Thaxll 4y ago
    Microservices are 100x more popular than app than need 1TB of memory. Also have you proof that Go will die under large memory usage? It's FUD.
    - kaba0 4y ago
      Sure. What about apps that need 300MB. Or a few GBs? Where you can get away with barely any allocations is a much smaller niche even for microservices. And Java’s GC is in an entirely other generation of GCs compared to Go’s.
    - vips7L 4y ago
      > Also have you proof that Go will die under large memory usage? The Debian binary-tree test is designed to create a ton of allocations and stress the GC. Go comes in at 12.23 seconds with Java at 2.65 [0] Discords famous article about moving a service off Go because of GC issues [1] I think there is definitely enough evidence to suggest that Go’s GC does have performance issues and doesn’t give you the knobs to tune it. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
MobiusHorizons 4y ago
I'm curious why you think a language feature would obsolete an entire programming language. Do you imagine that go programmers secretly wish they were writing Java syntax, in my experience this is very much not true.
- EdwardDiego 4y ago
  I'm tempted to make cheap shots about sets that do actual set operations without a for loop, but I'm hoping Go >=1.19 will start introducing some nice generic collections in the stdlib.
d3nj4l 4y ago
I've heard some variation of "$java_feature will make $language obsolete" for years now, most recently wrt kotlin/scala, and it's never held true. It's great for the people who use Java, but there are tons of reasons why other people use other languages.
- EdwardDiego 4y ago
  Java record vs. Kotlin dataclass?
  - d3nj4l 4y ago
    That was the recent incident, yeah. Records + Pattern Matching led to many saying you no longer need Kotlin, even here on HN.
    - brabel 4y ago
      Well, for a lot of people those things are enough to go back to Java and avoid having to rely on the Kotlin ecosystem (which is not free of problems). At which point would you say Java has improved enough to catch up with Kotlin (supposing Kotlin does not also keep improving)? As a long-term user of Kotlin, I would say I would not reach out for Kotlin anymore for new projects. The last remaining big thing Kotlin gives is non-nullability, but with simple tools, Java also has that already.
      - d3nj4l 4y ago
        I wouldn't reach for Kotlin for backend projects at all tbeh, since the ecosystem on that side is (relative to Java) immature and doesn't always play well with standard Java tools such as JPA. Non-standard tools are half-baked, inconsistently maintained and not ready for primetime. But for apps, like in mobile, the ecosystem is rich and I would prefer it over Java, especially with advances such as KMM and KotlinJS. My point being, Kotlin vs Java isn't just about language features, it's about community, ecosystem, use cases etc. (Fwiw, personally I prefer Kotlin because it's more expression oriented than Java.)
- 4y ago

didip 4y ago

Java moves a lot slower so I don't think it will obsoletes Go. If anything, if Loom is great, then it will keep Go on its toes and hopefully Go will also evolved due to external pressure.

slantedview 4y ago
I beg to differ. Go has been moving at a glacial pace. Generics took forever to implement, aren't even feature complete (no type parameters on methods), and have no integration with the standard lib. Meanwhile Java is adding lots of new features and versions at a quick pace.

cogman10 4y ago

Not on the first go around. AFAIK, they are looking at exposing more of the internal scheduling API but that's likely not going to be a part of the initial release. The executor services referred to in the blog are for the order of execution of tasks on the virtual thread pool. For a "virtualThreadExecutor" service, every task will get a virtual thread and scheduling will happen internally. You can still use a fixed thread pool with a custom task scheduler if you like, but probably not exactly what you are after.

CHY872 4y ago
This blogpost does rely on plugging in an executor. While the API was removed, it’s one private variable away (documented in footnote). As you say, it seems like it’s an ‘on the way, but later’ thing - the last Loom preview I used (a while ago) actually had the API so when I started drafting this post I was unhappily surprised!
- cogman10 4y ago
  IMO, they are focusing on the right thing here. Getting a good virtual thread API GA will be paramount in the decisions around scheduling and continuations in the future. Maybe a little disappointing for low level nuts and other languages like kotlin, but the right move IMO. Virtual threads alone will be a huge benefit to the ecosystem. The other stuff will help, but won't have near the same impact.
  - CHY872 4y ago
    Agreed. And the pluggable scheduling is still a key part of it, just doesn’t need to be a thing to get right out of the gate. I’m honestly mega excited that Loom is even a real thing that exists and that you can use.
- pron 4y ago
  Right, custom schedulers aren't quite ready for release yet -- there's a small missing piece in the VM that's required to fully preserve the spec, and they need a lot of testing that we don't yet have -- so we decided to go ahead without them and add them later.
  - CHY872 4y ago
    What’s the missing piece?
    - pron 4y ago
      A technical detail. Monitors (synchronized) record their owners as the OS thread, which makes the VM not know whether the carrier or the virtual thread owns a monitor, as they both share the same OS thread.
      - CHY872 4y ago
        For any future readers, I think this is the bug: https://bugs.openjdk.java.net/browse/JDK-8281642 https://bugs.openjdk.java.net/browse/JDK-8281642

jjice 4y ago

I don't think it will. If everyone was clamoring for Java and settled on Go only because of goroutines, then sure, but I think Go was liked for a lot of reasons aside from that. I also don't often see people complain about wanting more control over the scheduler for Go (could be that I just miss those). I'd be surprised if Go adoption plummeted because of this, but who knows, I sure don't have a crystal ball.

lostcolony 4y ago
Sane concurrency is -one- of the reasons people reach for Go, and sure, that may no longer be a differentiator. But it's definitely not the only one I've heard people toss around (and, agreed, I've never heard anyone bemoan the lack of control of the scheduler). In fact, the introduction of virtual threads and no new memory semantics I think means it still fails one of the main benefits of goroutines (channels and default copying semantics); everything in JVM land by default is still going to use shared memory and default pass by reference semantics. I think it's all a moot point though, as it basically just demonstrates the next iteration of Paul Graham's Blub Paradox. With every iteration of new improvements for the JVM it reinforces the belief of many that the JVM is the best tool for every job (after all, it now just got cool feature y they just now learned about and can use and OMG Blub-er-Java is so cool, who needs anything else?!), and reinforces the belief of many others that the JVM is playing catchup with other languages (it only just -now- got feature y) and there are often better tools out there.
- erik_seaberg 4y ago
  Go structs are copied but not deeply; collections are inherently passed by reference and everything is mutable. Scala and Kotlin get immutability right and Java is getting there with unmodifiable collections and records.
  - lostcolony 4y ago
    I don't know that I'd say Scala gets immutability right in that it still provides you equal access to the mutable collections (and I have basically no experience with Kotlin), but I cede the point it's way better than either Go or Java here. I readily admit Golang gets this wrong, just, -slightly- better than Java. I'm coming from an Erlang background, and that's the main influence I'm looking at concurrency from; the JVM as a whole gives me a sad when it comes to helping me write correctly behaving code.

kjeetgill 4y ago

One of the unsung heroes of go is how goroutines sit on top of channels + select. Blocking and waiting on one queue is easy, blocking and waiting on a set of queues waiting for any to get an element is a good deal trickier. Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. You can kinda do this with futures but I suspect it'll be wildly inefficient. I really hope Java get's something to fill this niche. We already have a menagerie of Queue, BlockingQueue, and TransferQueue implementations. What's a few more?

sudarshnachakra 4y ago
I guess the Structured Concurrency JEP below addresses the problems you'll get to solve. It'll enable things like AND / OR combinations of virtual threads which IMHO looks like a better way to solve this rather than having a special syntax for select. https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 But frankly I'm afraid of how these changes affect garbage collection since more and more vthread stacks are going to be in the heap (I hope they are contemplating some form of deterministic stack destruction along with the above JEP).
ackfoobar 4y ago
> Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. Kotlin coroutines have the bare minimum in the language, and implement the rest (e.g. channel, select, `go`/`launch`) in libraries. Could you explain what the dividends for Go are?
MrBuddyCasino 4y ago
Channels on the JVM would be sweet. You can do the same with Futures, and its probably not even slower, but it is a lot more clunky. I suspect its never gonna happen, too big a change. Maybe Kotlin will do it.
- native_samples 4y ago
  Kotlin already does it: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.selects/select.html https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutin...

Thaxll 4y ago

Go does not need 128MB of memory to run hello world in a container. People don't pick up Go over Java because of goroutines, Java is still and will forever be an "enterprise" language behind many layers of abstractions.

kaba0 4y ago
Low memory consumption also has a price in this case. On a 1 TB server machine guess which platform will have better throughput by far? Go’s GC will die under that load. Writing a “hello world”-scoped microservice is a tiny niche.
- Thaxll 4y ago
  Microservices are 100x more popular than app than need 1TB of memory. Also have you proof that Go will die under large memory usage? It's FUD.
  - kaba0 4y ago
    Sure. What about apps that need 300MB. Or a few GBs? Where you can get away with barely any allocations is a much smaller niche even for microservices. And Java’s GC is in an entirely other generation of GCs compared to Go’s.
  - vips7L 4y ago
    > Also have you proof that Go will die under large memory usage? The Debian binary-tree test is designed to create a ton of allocations and stress the GC. Go comes in at 12.23 seconds with Java at 2.65 [0] Discords famous article about moving a service off Go because of GC issues [1] I think there is definitely enough evidence to suggest that Go’s GC does have performance issues and doesn’t give you the knobs to tune it. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...

MobiusHorizons 4y ago

I'm curious why you think a language feature would obsolete an entire programming language. Do you imagine that go programmers secretly wish they were writing Java syntax, in my experience this is very much not true.

EdwardDiego 4y ago
I'm tempted to make cheap shots about sets that do actual set operations without a for loop, but I'm hoping Go >=1.19 will start introducing some nice generic collections in the stdlib.

d3nj4l 4y ago

I've heard some variation of "$java_feature will make $language obsolete" for years now, most recently wrt kotlin/scala, and it's never held true. It's great for the people who use Java, but there are tons of reasons why other people use other languages.

EdwardDiego 4y ago
Java record vs. Kotlin dataclass?
- d3nj4l 4y ago
  That was the recent incident, yeah. Records + Pattern Matching led to many saying you no longer need Kotlin, even here on HN.
  - brabel 4y ago
    Well, for a lot of people those things are enough to go back to Java and avoid having to rely on the Kotlin ecosystem (which is not free of problems). At which point would you say Java has improved enough to catch up with Kotlin (supposing Kotlin does not also keep improving)? As a long-term user of Kotlin, I would say I would not reach out for Kotlin anymore for new projects. The last remaining big thing Kotlin gives is non-nullability, but with simple tools, Java also has that already.
    - d3nj4l 4y ago
      I wouldn't reach for Kotlin for backend projects at all tbeh, since the ecosystem on that side is (relative to Java) immature and doesn't always play well with standard Java tools such as JPA. Non-standard tools are half-baked, inconsistently maintained and not ready for primetime. But for apps, like in mobile, the ecosystem is rich and I would prefer it over Java, especially with advances such as KMM and KotlinJS. My point being, Kotlin vs Java isn't just about language features, it's about community, ecosystem, use cases etc. (Fwiw, personally I prefer Kotlin because it's more expression oriented than Java.)
4y ago