Does anybody have experience in both Clojure and Go in production?

<p>I wanna jump on a new project ; a web app where I&#39;m gonna spend a lot of my time and energy for the rest of the year. clojure or go would be a good fit for the project. However since it&#39;s a long term investment I want to think about it a lil bit more before jumping in. In other words, knowing the personal experience of anyone who used both languages in production will be greatly helpful.</p> <p>It&#39;s always difficult to compare languages but if you have to - what would you say are the strength of each, the weaknesses and which one would you pick depending on the project you&#39;re working on? Lastly, which one would you choose if you had a gun to your head?</p> <p>note: I played with both Go and Clojure for a short period of time, and I like them both</p> <hr/>**评论：**<br/><br/>meowtasticly: <pre><p>We use Go in production at work, whereas my experience with clojure is limited to hobby projects. So I might not be the exact person you&#39;re looking for input from.</p> <p>They&#39;re both excellent languages, and I doubt you&#39;d have any big regrets in picking either one. I lean towards Go simply because I like the static binaries and not dealing with the JVM. YMMV.</p></pre>brunokim: <pre><p>If I had a gun to my head: Clojure, for the ecosystem. If all else fails, you&#39;ll have a very decent chance to find a good library made for Java that you can assimilate.</p> <p>I never used Clojure in &#34;production&#34; (but did create an amount of code (~3 kLOC) in an individual project), and now I&#39;m working professionally with Go (few weeks). If I didn&#39;t have a gun to my head I&#39;d pick Go for the personal experience.</p> <p>What I find is that both languages are very well-thought, sufficiently young to not have accumulated some cruft and opinionated in the correct amount to make readable, maintainable code by bending you towards its mindset. I prefer Clojure&#39;s immutable value mindset, which greatly improves tedious stuff like equality testing; and I&#39;m enjoying Go&#39;s typing system to elaborate more structured data instead of lists of maps of maps.</p> <p>Feel free to ignore the following analogy: My general feeling is that Clojure models well a car factory, where pieces flow between stations where complex robots mutate and recreate them; and Go is appropriate to an open-floor office, where papers circulate between desks, workers do impromptu standup meetings while others sit alone to complete a task... and despite that complexity, stuff gets done.</p></pre>alpheus: <pre><p>I write Go and Clojure every day. I don&#39;t enjoy Go very much; it reminds me too much of writing C. Clojure is my favorite now that I&#39;m not programming in Common Lisp.</p> <p>There&#39;s a huge benefit in writing Clojure and Clojurescript for web apps. I find myself moving functionality between the client and server as a matter of convenience. It&#39;s nice to have the same code work equally well either place.</p></pre>robertmeta: <pre><p>Go and GopherJS for web apps. Even unexpected stuff from the Go ecosystem just works on the client (like godebug: <a href="http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/" rel="nofollow">http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/</a>). </p></pre>alpheus: <pre><p>Thanks for bringing up GopherJS. Didn&#39;t know about it.</p> <p>This fascinates and concerns me:</p> <p>&#34;GopherJS does some heavy lifting to work around this restriction: Whenever an instruction is blocking (e.g. communicating with a channel that isn&#39;t ready), the whole stack will unwind (= all functions return) and the goroutine will be put to sleep. Then another goroutine which is ready to resume gets picked and its stack with all local variables will be restored. This is done by preserving each stack frame inside a closure.&#34;</p> <p>Clever, but what if any of those functions on the stack had side-effects? Is it up to the application programmer to ensure they&#39;re pure functions?</p></pre>boomshroom: <pre><p>It is up to the programmer, that said Go strongly advocates to <a href="http://golang.org/doc/effective_go.html#sharing" rel="nofollow">not communicate by sharing memory; instead, share memory by communicating</a>.</p></pre>kangsy: <pre><p>I use Go and Clojure at work and I really like them both. I am currently working on two projects. One uses Go for the server part and Clojurescript as frontend, the other is Clojure only.</p> <p>As long as I dug in one, I find both languages very enjoyable, but if I need to switch between them very often - I feel some kind of burden. It is difficult to write idiomatic code, suddenly I miss static typing in Clojure, a REPL in Go etc.</p> <p>And over time it is quite a big investment to learn the standard libraries and keep track with latest developments, so I tend to go Clojure-only in future. </p></pre>