Comment by coldtea | Hacker News Reader

Comment by coldtea | Hacker News Reader

Parent Full thread

>Oh, come on. Not only is your comment needlessly insulting but it's completely unconstructive.

I find his comment pretty spot on. If anything it was the "don't do CSP in Rust" comment that was unconstructive and passive aggresively insulting. Instead of understanding what he read and the constrains it shows, the commenter preffered to just piss on the language.

As for the example, it was obviously "retarted" or rather, contrived. I mean, heck, it's "chinese whispers" with 10000 channels, what more do you need to see that this is not a serious way of solving actual problems with CSP? It's a bloody microbenchmark, and those are rarely representative of anything.

>What types of CSP things should you do in Rust, then?

The types of CSP things that people use threads and processes for. E.g getting lots of computations going on in parallel, not incrementing tens a single int in each of thousands of "computations".

CSP and channels are meant for getting real (cpu intensive) work done. You don't just use threads (or greenthreads) "because concurrency".

That some Go programmers like to use channels as a control mechanism, doesn't mean CSP was meant for that kind of abuse. That's like using Exceptions for control flow to me.

Isn't it obvious that even in Go the times to complete this are horrible (just an order of magnitude less horrible because of different design trade-offs), and that doing the same job of 10,000 incrementings properly would complete in 1/1000 the time?

    > CSP and channels are meant for getting real (cpu 
    > intensive) work done. You don't just use threads (or 
    > greenthreads) "because concurrency".

The whole point of green threads is that they're orders of magnitude cheaper to create (and destroy) than real, operating system threads. They are precisely around "because concurrency" -- they allow you to nicely model concurrent problems without having to be overly concerned with the implementation detail of their creation cost.

While it's not idiomatic in Go to use a channel/goroutine combo as an iterator, for example -- that's too low-level -- it's absolutely idiomatic to use one for other types of higher-order control flow, managing state machine transitions, doing a scatter/gather, and so on.

Rust tasks have the same large fixed-size stack as OS threads. A fine-grained concurrency model like a task graph would be build on top of them.

    > Rust tasks have the same large fixed-size stack as OS 
    > threads. A fine-grained concurrency model like a task 
    > graph would be build on top of them.

In the absence of other context (I don't really know much about Rust) I would then argue that Rust tasks miss the point of CSP.

I think that's unfair. There's no absolute threshold that defines "the point of CSP"; you might equally say Go's goroutines miss the point of CSP because they're slower than the equivalent for loop.

Besides, the only substantive difference between Go's implementation and Rust's implementation is that Go uses segmented stacks, while Rust does not. That is because segmented or relocating stacks are in opposition to Rust's design goals of no GC, fast calling into C, and predictable performance.

One might say that passing raw pointers around is against the point of CSP. As I understand it go does exactly what the Singularity OS does, pass over ownership instead of copy or raw pointer.

This seams more idimotic, and more CSPish to me.

(Passing around pointer/references to immutables is of course ok)

> As I understand it go does exactly what the Singularity OS does, pass over ownership instead of copy or raw pointer.

I may misunderstand what you're talking about, but as far as I know Go more or less passes a raw pointer (or a copy thereof) over pointer channels. It has no concept of ownership, and the pointer (and pointee) on the sender side remains valid: http://play.golang.org/p/E1bqrVFxZ6

I mixed up go and rust. Go send around raw pointers.

Mixed up go and rust.

Reply on news.ycombinator.com