> As far as I know, no other popular language allows you to read from multiple queues at the same time

Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about.

That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.

As I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.

> It's possible to implement CSP channels in most languages, but they're not first-class like go.

But does that matter? In all my experience, I can't think of any instances where that wouldn't be a distinction without a difference. (Perhaps I'm missing something, though.)

It matters a lot IMO. Most systems programming languages can implement whatever concurrency primitives you care to use, but most people default to whatever is provided by the OS/language because concurrency is hard. Having first-class syntactic sugar over a concurrent runtime bakes in a certain programming style in the language, which strongly determines how the language is used and the programming style. Go comes out of the Newsqueak/Aleph/Limbo family which has a very different style of programming compared to a lot of other languages.

I think there's a difference between 'in the standard library' and 'in the language', though. They seem to be praising Go for doing the latter. And the technical language in which it was expressed gave me to think there was some technical motivation for that, as opposed to sociological - but if what they meant is what you said, then I certainly wouldn't disagree with that.

I'd argue that Go is explicitly sociological. Most of the novel ideas in Go (process calculi/guarded commands in a concurrent language) were originally embedded in Cardelli and Pike's Squeak back in the 80s. The rest is trying to standardize the way scalable web applications are built.

Defaults matter because friction matters, but friction there is largely removed by having a decent package manager, so I personally don't think it matters (though the topic of "what batteries should be included" has far from run its course).

The minute you put language constructs in the base syntax and runtime of the language, it's a lot more than friction. Love it or hate it, Go is inextricably tied to CSP.

It's the opposite - pointing out that X can just as well be implemented in language Y is the irrelevant point because anything can be implemented in any turing complete language.

Where languages differ is what they make easy to use, or first class.

As an example consider Go's autoformatter gofmt. It got released with the language, pushed and marketed as the way to format your code - first class. As a result, virtually all Go code is uniformly formatted. Contrast that with autoformatters in other languages pre-Go. They existed, but often multiple per language, each with hundreds of configuration options, all with minimal uptake in their ecosystems.

If you could spare some time, would you please demonstrate an example? Any language of those mentioned would be OK.

Here's a Rust example, with tokio: https://play.rust-lang.org/?version=stable&mode=debug&editio... - I don't have time to come up with Java/C++ examples, but I'm sure others will.

(If your point was about it being _built into the language_, then it definitely stands, see the other discussion in the parent comment thread)

Yeah, I guess I overestimated the complexity of such mechanisms. I mean, still, you need some kind of runtime for the asynchronicity, but the Rust version seems fairly OK (apart from the function coloring, but that's another story).

I guess I just like it being built into the language. Plus no function coloring (everything is asynchronous, but appears synchronous) really makes it easy to build complex systems.

Here's a rust example - https://github.com/autarch/channel-select

Ada too, I think.

Ada has had this built-in for decades, and even allows selecting from one of multiple waiting queues (entries) using a `select` keyword.

If that's all you want, Haskell has had goroutines (forkIO, yes it's called "fork" but it doesn't spawn an OS level process, that's forkOS), channels, and select since 1996. https://www.microsoft.com/en-us/research/wp-content/uploads/...

People also want a programming language they can easily read and that has enough market share to work well in team environments.

nobody should ever write haskell

here's some documentation on how to do it in C++ with boost in 2008, before go even existed: in this example two threads pull events from a single queue.

https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tu...

(of course it was possible before)

I'm not really experienced with Boost so I'm having a hard time understanding what that snippet does. Is there any example that is completely self-contained (or at least limited to STL)?

Boost's io_service (since then renamed as io_context) is an implementation of a thread-safe event queue. Threads can put events in the queue (timer events, asynchronous read and write requests for networking, but one can also just push a generic lambda).

This example sets up two timers which will regularly push events in the queue, while two threads processes these events. It's from before c++ had lambdas - nowadays it can be written much more tersely.

I'll try to write a short example after when I'm not on my phone - it should be reduceable to 5-6 lines of setup at most

=> very dumb example of processing messages from ten threads

    #include <boost/asio.hpp>
    
    #include <atomic>
    #include <iostream>
    #include <thread>
    
    int main() {
      boost::asio::io_context io;
    
      using work_guard_type = boost::asio::executor_work_guard<boost::asio::io_context::executor_type>;
      work_guard_type work_guard(io.get_executor());
    
      std::vector<std::jthread> t;
      for(int i = 0; i < 10; i++)
        t.emplace_back(std::jthread([&io] { io.run(); }));
      
      std::atomic_int counter{};
      while(counter < 100)
        io.post([&] { 
            std::cerr << std::this_thread::get_id() << '\n'; 
            counter++; 
        });
      
      io.stop();
      return 0;
    }

>read from multiple queues at the same time

That's a trivial thing in javascript.

If you could spare some time, would you please demonstrate an example?

You can use Promise.race to wait for the first resolved promise.

Abusing notation a bit,

var a = new Queue();

var b = new Queue();

a.read(() => some callback);

b.read(() => some callback);

And code continues here without blocking.

To be honest, I think you could do the same in any (slightly) modern language.

Is the read() call running a task in the background? In that case, that's equivalent to launching two threads. For n queues, you'd need n tasks, and they'd hang in the background in case they never get a result and take up memory.

How? Javascript is single threaded run loop.

Concurrency is not parallelism: https://go.dev/blog/waza-talk#:~:text=In%20programming%2C%20....

>read from multiple queues at the same time

Agreed, and things happening "at the same time" are possible only with parallelism. Hence my question =)

I interpreted "at the same time" as "without blocking",

But sure you could also add parallelism using a few built-in Node modules (there's cluster and worker threads, also don't know if atomics are already in Node, they are in V8),

It's not trivial anymore but also not that hard. A newcomer could figure it out in ~30 mins from the docs.

Gotcha, sounds like we interpreted it differently. I appreciate you taking the time to clarify, I am an old hand as JS but didn't know true parallelism had become feasible these days. Thank you, sincerely!

Don't worry, JS has come a long way.

During my PhD we had to crunch some numbers and my group usually makes use of C++ with libs for that. I tried doing it in Node using cluster and let it spread through our whole cluster of nodes (funny how it plays on words) and performance was worse obv. but not that bad, it was about 2x slower, but with that I was able to write code and test it in hours instead of days, and it didn't matter to me if a program that was going to take 2 hours was now taking 4 as I was going home anyway and check it out next morning ¯\_(ツ)_/¯. Plus, my experiment had a REST API for free (well, like 8 lines of code) and when I showed that to them they were :O.

Lots of languages have similar async, channel and pattern matching syntax these days. Kotlin, C#, off the top of my head. Probably a lot more.