In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism.
Having actual algebraic data types is night and day to Go's more limited structs. OCaml also has a good object system which people don't use too often but can come on very handy.
While I agree that the former is a nice language, it doesn't compare favorably to Go as a development suite: the standard library is terribly designed, and the package management is rather poor compared to Go's (which is about as great as it gets).
Now there is "OCaml Batteries Included" which is supposed to mitigate that, but it appeared after I stopped actively using OCaml so I can't comment on that (incidentally, I dislike many of their choices).
Also Go has many of the features that make programming in ML a pleasure, many languages these days have them, which is a good thing.
Personally my tool of choice for many tasks would be OCaml with Go's package management system, and perhaps a syntax closer to M-expressions (like Mathematica).
For package management, I haven't had the chance to really try it yet, but I'm hearing good things about OPAM.
Finally, Rust just looks awesome, I'm hoping that the language stabilizes before the end of the year, as I'd love to do my master thesis with it.
Package management is one of those things that are better off when there is just one.
Would you mind expanding on what is good about m expressions and how that could apply to go, I'm not familiar with them?
Please note I'm suggesting using that syntax for OCaml, not Go.
In short, I want to write "f[x;y]" for "f x y". On the first sight it appears this adds a bunch of noise, but there are many advantages:
1. You now have much less parens resulting from nested function calls;
2. You get partial application by any argument, not just the last. map[;list] is a "functor" that applies its argument to "list";
3. Corollary to this, chaining functions together is now much easier even if you need to supply a parameter other than the last: f[;x]$g[y] (assuming $ stands for apply; it might be wortwhile to take empty space for application)
4. Further you are able to unify many aspects of the syntax (if[cond;true;false]), which makes parsing easier for both humans and computers.
I've been porting the reconciliation algorithm in SKS to Golang so Hockeypuck can peer with SKS servers. I think it will be very useful in other applications beyond keyservers. The mathematical definitions of finite fields and polynomials are elegant in OCaml, and I definitely understand the choice of language from that point-of-view.
If you want to see a comparison of finite-field arithmetic and polynomial factoring in Go vs OCaml, my recon port is in a separate project called conflux (https://github.com/cmars/conflux). It's an incomplete work in progress, needs tightening up, tail-call elimination, etc. but early feedback is welcome.
As a developer unfamiliar with OCaml & without much formal mathematics background, I had a hard time understanding some of the intent of the SKS sources -- in those cases, conflux is a straight-up port from OCaml with unit-tests also ported from SKS to back it up. Some of it, I understood the math concept, but not the OCaml, so I ported from SymPy instead.
Wolfram Alpha was also helpful to validate my work and create test cases -- it does polynomial factoring over finite fields!
I was mentioning it in my previous comment to provide perspective on my opinion of Go.
I am a big supporter of the idea that all languages have their advantages anyway :)
