<p>We often hear about companies that switched from node.js to golang or ruby to clojure? How about companies that moved from clojure to golang? I would like to know if there are any companies who experienced a pain point that either of those two languages solved that the other was lacking in some way or another. -- Golang To Clojure; or Clojure to Golang.</p>
<hr/>**评论：**<br/><br/>tealeg: <pre><p>I don't know about companies - but I moved from Clojure to golang around 5 years ago. I had completed around 5 projects in Clojure at that point, but had grown very frustrated with the reality of dealing with the java ecosystem (my background was C, Scheme and Python, and my few experiences with Java thus far had been equally frustrating). The company I was working for at the time mostly outsourced development tasks, but there were huge swathes of data cleaning and processing that they never properly planned or budgeted for, so I ended up doing those things alone. As such I had control and I ended up doing some of those things in Go. One result of that is <a href="https://github.com/tealeg/xlsx" rel="nofollow">this library</a> - I've not had need of it since I left that job, more than 4.5 years ago, but it seems to have taken on a life of it's own. </p></pre>x7C3: <pre><p>Oh wow, that's your package?</p>
<p>I've used it a few times, thanks for initially developing it. Great great help!</p></pre>tealeg: <pre><p>Thanks for the thanks.</p></pre>koffiezet: <pre><p>Damn that looks like a nice library! I've always used xlswriter in Python for generating xlsx reports, but am certainly going to look into this...</p></pre>tealeg: <pre><p>Well, it has it's problems (check out the issues on github!) but the biggest one is finding time to work on it!</p></pre>natdm: <pre><p>Hah! I have a program that used that library once a month. </p></pre>tealeg: <pre><p>Nice to hear it.</p></pre>FrenchDonkey: <pre><blockquote>
<p>this library</p>
</blockquote>
<p>I have been using this library so much !
Thank you so much for creating it </p></pre>tealeg: <pre><p>My absolute pleasure.</p></pre>kadema: <pre><p>I have used xlsx before. Thanks a lot for that.</p></pre>tealeg: <pre><p>I'm really glad that so many people have found it useful.</p></pre>tealeg: <pre><p>Thanks for the gold, whomever that was!</p></pre>FrenchDonkey: <pre><p>My absolute pleasure :)</p></pre>GoTheFuckToBed: <pre><p>How do you handle really messy XML files. I found it hard to write all parsing and type handling in go.</p></pre>tealeg: <pre><p>I'm not quite sure what you mean? This project is quite old and it uses encoding/xml extensively. For the most part that just means there is a Go struct for ever XML element - the struct is annotated and encoding/xml takes care or the marshalling and marshalling. We've worked around some issues (particularly around styles) but actually I'd like to move even that code back to the built in marshalling. Probably the biggest issue I have with encoding/xml is the way it handles namespaces. </p></pre>orbat: <pre><p>We're pretty relaxed as to which programming language people use, so we're actually using both.</p>
<p>This <em>could</em> end up biting us in the ass, but it's nice to have that kind of latitude</p></pre>s-expression: <pre><p>I've developed applications in both Clojure and Go at my company, with most new development in Go.</p>
<p>Reasons for moving toward Go:</p>
<ul>
<li>Native compiled binaries makes deployment a breeze. Using docker with the JVM and some JARs isn't painful, but it's annoying enough for Go to score some points here.</li>
<li>Much lower memory requirements. Clojure is a beast with memory, and more memory means more money to spend. One of our most heavily-used services tops out at about 100MB of memory, whereas the Clojure equivalent <em>starts</em> at about 350MB of memory and tops out a little short of a gig.</li>
<li>REPL startup time is terrible. This has spurred a movement within the Clojure community to architect applications in a REPL-friendly manner, instead of trying to model your problem domain. So what should have been simple is now a woven (or <em>complected</em> in Hickey-speak) blanket of Components and Dependencies. Whereas with Go I can just use something like <code>gin</code> and my app is recompiled <em>on the fly</em> and it's actually fast.</li>
<li>Too much Java interop. Java is ugly and it seems you can't write a non-trivial Clojure app without Java-isms infecting your code.</li>
</ul>
<p>Things we miss:</p>
<ul>
<li>Leiningen is awesome</li>
<li>Lisps are awesome</li>
<li>Immutability is awesome. Code is simpler to reason about.</li>
<li>Ring is a phenomenal library, and every web framework supports it. Seeing stuff like <a href="https://github.com/xyproto/permissions2" rel="nofollow">this</a> (look at the examples) means things are only going to get worse in the Go community. There are a hundred routers/frameworks and each one manages to be completely incompatible with the rest.</li>
</ul>
<p>Clojure has no shortage of exceptionally high quality libraries, and solutions written in Clojure seem to be smaller, simpler, and easier to understand.</p>
<p>However Clojure brings with it the JVM, along with all its problems and annoyances. If Clojure targeted a runtime that wasn't incredibly bloated, slow, and painful, then we'd still be using it.</p></pre>mallocc: <pre><p>You indict the JVM, but cite issues with the CLJ runtime. I don't really understand why the JVM angst when most of your objections seem to be with CLJ and all the baggage it brings with it.</p></pre>ledgerdev: <pre><p>I would have to agree, while the JVM isn't a lightweight, it's the clojure core namespace, lein, nrepl and associated toolchain that are grotesquely obese.</p></pre>ledgerdev: <pre><blockquote>
<p>This has spurred a movement within the Clojure community to architect applications in a REPL-friendly manner, instead of trying to model your problem domain. So what should have been simple is now a woven (or complected in Hickey-speak) blanket of Components and Dependencies. </p>
</blockquote>
<p>This is such an excellent point. The whole "component design pattern" is a travesty. For as many smart decisions as clojure makes, why are they so blind to this?</p></pre>ledgerdev: <pre><p>I've not been a part of a companies switch between the two, but have been using golang on some projects recently. Damn if golang isn't a breath of fresh air compared to clojure for a lot of reasons. I do miss the repl, the functional aspect and conciseness of clojure. To me golang seems to be gaining momentum(while clojure stagnates) and it seems a better fit for where application development is heading.</p>
<p>Has anyone else been thinking of a lightweight cleaned up clojure like language on top of the golang runtime?</p></pre>MahouMaouShoujo: <pre><p>I don't think it qualifies as a cleaned up clojure, but maybe <a href="https://oden-lang.org" rel="nofollow">https://oden-lang.org</a> piques your interest?</p>
<blockquote>
<p>A functional language inspired by Haskell, LISP and Go compiling to Go.</p>
</blockquote></pre>ledgerdev: <pre><p>Interesting, will look into it.</p></pre>jason_e_aten: <pre><p>Yes, this. Very much so. I missed the repl in golang, so I wrote <a href="https://github.com/glycerine/zygomys" rel="nofollow">https://github.com/glycerine/zygomys</a></p></pre>ledgerdev: <pre><p>Very cool!</p></pre>kingfishr: <pre><p>My company (liftoff.io) used to be more-or-less Clojure-only, and now we use Go for servers where performance matters (as well as many internal tools). I even wrote <a href="https://github.com/cespare/goclj" rel="nofollow">a Clojure parser and code formatter in Go</a> so that I could write cljfmt :)</p></pre>
