3 ms·

> it is important to point out that Go essentially solves the same problems Java does One of the major selling points of Go is its concurrency features built i

> it is important to point out that Go essentially solves the same problems Java does One of the major selling points of Go is its concurrency features built into the language. Namely, first class channels and lightweight threads. Java has neither of those. In particular, very few languages support lightweight threads in an M:N scheduling style (Haskell, Erlang, Rust), which in and of themselves makes Go a very attractive tool for concurrent programming.

pron 14y ago
Actually, these aren't lightweight threads because, AFAIK, they require cooperative multitasking. Java actually has fork-join, an extremely sophisticated scheduler, that allows much finer control over scheduling than Go, and also supports non-cooperating tasks. I believe it's being used as the basis for Akka's actors. Java also has quite a few queue implementations suitable for a different concurrency scenarios. So, in that respect, Go offers easier to use, though fewer, concurrency options, while Java offers finer control over concurrency. But the point wasn't to debate the merits of Go over Java or vice versa, just to say that they are both intended to be used in the same domains.
- burntsushi 14y ago
  Go's lightweight threads do not require cooperative multitasking in the traditional sense. In Go, lightweight threads are preempted by the runtime whenever an operation that can block is made (IO, channel send/receive, system calls, etc.). However, lightweight threads can hog the CPU, and in that sense, they must be cooperative. But this rarely shows up outside of pathological cases in practice. More importantly, I wasn't talking about scheduling. I was talking about lightweight threads. They are also commonly known as: goroutines, green threads, fibers, user space threads, etc. This has a dramatic effect on the style of concurrent programming, as spawning a light weight thread is cheap relative to spawning an OS thread. Joe Armstrong explains [1] things better than I can: Processes in Java or C# are pretty much like the objects in the flawed object system which we described earlier - you can’t have many of them, and if you have more than a few hundred processes the system will start misbehaving and to do any real work with them you have to write your own scheduler and start combining multiple threads of control into single processes. All of this gives concurrent programming a bad name - and would probably make any sane person think that concurrent programming was a difficult and should be avoided whenever possible. The opposite is true. And: In Erlang processes are *light weight*. This means that very little computational effort is required to create or destroy a processes. Light-weight processes in Erlang are one to two order of magnitude lighter than operating system threads. Not only are Erlang processes light-weight, but also we can create many hundreds of thousands of such processes without noticeably degrading the performance of the system (unless of course they are all doing something at the same time). In Go, "goroutines" are analogous to "processes" in Erlang in the above excerpt. My point here was that Go solves the concurrency problem much differently than Java does, to a point where Go is much better suited to write concurrent programs than Java is. Joe Armstrong's argument in his paper applies pretty well here. I'm not really sure what is to be gained by debating over whether Go was "intended" to be in the same domain as Java. I've used Go to solve problems that I might have otherwise solved in a variety of other languages (C, Haskell, Python). Had I ever been a Java programmer, I'm sure that would have been in the list too. Experience in speaking with other Go programmers leads me to believe that I am not unique in this regard. [1] - "Concurrency oriented programming in Erlang", 2003. https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armst...
  - pron 14y ago
    Take a look at Akka actors. The JVM offers similar mechanisms, only with finer control over scheduling. But Go is fine and does have some advantages over the JVM (faster startup time) as well as disadvantages (dynamic code loading, runtime instrumentation, monitoring). Use it in good health!
- tptacek 14y ago
  Isn't the "heaviness" of Go's threads due to do with how the thread stacks are allocated, not so much with how the threads are scheduled?
  - pron 14y ago
    In that case, Java allows for a very similar thing with fork-join. If you want to see exactly how, in two weeks I'll release an open-source library that wraps Java's fork-join as Go-like lightweight threads, only more preemptive and with better scheduling.

pron 14y ago

Actually, these aren't lightweight threads because, AFAIK, they require cooperative multitasking. Java actually has fork-join, an extremely sophisticated scheduler, that allows much finer control over scheduling than Go, and also supports non-cooperating tasks. I believe it's being used as the basis for Akka's actors. Java also has quite a few queue implementations suitable for a different concurrency scenarios. So, in that respect, Go offers easier to use, though fewer, concurrency options, while Java offers finer control over concurrency. But the point wasn't to debate the merits of Go over Java or vice versa, just to say that they are both intended to be used in the same domains.

burntsushi 14y ago
Go's lightweight threads do not require cooperative multitasking in the traditional sense. In Go, lightweight threads are preempted by the runtime whenever an operation that can block is made (IO, channel send/receive, system calls, etc.). However, lightweight threads can hog the CPU, and in that sense, they must be cooperative. But this rarely shows up outside of pathological cases in practice. More importantly, I wasn't talking about scheduling. I was talking about lightweight threads. They are also commonly known as: goroutines, green threads, fibers, user space threads, etc. This has a dramatic effect on the style of concurrent programming, as spawning a light weight thread is cheap relative to spawning an OS thread. Joe Armstrong explains [1] things better than I can: Processes in Java or C# are pretty much like the objects in the flawed object system which we described earlier - you can’t have many of them, and if you have more than a few hundred processes the system will start misbehaving and to do any real work with them you have to write your own scheduler and start combining multiple threads of control into single processes. All of this gives concurrent programming a bad name - and would probably make any sane person think that concurrent programming was a difficult and should be avoided whenever possible. The opposite is true. And: In Erlang processes are *light weight*. This means that very little computational effort is required to create or destroy a processes. Light-weight processes in Erlang are one to two order of magnitude lighter than operating system threads. Not only are Erlang processes light-weight, but also we can create many hundreds of thousands of such processes without noticeably degrading the performance of the system (unless of course they are all doing something at the same time). In Go, "goroutines" are analogous to "processes" in Erlang in the above excerpt. My point here was that Go solves the concurrency problem much differently than Java does, to a point where Go is much better suited to write concurrent programs than Java is. Joe Armstrong's argument in his paper applies pretty well here. I'm not really sure what is to be gained by debating over whether Go was "intended" to be in the same domain as Java. I've used Go to solve problems that I might have otherwise solved in a variety of other languages (C, Haskell, Python). Had I ever been a Java programmer, I'm sure that would have been in the list too. Experience in speaking with other Go programmers leads me to believe that I am not unique in this regard. [1] - "Concurrency oriented programming in Erlang", 2003. https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armst...
- pron 14y ago
  Take a look at Akka actors. The JVM offers similar mechanisms, only with finer control over scheduling. But Go is fine and does have some advantages over the JVM (faster startup time) as well as disadvantages (dynamic code loading, runtime instrumentation, monitoring). Use it in good health!
tptacek 14y ago
Isn't the "heaviness" of Go's threads due to do with how the thread stacks are allocated, not so much with how the threads are scheduled?
- pron 14y ago
  In that case, Java allows for a very similar thing with fork-join. If you want to see exactly how, in two weeks I'll release an open-source library that wraps Java's fork-join as Go-like lightweight threads, only more preemptive and with better scheduling.