libmill - Go-style concurrency in C (libmill.org)

I think Concurrent ML (1991) had select before Go. Go itself took it from Newsqueak (1994) and Limbo (1995) I think. The name itself probably comes from the UNIX select(2) syscall, which first appeared in 4.2BSD (1983).

As someone who worked with a decent variety of languages that all claim their fame to CSP (Erlang, Clojure and Go), suffice to say that these all look very similar. It’s the tooling _around_ the CSP where the real differences are.

There are no queues in CSP, although you can make one by making a queue process.

In CSP, the sending side of a message is always logically simultaneous with the receiving side. So it's like Go's default channels where the sender and receiver both block until ready to transfer, and different from Python's multiprocessing and queue constructs, where the sender doesn't block.

CSP was used in Occam¹ on Transputers² in the 1980s. In Occam, it was normal to have a large number of tiny processes, some of them maybe only a few instructions (such as an implementation of a queue), and the thread switching and communication primitives were actual CPU instructions. The CPUs were joined with dedicated message communication links into large meshes, providing hardware parallelism with a very different model than today's SMP multi-core. A similar architecture exists today, XMOS³.

Go implements a model similar to CSP on today's SMP multi-core systems and OSes, emphasising many efficient, small threads running loops that communicate synchronously. Channels are unbuffered by default, making them like CSP. They can be made buffered, which adds a queue, as if a CSP queue process was added. Go is much less rigid than Occam, because you can also make new channels and spawn new threads efficiently, which are essential features in modern sofware.

Python multiprocessing doesn't provide efficient, small threads. You need larger thread units to get good performance out of it. It also emphasises queuing. So it's quite different from CSP.

Erlang implements a model like Occam and Go of many, efficient, small threads, but the messaging is always asynchronous. The communication is similar to Go with buffered channels.

¹ https://en.wikipedia.org/wiki/Occam_(programming_language) ² https://en.wikipedia.org/wiki/Transputer ³ https://en.wikipedia.org/wiki/XMOS

Yes, Erlang is based more on the actor model.

CSP is synchronous, so sending to a channel will block if the receiver isn't ready. Erlang and actors are asynchronous in this matter. They will send regardless of whether the receiver is in a state where it can receive the message. Practically, Go (and libmill) allow buffered channels so that you only block if the channel's buffer is full.

CSP is based on anonymous processes. Actors have identity, and this would be the process IDs in Erlang. Erlang and the actor model don't use channels (though you can use processes to mimic them).

Technically, Erlang is based on Actor model. But both models are formally equivalent, i.e. you can simulate one model in another.

Go can somewhat emulate Actor model using concurrency control structures and buffered channels with non-blocking send to emulate mailboxes.

Probably this one: https://9fans.topicbox.com/groups/9fans/Tef717f57ede82d4f-M5...

It is, i had this piece of code in mind:

    choose {
    out(ch, int, 42):
        foo();
    in(ch, int, i):
        bar(i);
    otherwise:
        baz();
    end
    }

every other languages are too rigid when it comes to DSLs, so you either fall back to a scripting language / bloated XML file, or you use the language itself and write a bloaty and unreadable mess

only C allows that kind of level of customization, so powerful

i love D, i use it more than C, but damn i miss being able to shape the language this way

July 25, 2015 - https://news.ycombinator.com/item?id=9947749 (16 comments)

(and 2 more with 1 comment)

libdill:

9 months ago - https://news.ycombinator.com/item?id=27357295 (19 comments)

Feb 17, 2018 - https://news.ycombinator.com/item?id=16401234 (22 comments)

Dec 21, 2017 - https://news.ycombinator.com/item?id=15977983 (50 comments)

June 4, 2016 - https://news.ycombinator.com/item?id=11835091 (32 comments)

Lexical closure of syntactic lambdas, with escape analysis as an implementation optimization.

RISC-V is a pretty evolutionary architecture when compared to the Mill architecture, so I would think they're attempting pretty different things. I don't know a lot about Mill other than what I've read recently, but it seems like it's just had extremely slow progress towards an implementation, which leaves the claims about it's architectural innovations not proven until there's a chip to prove them on.

Do you have a pointer to Mashey's comments on Mill?

They just don't seem to be in a rush to get anything to market; I know they are talking to VCs but don't get the impression that they are motivated to take money that would speed their time-to-market.