Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Go has shared memory and mutexes, but using them means giving up on memory safety because the whole rigmarole that Rust does to preserve safety in concurrent code is totally missing in Go. So that's a meaningful reason to stick to CSP - sure, it might create easy deadlocks but at least it won't totally crash your app with a potentially exploitable fault.

View on HN

Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are safe, allows to avoid deadlocks just as channels and much more flexible.

And with mutex one can build those as necessary, even if interaction with channels is ugly.

Erlang doesn't have priorities natively, does it? As far as I am aware, there is a standard pattern to do it, like this:

    receive
        {high_p, Message} ->
            process_high(Message)
    after 0 ->
            receive
                {high_p, Message} ->
                    process_high(Message);
                {low_p, Message} ->
                    process_low(Message)
            end
    end

The Go equivalent can be done with different channels for priorities and similarly nested selects, as I am sure you are aware.

Hm, is this pattern the best Erlang has and VM does not optimize it to avoid the need to lock the queue twice? If so then you are right double-select is equivalent even if it is rather messier in Go then in Erlang with the need to provide 2 channels.

Erlang has selective receive, meaning it will go through all your receive branches in order, until one matches.

With this code:

    receive
        {high_p, Message} ->
            process_high(Message);
        {low_p, Message} ->
            process_low(Message)
    end

if the process has one high_p message and a low_p message, the high_p message will be processed first.

> Go could have provided message queues with priorities Erlang style

Erlang doesn't have priorities; you can fake them with selective receive, but IIRC selective receive is considered a code smell and something that should generally be avoided or minimized.

(You can also have a separate process act as a priority queue channel by, well, storing messages in an actual priority queue structure and sending from its head, and that's a little more robust.)

Reply on news.ycombinator.com