Would someone care to compare Firefox Quantum Rust concurrency features to Go....

726 views
Skip to first unread message

Anssi Porttikivi

unread,
Nov 23, 2017, 3:04:09 AM11/23/17
to golang-nuts
How would this look, if implemented in Go? Is there anything to learn from Rust "fearless concurrency"? What are the goals and complexity trade-offs of the two languages? https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html

When and why would there be a browser engine in Go? ;-) Some interesting projects to compare to are

ffm...@web.de

unread,
Nov 23, 2017, 11:15:27 AM11/23/17
to golang-nuts
Concurrency in Rust and Go are completely different things. In Rust a thread has its own memory space and hence a thread cannot reference data by reference of some other thread. The rational behind that is security. Also, a thread in Rust is not lightweight, but a full-blown OS thread. So there is no CSP in Rust as in Go and therefore there is little to compare between Rust and Go concerning concurrency. AFAIK, there is some crate in Rust that adds some minimal support for coroutines, but I don't think its used in Servo.

Fino

unread,
Nov 24, 2017, 6:25:38 AM11/24/17
to golang-nuts
a browser engine need to support JavaScript, 
so I think it make sense to write a browser engine in JS to support JS itself.

if Go(or other language, web assembly...) can entirely replace JS in web,  
then I think it will be wonderful, 

BR fino

Dave Cheney

unread,
Nov 24, 2017, 10:33:17 PM11/24/17
to golang-nuts
> In Rust a thread has its own memory space and hence a thread cannot reference data by reference of some other thread.

How is this accomplished? Is there a prohibition against passing a borrowed reference between threads?

hughag...@gmail.com

unread,
Nov 24, 2017, 11:11:15 PM11/24/17
to golang-nuts


On Thursday, November 23, 2017 at 9:15:27 AM UTC-7, Haddock wrote:
Concurrency in Rust and Go are completely different things. In Rust a thread has its own memory space and hence a thread cannot reference data by reference of some other thread. The rational behind that is security. Also, a thread in Rust is not lightweight, but a full-blown OS thread. So there is no CSP in Rust as in Go and therefore there is little to compare between Rust and Go concerning concurrency. AFAIK, there is some crate in Rust that adds some minimal support for coroutines, but I don't think its used in Servo.

I've read about both Rust and Go, but I'm not very familiar with either. I am more interested in Go because it has lightweight threads, which seem to take better advantage of a multi-core system.
I don't know what CSP or "crate"  mean.

In my processor I support a Forth that has "quotations." These are anonymous nested functions defined inside of a parent function.
The quotation's xt (execution token) can be passed as a parameter to a HOF (higher-order function) that can EXECUTE it (typically inside of a loop).
Typically the HOF will traverse a data-structure and execute the quotation for every node in the data-structure.
The cool thing is that the quotation has access to the parent function's local variables --- it can read or write to them --- this is despite the fact that the HOF has local variables of its own.

Do either Rust or Go have anything comparable to my quotations?
Note that my quotations are not like Scheme closures --- they can only be executed so long as the parent function is in scope ---
in Scheme the parent function can exit and the closure is still valid, because the local-frame is in the heap and doesn't get GC'd until all the closures have been killed.
I don't have GC in my system --- I have a simpler system that supports general-purpose data-structures --- my processor is intended to be a micro-controller.

I have something called rquotations that are almost like quotations, with the minor limitation that the xt can't be determined at compile-time (so they can't be used in my <SWITCH construct).
These are not ANS-Forth, but they have been implemented in both VFX and SwiftForth, and could easily be implemented in any ANS-Forth system (given some carnal knowledge).

Has Go been implemented for use on any micro-controller? Or is it purely a desktop-computer language?
My multi-core Forth processor will obviously be programmed in Forth. It may be possible for a language such as Go to generate Forth code that runs on my processor though.
Each core has its own zero-page that includes the data-stack and return-stack. The rest of the memory is shared.

Henrik Johansson

unread,
Nov 25, 2017, 5:33:16 AM11/25/17
to hughag...@gmail.com, golang-nuts

Ifaik rusts safety is compiler magic. Nothing special runtime you just can't share stuff in dangerous ways. Syntax is horrible compared to Go but who knows sometimes it can maybe be worth it.


--
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.
For more options, visit https://groups.google.com/d/optout.

Sam Whited

unread,
Nov 25, 2017, 10:26:23 AM11/25/17
to golan...@googlegroups.com
In general, yes. Data types in Rust can allow themselves to be accessed
by multiple threads and define the semantics of how that happens. There
are several ways in which data can be shared between threads, and all of
them are safe. These include sending a value on a channel or accessing
it via a mutex (mutex's in rust take ownership of the value, so you send
the mutex and can only access the value through that so you can't forget
to lock/unlock it), implementing Copy semantics, etc.

This is an old, but still valid, blog post on the topic of concurrency
in Rust: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

—Sam
Reply all
Reply to author
Forward
0 new messages