▲ 67 points
back
12 comments
Just a small "ackchyually": Go is basically a modern Limbo which is itself based on Alef and there was an official "Alef for C" thing in Plan 9 in libthread (https://9p.io/magic/man2html/2/thread)
EDIT: looks like it was ported on UNIX as part of Plan9Port (https://github.com/9fans/plan9port/blob/master/src/libthread...)
Russ Cox created libtask, a similar library that runs on multiple UNIXes (UNIXEN?). Based on the COPYRIGHT file, it may be based on libthread.
It’s a great little library. Very easy to read and understand.
As I recall, Bell Labs actually abandoned Alef on Plan 9 because the concurrency primitives they wanted were doable in C so they just went with that.
Nope, they abandoned it because the language design was unsound, and in retrospective a GC was a critical missing piece.
"Alef appeared in the first and second editions of Plan 9, but was abandoned during development of the third edition.[1][2] Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;[3] also, in a February 2000 slideshow, Pike noted: "…although Alef was a fruitful language, it proved too difficult to maintain a variant language across multiple architectures, so we took what we learned from it and built the thread library for C."
https://en.wikipedia.org/wiki/Alef_(programming_language)
"Problem: with C's memory model in a concurrent world, hard to know when to free items.
All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming"
http://go-lang.cat-v.org/talks/slides/emerging-languages-cam..., slide 19
And some Oberon-2 in the mix as well, method syntax and unsafe package.
There is also libmill/libdill, which implements go-style coroutines using setjmp and is usable directly from C (not just as a transpilation target).
What on earth is going on when you click the Tutorial button on that website?!
He obviously got hacked by some Indonesian gaming site
But select statements are the most important part, and second to that is the fact that goroutines are low cost user space threads
Yes exactly. The author’s design decisions only make sense if this is supposed to be a toy language. On using pthreads rather than fibers:
> I decided not to use one. I wanted something dead simple — an approach I could explain in a paragraph, using tools every C programmer already knows. The trade-off is that you lose some performance with fine-grained blocking, but in many real-world situations, pthreads work fine if you use a worker pool.
Sure. You can take a large production Go app and measure how many user space threads are launched; it’s decidedly a lot more than the typical number of threads if you were using pthreads.
And the author didn’t really justify why select isn’t implemented other than implementation difficulty.
I've been using Go regularly since 2012. Worker pools are completely valid and idiomatic in Go. Not sure how you read that quote and concluded "toy".
I was expecting proper green threads (it's not like it's impossible in C, there's several C libraries for doing it).