News for hackers. Stuff that matters.
Re:Go 1.18 by zozbot234 on Tuesday March 15, 2022 @02:38PM (#30689178)
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.
Re:Go 1.18 by fpoling on Tuesday March 15, 2022 @02:49PM (#30689341)
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.

Re:Go 1.18 by sriram_malhar on Wednesday March 16, 2022 @12:07AM (#30695211)
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.
Re:Go 1.18 by ergl on Wednesday March 16, 2022 @10:32AM (#30699304)
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.
Re:Go 1.18 by fpoling on Wednesday March 16, 2022 @02:29AM (#30695916)
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.
Re:Go 1.18 by dragonwriter on Wednesday March 16, 2022 @12:14AM (#30695247)
> 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.)