As someone who used Go in the past for work and now uses Haskell, I can say that the advantages of Haskell over Go are more than "just theoretical".

In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell.

The ease of refactoring creates an incentive to improve code.

Seems like Go and other imperative languages are easier to start a project off with, but functional languages really shine when the code becomes really large and complex.

I can agree with that, but once you are experienced with functional languages I think "easier to start off with" becomes a very low value. I'm assuming by start off with you solely mean "starting a new project" and not "starting to use language from scratch".

At least that seems to be what has happened in my case.

I find that the confidence that refactoring will be easy helps me tremendously with velocity when starting a project.

My experience is the exact opposite. Maybe we work on very different kinds of problems, or maybe it's just because we're different people.

> Maybe we work on very different kinds of problems, or maybe it's just because we're different people.

In the interest in figuring out which, what problems do you work with and what are your principles/beliefs/guiding principles in software? :P

I work on rest APIs mostly and the Internet of things.

C# has had excellent concurrency support for quite some time, and is most definitely a utilitarian language.

Of course, the elephant in the room is needing a windows-based infrastructure ... but if that's not a huge barrier, it's not an unreasonable choice.

I keep forgetting about C# and F#, but with Microsoft embracing open source they may become actually interesting for people outside the windows world.

It might not be common knowledge yet, but C#, F#, and .NET are fully open source and cross-platform. Development is done in public on GitHub (https://github.com/dotnet), and pull requests are accepted from the community. You can even get a support contract from Microsoft and call them up to troubleshoot your .NET project on Linux. No Windows required.

Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.

Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the state in the parameters so the state is explicit and visible rather than a hidden something inside a class.

Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem.

With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code.

It kind of depends what your priorities are, if it's correctness or development speed.

> The difference is that with Haskell or Erlang you get hard > guarantees about side effects, but access to imperative > libraries is very difficult.

Well yes, I can just live without imperative libraries because it is so natural to have single assignment (in the same scope) that I do it even in other languages. Accessing imperative libraries is possible though, just think about the C libs. What would you implement in Erlang the imperative way or which library do you miss exactly? The ecosystem is definitely smaller, but you can get support, some of the smartest software guys hang out on the mailing lists and IRc as well. I got absolutely amazing help from both when we worked on a Erlang project.

> It kind of depends what your priorities are, if > it's correctness or development speed.

Yeah and also how much fun you want to have. :)

Using Erlang is great but not many devs out there for hire, on the other side you have two seasoned Erlang devs they can do a lot. Contractors FTW!

Btw. what about using ASN.1 with Erlang? How does that change the correctness / development speed?

> The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult.

In my experience creating Haskell bindings to say imperative c libraries is pretty easy. What imperative libraries have been hard to access for you personally?

> The difference is that with Haskell or Erlang you get hard guarantees about side effects

As far as I know Erlang doesn't give you any guarantees about side effects. You can call side-effecting functions at any point in your program, just like in Clojure or OCaml.

Python is my longest standing favorite language. But after working on a large python project I am cured for life of dynamic languages. I would not use them for anything over ten thousand lines of code ever again if I can help it. Go is now my favorite language.

>But Go is still a much better choice for getting things done.

What makes you say this?

Experience. I still don't quite understand it fully, but I'm much more productive in Go than any other language I've used, and I have deep experience in about 8 popular languages and passing experience with another 12. I can list things that contribute to that, but a list of ingredients does not equate to a culinary masterpiece. Other people's experience may vary.

Being a "boring" simple language with limited options for implementation means more focus on the problem and less on the infinite number of ways to solve the problem "elegantly". But there are a lot of other factors too. Static typing helps once the code base gets above 5000 lines, for example. Fast iteration from making a change to running the tests again also helps.

Maybe you should write a blog post and list those reasons and post it here. Would probably create interesting discussion.

Reasonable question,seemingly phrased without ill intent. Do not understand downvote.

This is what I think (hope?) Elixir could be: a bit more practical (familiar? convenient?) language with the same concurrency support as Erlang. Maybe after another couple years of maturing libraries.