[jjice]

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]

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]

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]

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.

[EdwardDiego]

It might be equally accessible, but mutable collections require you import classes from scala.collection.mutable that have very different names, e.g., mutable.ArrayBuffer vs List.

The path of least resistance in Scala leads to immutable collections.

[EdwardDiego]

Channels are just blocking queues with weirder semantics.

[ackfoobar]

At first I misread "wider" and agreed.

In Go/Kotlin, one can atomically take from/send to exactly one channel with the `select` call.

Then I agree with "weirder" as well, in the case of Go channels. A send on a nil channel blocks forever. Why?

[EdwardDiego]

Haha yep, it's those edge cases, to quote one of the many web pages documenting it:

  Channels exhibit the following properties:

    * send to a nil channel blocks forever
    * receive from a nil channel blocks forever
    * send to a closed channel panics
    * receive from a closed channel returns the zero value immediately

I have this bookmarked because I don't write Go enough to remember it by heart.