Clojure and Go seem like two of the least comparable languages to me. They basically have no commonalities. Comparing Java, Kotlin, or Scala to Go seems more valuable to me.
Superficially they're very different. But lots of people use Go because its a "first class" concurrency language. Concurrency was given a huge consideration in Clojure too, with its immutability, STM, agents, etc. The reasons you might choose Go can overlap heavily with why you might choose Clojure, Erlang, or Elixir.
Is it really first class though? Anything CPU bound is basically a noop since GO doesn't have actual threads.
Go automatically multiplexes goroutines on top of OS threads. You can peg all the cores of a multicore CPU in a single Go program using goroutines.
Edit: last I looked you could see how many OS threads would be used by looking at runtime.GOMAXPROCS. There was a time when it would just default to 1, but it looks like they changed it. When I last programmed in Go you had to override it via an environment variable or set it in code.
Re:The Next Step for Generics
by darksaints on Tuesday June 16, 2020 @08:20PM
(#23546098)
Both are great choices for networking, concurrency, latency, and throughout-oriented use cases. Networked applications, databases, streaming, caches, etc.
To me, Go vs JVM ecosystem languages is a much more difficult choice. I would have to actually think a bit.
To me, Rust and Go really don't occupy the same ecosystem niche. I can't think of a project where I would have to choose between them--the choice between them is almost always dead obvious given the project description.