Go gouroutines vs Rust threads

[Serge Hulne]

Does anybody know if Rust threads are lightweight processes like Go goroutines or if they rely on system threads (i.e. more like the Python approach) ?

Thanks!

[Russel Winder]

Rust std::thread is all about OS threads. There are many crates dealing with
threadpools, work-stealing, etc. e.g Rayon.

--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk

[Serge Hulne]

Am I therefore correct in assuming that, if the problem I am trying to model is not IO bound or CPU bound, but deals essentially with modeling a large number of independent cells (a sort of massively parallel « Game of life »), where each cells lives in its own process, it makes more sense to model it in Golang rather than rust?

[Robert Engels]

It may be easier - as you can code it in a more procedural fashion, but you can do it in either system - there are many techniques you can use.

There are also “green threads” libraries (crates) available for Rust. These may over more control over the internal scheduler as well.

> On Nov 13, 2019, at 8:02 AM, Serge Hulne <serge...@gmail.com> wrote:
>
> Am I therefore correct in assuming that, if the problem I am trying to model is not IO bound or CPU bound, but deals essentially with modeling a large number of independent cells (a sort of massively parallel « Game of life »), where each cells lives in its own process, it makes more sense to model it in Golang rather than rust?
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87f2cdd8-1968-445d-b2bc-eae349ae5687%40googlegroups.com.

[Robert Engels]

Also, I find the GC model of Go far simpler that the “borrower” model in Rust - but to each their own.

I think the “experts” would say use Rust if it is mission critical or needs to meet absolute performance metrics.



> On Nov 13, 2019, at 8:13 AM, Robert Engels <ren...@ix.netcom.com> wrote:
>

[Serge Hulne]

Thank you very much for your answers, they are very much appreciated.

Serge.

[Brian Hatfield]

Note: rust also recently landed async/await: https://blog.rust-lang.org/2019/11/07/Async-await-stable.html, though I have not looked into how it schedules the futures (ie, is it a one-cpu loop like swift or node, does it attempt to schedule futures in an M:N fashion like goroutines, etc). It's a recent development that seems excellent for the Rust ecosystem, so it might be looking at further when learning about language concurrency models.

On Wed, Nov 13, 2019 at 9:22 AM Serge Hulne <serge...@gmail.com> wrote:

Thank you very much for your answers, they are very much appreciated.

Serge.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/bbe52ea5-b65b-4959-89cc-80e747322be9%40googlegroups.com.

[Russel Winder]

No. At least not per se.

If you feel more comfortable doing it in Go in preference to Rust that choose
Go. Another person might have a different background and therefore choose
Rust. The programming languages do not provide the disambiguation, it is about
the programmer(s), the audience, and the context.

[Serge Hulne]

Thank you!