[Cryptography] Languages, languages (was Re: Swift and cryptography)

[Tony Arcieri]

On Thu, Jun 12, 2014 at 5:55 PM, Perry E. Metzger <perry at piermont.com>
wrote:

> Personally I'm partial to go's solution, which is to adopt the CSP
> model and get rid of shared state entirely, but that's another long
> story, and we're getting far afield of crypto.


Go still shares state between goroutines and is still just as susceptible
to data races as any other language which bolts on CSP or actors as an
afterthought. They have at least started shipping a race detector, but this
will only detect data races when they manifest (which is often at the worst
times, e.g. in production and under unusual load), as opposed to Rust,
which leverages the type system to ensure it's impossible to share state
unsafely.

I think there's a bit of a misconception that Go has separate heaps per
goroutine or something of that nature ala Erlang, but this isn't the case,
it has a single flat shared heap and sending a value over a channel just
shares a reference to the same data between two potentially racy goroutines.

It's described on Wikipedia here:

https://en.wikipedia.org/wiki/Go_(programming_language)#Race_condition_safety

I'd also note that Rust also implements CSP and has tasks/channels,
although Rust supports both synchronous and asynchronous channels (whereas
Go only supports synchronous channels) and Rust also supports both 1:1 and
M:N tasks:threads (which you can mix and match in the same program using
the same API), whereas Go only supports M:N tasks (i.e. goroutines)

Anyway, I apologize if I'm dragging the list further off topic ;) I just
wanted to make it clear that Go is not a "concurrency safe" language in the
same way Rust is. CSP alone is not a silver bullet.

--
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140612/e3cf3efd/attachment.html>