Clojure core.async and Go: A Code Comparison
blog.drewolson.org
Clojure core.async and Go: A Code Comparison
1–10 of 81 posts
Re: Clojure core.async and Go: A Code Comparison
#2Thanks for the write up. Definitely good to see core.async and goroutines side by side...
Re: Clojure core.async and Go: A Code Comparison
#3Are the first two examples equivalent? In the go version, an anonymous function is being declared and then called with the value of the outer 'i'. In the clojure version, it appears that the value of 'i' is part of the closure for that function.
The go version does what it does to avoid a race condition, because the goroutines are being spun up in the background and it's highly likely that it will take longer to spin up at least one of them than it will to finish the loop, so without it you'd likely get output of all nines.
If the clojure version doesn't have that problem, then I think it's a somewhat telling indication of how it's actually working.
TL/DR: The Go version has to work around the race condition because the runtime is doing things "right", is core.async?
Re: Clojure core.async and Go: A Code Comparison
#4I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?
Re: Clojure core.async and Go: A Code Comparison
#5Are the clojure threads actually lightweight? Thread/sleep is blocking so you'd need to occupy 10 threads right? If you wanted to sleep without blocking a real thread would you use an executor service to write to a channel after delay and block on that?
Re: Clojure core.async and Go: A Code Comparison
#6I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?
It's a bit more verbose than popular dynamic languages like ruby, python, clojure, etc. but a lot less verbose than Java, C#, or C. To me it feels roughly on par with javascript LOC-wise, though it has much stronger constructs.
Re: Clojure core.async and Go: A Code Comparison
#7Are the clojure threads actually lightweight? Thread/sleep is blocking so you'd need to occupy 10 threads right? If you wanted to sleep without blocking a real thread would you use an executor service to write to a channel after delay and block on that?
Author here.
From what I've read/seen, the go blocks are lightweight thread-like processes multiplexed onto a thread pool. You may be correct about using Thread/sleep, ideally I would have used (timeout ...) and then pulled off the channel. However, I didn't want to introduce the concept of channels too early in the post, so I felt Thread/sleep worked as a compromise.
Re: Clojure core.async and Go: A Code Comparison
#8Are the first two examples equivalent? In the go version, an anonymous function is being declared and then called with the value of the outer 'i'. In the clojure version, it appears that the value of 'i' is part of the closure for that function. The go version does what it does to avoid a race condition, because the goroutines are being spun up in the background and it's highly likely that it will take longer to spin…
The i is scoped differently in clojure than in golang so it doesn't have the same potential pitfall. I think golang people consider their scoping here a mistake (and have tooling to check it?).
Re: Clojure core.async and Go: A Code Comparison
#9I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?
Clojure, being a Lisp, is as terse as you want it to be. Some of the examples on this page could be made even shorter with macros.
Re: Clojure core.async and Go: A Code Comparison
#10Are the clojure threads actually lightweight? Thread/sleep is blocking so you'd need to occupy 10 threads right? If you wanted to sleep without blocking a real thread would you use an executor service to write to a channel after delay and block on that?
Author here. From what I've read/seen, the go blocks are lightweight thread-like processes multiplexed onto a thread pool. You may be correct about using Thread/sleep, ideally I would have used (timeout ...) and then pulled off the channel. However, I didn't want to introduce the concept of channels too early in the post, so I felt Thread/sleep worked as a compromise.
Yah, for demo purposes of wanting to show something taking awhile thread/sleep is very convenient. I have no idea, time.sleep in golang might actually block a real thread too. I'm just curious if blocking in a go block could starve your thread pool or if there is some magic being done by the macro to even correct for that?