I found tooling good, easy to use, fast. Most things just worked out of the box. There is a single entry point - the go command - which allows to build/install/remove packages and executables.

What I liked the most (although it's probably irrelevant for many) is that setting up Emacs environment took me only 30-40 minutes. go-mode, go-eldoc, go-autocomplete, go-rename required little to no extra tweaking delivering a pleasant, virtually bug-free development experience. I especially liked go-playground which provided me with almost repl-like functionality.

Documentation for the language, the standard library, tools, third-party packages is well written. It is approachable and beginner-friendly but comprehensive at the same time.

To sum it up: excellent.

Go was easy to set up, easy to use. Abundance of documentation and ready-to-use libraries written clearly and concisely helped a lot. Language-wise I had experience not dissimilar to what I had with AWK - somewhat awkward but straightforward - KISS principle at its fullest. I think it is a good language that anyone can start hacking without having to read a Category Theory book.

The flip side of the coin is not that bright I am afraid. There is no a standard way (at time of this writing, at least) to lock dependencies. It is not a problem for small one-off projects, but I can't image how people are able to develop/maintain larger code bases without falling into cabal hell. Not dissimilar to Haskell, NixOS could be an answer to that problem.

Another observation, and it does stand out, especially after Haskell experience, is that language-wise it feels somewhat… lame. Which is not necessarily a bad thing. I've got mixed feelings about it and will probably write a post or two to get into more details.

Back In 2016 haskell-mode with interactive-haskell-mode and structured-haskell-mode for Emacs provided a well-rounded development environment. I am not sure what has changed since then, but I could not glue it all together and spent at least three hours trying to make it work cohesively. I ended up using intero-mode and brittany for code formatting. It worked reasonably well, yet determining a type of highlighted expression, especially if it involved polymorphic functions, was highly unreliable. I had to use typed holes all the time. Worst of all was that repl within Emacs tend to produce scary error messages - "unfathomable operation" (or something along the lines) - every time I did anything IO-related. I had to run repl in the terminal to avoid that.

Documentation for most Haskell packages is scarce at best. The majority of libraries provide but a few pointers, merely remarks for the authors themselves, rather than a comprehensive documentations for their users, let alone "getting started" guides or tutorials.

Hoogle is your friend and works just fine from command line/Emacs. It has been invaluable and I wish all languages would provide something similar. The problem, however, is those Haddock pages are hard to navigate. "Synopsys" is useless when there are more than a handful of functions (which is true in most cases) because it does not scroll (!!), effectively displaying only first 10-15 items. The only sane way to navigate through e.g. 100+ functions in ByteString library was calling w3m from within Emacs.

I used stack for building/compiling. It was OK. I think it has become even better over the past two years. My only gripe is that it lacks search command and something like deps fetch/update/remove to simplify handling of dependencies.

Using Haskell was surprisingly hard. When searching for information scattered through Haskell Wiki, StackOverflow posts and multiple blogs I felt more like a detective or investigator rather than a software engineer. Had I had something akin to Real World Haskell but up to date, the whole process could have been smoother. Alas I had not and I struggled.

Another observation I made was that my intuition about performance was almost always off. GHC provides fantastic tools for profiling and it was the only way for me to improve performance. Laziness of the language changes the run time behaviour drastically, and, compared to strict languages, that is something to always keep in mind. I should write another post about the journey to cut down the run time from 144 minutes to 17. It is almost a detective story. All I can say here is that performance hits were never where I expected them to be.

update 05/09/2018 - the post has been published.

Setting up Emacs environment was straightforward. There is an excellent merlin tool that provides auto completion, type information, source code navigation and integrates with Emacs seamlessly. There is also a fancy repl called utop that I think far exceeds any stand-alone repls out there in terms of usability and number of colours in use. And also there is an easy to use and feature-full packet manager called opam. I would consider it being superior to Haskell's stack tool in terms of usability if not feature-wise. The icing on the cake is the dune build system. It is insanely fast, although as everything (it would seem) coming from JaneStreet feels a bit too opinionated. Overall my impression of the tools is positive, Go-level-like or even better.

The story is not that great wrt documentation. While many packages have concise and comprehensible READMEs, tutorials on the official web-site are mostly outdated and/or incomplete. Real World OCaml is also somewhat dated and is heavily biased towards Core - the standard library replacement. There is a newer edition of the book in progress but still it is Core (or rather Base)-biased and does not touch on some other excellent libraries out there.

The ecosystem is not that healthy as Go's and definitely not as vast as Haskell's but I found it good enough and, more importantly, useful. For example, I could install a package where the latest commit was 5-8 years ago and it worked straight out of the box. That's something unimaginable with Haskell.

I fell in love with OCaml. It's a simple, explicit language that is pleasant to work with, has strong, sophisticated type system that actually guides the development process. It does not try to produce scary, intimidating error messages ☺. The type-level language has different syntax from the main language, arguably making code easier to "brain-parse".

A pleasant deviation from Haskell, I think, is that the community seems to prefer writing libraries with the goal of getting job done, not to defend a CS thesis. I used batteries because I was looking for something that could interleave IO with pure computations. So I found Enum and a lot, lot more in there. I think it's an excellent library and somehow I find it more to my liking than Core.

I also was stunned by how effortless it was to write a C stub. Just throw in a C file into the source directory, declare external function signature and it's done! I couldn't find a "glob" library so I used find tool in the first version. The program was building a huge pattern and then read the command output using a pipe. It felt somewhat unfair because find was doing all the job. After some research I stumbled upon a piece of code that called a libc function in OCaml. So I wrote ~20 lines of code that wrapped the libc's glob function and used it instead. That painless, almost native-like interop with C code was something I did enjoy.