Hacker News Reader

Comment by bestinterest | Hacker News Reader

Java will join the (imo) better concurrency path of higher level languages with green like threads, Golang (goroutine), Erlang, Java (Loom, virtual threads) & Ruby (soon under Ractors?).

I really think C# & Python will be jealous of the languages mentioned and puts them in an odd spot from language design perspective.

View on HN

Well,

https://github.com/python-greenlet/greenlet

has been available for quite some time in Python (gevent probably being its most used flavor).

i.e.: just because it's not in the standard library doesn't mean it's not available (so, you can actually choose whether you'd like to use async/await or greenlets).

Because it’s not in the standard library means there are various issues with compatibility. Everything needs to be designed/used for greenlets in mind. It’s not quite the same as the VM itself saying we’ve sorted it all out.

Well, whenever you add threads to the mix (native or virtual threads) if you don't design for it, I don't think things pan out properly (but I guess that I agree that if someone designed with native threads going for virtual threads where the same APIs can now make IO async switch threads it's probably easier to go that route).

I must say that the main usage I personally had of greenlets didn't have it in mind initially (it was used in an existing application where making the coloring wasn't really feasible as it was a huge app already and adopting green threads was much less work).

As much as I love Rust for serious code and Python for scripting, I do much prefer the green thread model to async/await in general.

for anyone interested in Rust's choice to not use the green thread model:

https://www.reddit.com/r/rust/comments/7x0icm/regarding_gree...

https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

> Initially, Rust supported only the green threading model. Later, native threading was added and ultimately became the default.

I get why Rust opted for native threads vs. green threads as a default, esp. when they want to promote zero cost abstractions. What the above links don't cover, and what I'm interested in, is why async/await instead of M:N/green threads for the secondary "light weight" threading model. Was async/await easier to make "zero cost"? Or what was the reason?

In theory async/await can be compiled to something as efficient as if you wrote all the non-blocking logic by hand so yeah, it's a "zero cost" abstraction.

For green threads the stdlib would have to be designed around them (again) or they'd feel like something bolted on the side with two sets of APIs for everything. This is also the case for async/await but that means green threads don't have an advantage there. If you have to worry about Task vs Thread, make sure you all the right APIs from each, figure out what to do for TLS in Tasks, etc then you may as well just use the one that is more efficient.

Green threads and async/await are orthogonal concepts. Both can be used at the same time and separately. Jep 425 brigns VM threads, but the API remains same as the old one. Without deep language extensions any concurrency improvements, in terms of usage, aren't possible. C#, Rust, JS made the successful leap, and imo Go route is very interesting.

For Ruby I’d say the closest equivalent would be Fibers with the scheduler support introduced at 3.0. They take a different approach with pros and cons compared to virtual threads, but they are similar.

Kotlin state of the art coroutines should be mentioned too

Isn't Kotlin coroutines have the same coloring problem (functions must be marked with "suspend").l?

Although the coloring problem is only a problem if red functions are harder to use. Not sure marking all functions with "suspend" would make it any worse, besides infecting the codebase.

Here the Kotlin lead argued that it is not a "problem".

https://elizarov.medium.com/how-do-you-color-your-functions-...

I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions.

I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?

> Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember.

I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..

> you still need to mark functions as suspend and only call suspending functions from other suspending functions.

You restated the idea of function colouring without further elaborating why it is a problem.

If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.

runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types?

If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.

You can absolutely do this.

`fun main() = runBlocking<Unit> {`

https://kotlinlang.org/docs/composing-suspending-functions.h...

Then you'll have to explain why that isn't the default main behavior then. Synchronous functions cannot call async functions (without defining N runblocking scopes) but a runblocking main would make kotlin seems color-less and should be seen as best practice. What's the catch?

> would make kotlin seems color-less

Quoting the post:

> Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code.

Also you can do `suspend fun main()`

> You restated the idea of function colouring without further elaborating why it is a problem

Did you not read my second paragraph?

> I am also not sure

It felt like a question more than a complaint.

> create an interface that can be implemented by both suspending and synchronous functions

If interface has a suspending method, the implementations will also be suspending. But you can choose not to make any suspend calls in the method body. Not being able to say "this particular implementation of a red interface is blue" has never bothered me.

The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.

If it’s a better model, why wouldn’t C# and Python adopt it?

Yeah I really don't see an issue with C# building a virtual thread system if the paradigm really shifts that way. Its aggressively pragmatic in that way.

In theory, such a system could be implemented on C# with the same sort of gotchas as Java virtual threads. I don't think there's a fundamental design conflict.

There's no design conflict I'm aware of but you don't "just" implement virtual threads. The PR to do it in HotSpot is notoriously huge:

https://github.com/openjdk/jdk/pull/8166

1,140 files, (+98,553 −9,862 LOC) and those lines of code are mostly horribly fiddly low level assembly/compiler hacking. This is partly why it took years of development.

Most people don't realize this, especially because in the later stages of course many others contributed, but Loom is in some sense one man's journey. Before he worked at Oracle Ron Pressler spent years writing a library called Quasar which implemented fibers on top of the JVM using bytecode rewriting and some low level hackery with internal APIs. At some point he became available for hiring and Oracle brought him on board, as by that point he was not only an expert in fiber implementations but also the JVM. That was the genesis of Loom.

Something I've learned from following the intricacies of VM development is that what we get is very much a result of hidden human stories as well as technical decisions. Features happen or don't happen on the basis of who was available to be hired at the time, as much as cold calculations of performance impacts. In turn that depends heavily on the vagaries of personal lives. The skills needed to do this work aren't that easy to find on the open market and training takes a long time.

For other VM implementors to do this, and realistically only .NET has the sort of languages where it makes sense (JS doesn't), well, it'd take a long time even if they start today and there's no guarantee of success.

Reply on news.ycombinator.com