4 ms·
Thanks for the reply. My comment apparently came off as trite, apologies. One of the enlightening things for me about CSP and Erlang, in particular, was using
by kinofcain 13y ago
Thanks for the reply. My comment apparently came off as trite, apologies.
One of the enlightening things for me about CSP and Erlang, in particular, was using channels and messages and a bunch of lightweight tasks for flow control and state management. Reading the reddit comments, and even your reply here, seems to indicate that that type of programming isn't a good fit for rust, and that perfectly reasonable trade offs were made that led the language in a different direction. I should have phrased the comment better, but the recommendations here and in the reddit thread boil down to replying to "it hurts when I do this" with "don't do that".
Obviously no-one is trying to write programs that count to 10001, but the capability of doing it that way efficiently opens up a bunch of different options.
It will be interesting to see what happens to go's performance on things like this if they move away from segmented stacks.
- nickik 13y agoIt seams to me that Rust is still good at CSP, one can still start up many threads (logical) but they are not as cheap. This might just mean that it is more senceable to span a smaller number and communicate with them via port. Its still CSP, its still usful, but its not exactly like go. My guess is that if you start to do more computation in each thread the benchmarks are gone change. The Go style is only cheap if the stack does not grow.