4 ms·

"Concurrency" at syntax level is kind of dumb anyway.

• tkinom 12y ago
  The way golang works seems to be follow the model of Unix pipe (stdio pipe) between process. They are simple channel between go-routines (kind of) light weight threads. The concept is built into the language itself. Anything wrong with that?
  • mariusmg 12y ago
    Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks. Sorry but from my point of view, "real" concurrency is done at the OS level. The OS schedules threads to the CPU depending on their priority and "other" things. Having a single OS thread and runtime code that "yields" so another piece of code can run in the same thread, that's not concurrency...that's a toy. Sorry for being so blunt.....but that's my opinion.
    • cjslep 12y ago
      At least initially, the gccgo compiler implemented goroutines as OS native threads and am wanting to say it still does.
    • pritambaral 12y ago
      Switching goroutines is much lighter than switching OS threads. When this "toy" and "hack" becomes as heavy or slow and thus no more useful than OS threads, then you can make a point. As I see it, you aren't making a point right now, just explaining what OS threads do and calling goroutines names. So let me point in the direction of an explanation of what goroutines do: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Desh...