Ask HN: Besides Go, what languages are muti-threading "in background"? | Hacker News Reader

Ask HN: Besides Go, what languages are muti-threading "in background"?

2 pointsstanlogin16 comments

I mean, no need to write "async/await".

I think you're mixing up async execution and multithreading. They're quite different concepts, although you can offload an awaited work on another thread.

Almost any language supports spawning a new thread.

"in background"

What does that mean?

I don't think its difficult to understand. Look at the other two answers.

No, it really is. I've got experience with multiple languages / multithreading approaches and could argue it means 3 different things. I don't know what others think the question is about.

OK. It's difficult to you.

OP is right.

In Go you always need a keyword (go something) to start a co-routine, well, in C# you do exactly the same with Task.Run(something), while it also supports async/await.

Additionally, LINQ can make use of background execution via PLINQ, Dataflow Tasks allow to use a DSL to orchestrate executions that happen in the background, the early BeginInvoke()/EndInvoke() can make use of threads or not, and for all of that, we can also write our own scheduling algorithm and give it to the runtime scheduler.

So yeah, it depends how rich the language runtime happens to be, even if async/await are also supported.

When you said "(go something)", you are talking about different thing.

Nope, there are no goroutines without go something, other than runtime stuff like the GC.

I will not reply again. Yes you know something, and your knowledge is right. You saw my question and saw some keyword matched you knowledge, and you spoke out your knowledge. I'm not saying your wrong, but we are talking about different thing.

There is only one way for doing background execution in Go.

When you said goroutine, you are talking about different thing.

Go only has goroutines for background execution.

I think the tokio library does this for rust

Java 21+ (virtual threads).

Java already did it in the past, that is why we have the notion of green threads versus red threads.

What virtual threads bring to the table is that now they are both officially supported, with APIs for both cases, while previously it was an implementation detail of each JVM how threading was actually done.

Reply on news.ycombinator.com