Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent.
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.
I've written a moderate amount of OCaml and some Go.
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).
I love the package management in go and agree it is pretty good, but the lack of versions make me nervous. I do wish they reacted quicker to common criticisms like this and the missing generics, but I guess they want to take their time and do things right. What there is of go has been a pleasure to explore though.
Would you mind expanding on what is good about m expressions and how that could apply to go, I'm not familiar with them?
See [0] for an introduction to M-expressions, which was initially an alternative syntax for Lisp, but have found its way into APL and Mathematica.
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.
If you like OCaml but find Go lacking, you should check out Rust. I'm more of a Haskeller than a OCamlist, but the Rust compiler was originally written in OCaml, and it's influenced the language a lot.
I find this recommendation interesting because I am developing an OpenPGP keyserver in Go, called Hockeypuck (https://launchpad.net/hockeypuck). I started the project because of problems I ran into with SKS in a very specialized, write-heavy use case. SKS is developed in OCaml.
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!
Yeah, like I said, it was mostly during 2 years in college (in France in the close-knit network of research institutes and universities where the language was actually born) and OCaml is a wonderful language. It has numerous upsides (type inference, the mixed functional/OO paradigms, non-verbose, relatively fast, the awesomeness of pattern matching).
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 :)
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.