I'll second Paul's comments and raise you two: 1) Depending on your app's use cases, speed going forward will be gained primarily from parallelism. I think Clojure has a better story there than Go but that is just my opinion.
2) It is very hard to fight against cultural bias against the JVM. I work in embedded systems where anything but C/C++ (or Lua, Python) is taboo. Your best bet is to "Go" with their momentum and when they run into a roadblock in Go (probably something related to mutability/locks in the face of heavy load), give a shot at the same problem with Clojure. Obviously this has to be done in a non-intrusive way (on the other end of a socket) but will give you a chance to prove Clojure and the JVM can handle the job. Unfortunately your company won't gain the other benefits of Clojure beyond just performance (e.g. clarity, simplicity, etc.) because the rest of the code base will be in Go but... clearly that ship has already sailed. Good luck! Let us know how things turn out. Alan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
