Tokio 1.0 – async runtime for Rust

Re:Tokio 1.0 – async runtime for Rust by pvorb on Wednesday December 23, 2020 @06:00PM (#25523283)

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specialization of the concept that doesn't boil down to OS threads.

I haven't used it yet, so I can only repeat the advertising copy, but nevertheless wanted to give some perspective from other ecosystems.

[1]: https://wiki.openjdk.java.net/display/loom/Main

[ Parent | on HN ]

Re:Tokio 1.0 – async runtime for Rust by johnnycerberus on Wednesday December 23, 2020 @06:55PM (#25523689)

Go and Zig already solved the problem. Java will follow soon with Loom, can't wait.

[ Parent | on HN ]

Re:Tokio 1.0 – async runtime for Rust by littlestymaar on Thursday December 24, 2020 @12:12PM (#25529292)

Go “solved the problem” at the expense of being unable to interface with C libraries without a big performance penalty (and that's you'll have Rust in Chromium and not Go)

[ Parent | on HN ]

Re:Tokio 1.0 – async runtime for Rust by victor106 on Wednesday December 23, 2020 @06:31PM (#25523512)

Loom is going to be a game changer. Hopefully they release it soon.

[ Parent | on HN ]

Re:Tokio 1.0 – async runtime for Rust by wbl on Wednesday December 23, 2020 @06:58PM (#25523721)

Didn't they start with green threads way back when?

[ Parent | on HN ]

Re:Tokio 1.0 – async runtime for Rust by lmm on Thursday December 24, 2020 @02:40AM (#25525750)

Yes they did, and gave up because of serious problems with that approach. (Interestingly, so did Rust, more recently).

[ Parent | on HN ]