We've been using Go at work for 2.5 years now and it has become my primary language of use at this point in time. I hate it. I hate it like hell. It's like they decided to take all the things that make other languages good - such as safety, brevity, intuitiveness, versioning and proper project structuring - and threw them out the window. As far as I'm concerned the good things about Go (large community, fairly efficient generated executables) do not outweigh the bad.

We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it. And we still do. Finding developers is also an issue, as most developers do not really want to learn a new language, and Go is still not that common in enterprises (I used to be like that myself, but I've learned long ago that this shouldn't be such a big factor when thinking about a new job).

You can make the case that we're simply not good enough developers or Go is just not a good fit for the type of developers we are. Maybe. But the choices made in designing this language, and its popularity, absolutely baffle me.

Well, somehow this sounds to me like you are doing it wrong. Yes, you probably heard that before, but when you say things like 'proper project structuring' I think that you probably try to do something in a way that it is not meant to be used.

But at the same time you probably have good reason to try that, as that was the way you did it in the past (with other languages). So while Go allows you to quickly learn to write code, it is a much harder challenge to learn how to structure you code in simple small packages. In the end that brings a lot of benefits (testing is easier), but if you try to create a project with very few packages you will go through lot of pain due to the lack of structure.

Its very similar with interfaces. Programmers coming from other languages mostly ignore them in the beginning and it takes a while until they understand that exporting types from a package is a failure and that interfaces would have been a much better choice.

In my opinion, the key to successful Go development is building many small, well tested library packages while using interfaces a lot.

Appreciate the comment. I was largely referring to very large projects. When it comes to smaller projects, but really any Go project, we've moved to the structural recommendations in the Go documentation a long time ago, which did improve things a bit, but really there are almost no good examples out there for really large projects.

Your point about interfaces is mostly correct though, and we're progressively learning to utilize them better.

"We've spent so much time fixing obscure bugs and behaviors that betray everything we've learned in the languages we used previously in our careers that it was really not worth it."

That sounds very frustrating; I'm sorry your day-to-day became consumed by such things. Would you mind providing an example of such an "obscure bug and behavior"?

I wouldn't call it my day-to-day, but sure, here are some examples:

1. We have a client component that makes HTTP requests to a server component of ours. We've had production downtime issues in the server caused by filehandle exhaustion. Turns out the client was creating a new HTTP connection for every request rather than reusing connections, and it did that because Go expects you to read the response body in its entirety even if you don't need it, otherwise connections aren't reused. And in many of the cases we thought that we were reading the body in its entirety, for example in locations where the JSON decoder was reading and decoding the response, but sometimes it simply did not really read it in full, despite definitely parsing the entire JSON structure returned from the server. A "bad" net/http client can easily bring down a net/http server.

2. We've had several instances of severe memory leaks, with the Go garbage collector not releasing or reusing memory ever. These were sometimes very difficult to track down with the available Go profiling tools (pprof for example), and even more difficult to understand. And in some of these cases we're still not even sure we understand despite fixing the issues, mostly because our code is not different than examples in the Go documentation itself. For example, we had functions that read a stream of bytes into a byte slice, then cast that byte slice into a string and return it. We would intuitively think that the memory allocated for that byte slice would be released, but apparently the casting performed constitutes an active reference of the data (rather than a copy of it), so the data is not marked for garbage collection. But the most obscure part is that it was never released, even after the cast data had no more references to it. Memory management in Go is very hard for us to reason, despite the language claiming that developers needn't worry about this subject as it is handled for them.

This is just the top my head, I can bring more.

Your #1 issue is mentioned clearly in the documentation.

Mentioning here verbatim -

> The http Client and Transport guarantee that Body is always non-nil, even on responses without a body or responses with a zero-length body. It is the caller's responsibility to close Body. The default HTTP client's Transport may not reuse HTTP/1.x "keep-alive" TCP connections if the Body is not read to completion and closed.

Regarding #2, I think what you are taking about is this - https://blog.golang.org/go-slices-usage-and-internals (gotcha section). But maybe I am wrong.

Thanks for sharing. Which language(s) did you previously use primarily? How did you learn to program in Go? What resources did you use to "ramp up"? I ask because I am wondering about how to be introduced to such issues early on and learn how to fix them before they become more serious like causing "production downtime" because the response body isn't being completely read and closed.

My first resources were the Go website, specifically the following pages/articles: How to Write go Code [1], Effective Go [2] and Frequently Asked Questions [3].

I also read Alan Donovan and Brian Kerninghan's book "The Go Programming Language" [4]. So mostly these four, and of course simply writing code (along with the standard library documentation [5]).

Since then I've also gained a lot of info and insight from various articles and blogs, such as "Debugging Performance Issues in Go Programs" [6] from an Intel blog, various posts from Peter Bourgon's blog [7] and Dave Cheney's blog [8], both of which I highly recommend. Oh, and "The complete guide to Go net/http timeouts" from the Cloudflare blog [9] is also worth reading.

Previously I was mostly a Perl developer, but I also work(ed) a lot with JavaScript, and to a (much) less extent with Haskell, Racket and Nim.

[1] https://golang.org/doc/code.html

[2] https://golang.org/doc/effective_go.html

[3] https://golang.org/doc/faq

[4] http://www.gopl.io/

[5] https://golang.org/pkg/

[6] https://software.intel.com/en-us/blogs/2014/05/10/debugging-...

[7] https://peter.bourgon.org/articles/

[8] https://dave.cheney.net/

[9] https://blog.cloudflare.com/the-complete-guide-to-golang-net...

I can't speak to Haskell because I've never used it in a work context. I have extensively used Python and Go in both small and large codebases, however.

1. Long-term supportability: I'd definitely favor Go here because of the type system. I work(ed) in large Python codebases that deteriorate because ensuring correctness requires enormous amounts of test coverage, and refactors are absolute nightmares. People tend to rewrite code instead of refactoring because it's too difficult to figure out what on earth is going on. Deployment and cross-compilation is also a breeze with Go binaries, which has been another historical painpoint with Python.

2. Bugginess of typical code generated in the language: Favor Go for the above reasons. When the code really has to work, I choose Go. If I had more Haskell experience (and if it were a nice language to deal with), I'd probably favor Haskell for its correctness, because I still run into annoying nil pointer exceptions and array out-of-bounds in Go relatively often. I use Elm (Haskell-influenced frontend language) and love it for its lack of runtime errors.

3. Availability of developers: I'm sure there are more Python developers than Go developers. I work with data scientists, and I don't know many who are comfortable in a Go ecosystem, so if you're hiring lots of scientific computing folks, I'd go with Python. In terms of software engineers, when I've hired folks, a lot have expressed particular interest in working in Go even with no prior experience, which is a good signal. Easy for Java/C-style programmers to pick up.

Note that: You can do both/all three. We extensively use Go for systems building, and Python for data science.

As for 1), if you can use Python 3.5+, and the native type hins, you can use mypy to do type checking, and give hints to developers/ide's about acceptable inputs :

    def greeting(name: str) -> str:
        return 'Hello ' + name

https://www.python.org/dev/peps/pep-0484/#non-goals

Agreed -- definitely possible. The issue is more than in organizations I've seen, the group of data scientists does not agree on using type hints, because a lot of them want to "move fast," and not be bothered with what they consider irrelevant, low-level details.

This, sadly, brings us back to the problem.

I'm of the opinion nowadays that these rules need to be mandatory at a group level (i.e. either enforced by the compiler or by convention at your workplace) to be useful.

Python typing has the advantage of being gradual, so you can introduce types in certain places (e.g. core packages) without being forced to type everything.

AFAIK this doesn't imply static type checking though. The types are at best checked at runtime, aren't they? If so, it doesn't really help much.

It doesn't check runtime (AFAIK neither does Go, it checks compile time). In fact, Python fully ignores any type hints.

When coupled with mypy (http://mypy-lang.org/) they can be used to do type checking at "compile time", and with DropBox's pyannotate (https://github.com/dropbox/pyannotate), they can even be auto generated for existing code.

I'm not saying Python with type hints is better than a statically typed language, merely suggesting a possible solution if Python ends up being the preferred language.

Personally i love Go for the things i've used it for, and i've written and maintained large code bases in Python, and hated every minute of it. The same can be said for large code bases i've written in C, or even Java.

I've written kernels for GSM mobile phones, software for sortation devices (airport baggage sorters, mail sorters, etc), banking software, and despite our teams best intentions, given enough time and customization to meet customer demands, there is always some remote corner of the code that ends up as a "steaming pile"

  Mypy is a static type checker for Python.

From the intro in the MyPy docs. MyPy is a legitimate static type checker for Python, with similar capabilities and limitations as other statically typed languages. There's an escape hatch to get you back to dynamic land (the `Any` type) and you can do naughty things at runtime if you use it (in the same way that you can in languages like C#), but using Mypy you can get decent type checking without actually running your program.

No, it's static. You run the "mypy" command, which statically analyzes the Python code.

This may bring it to more-less Go's level, but is nothing close to what Haskell can do for you type-wise.

Thanks for the analysis!

On a side note: might it be the case that the Go codebases you've worked with are just newer/smaller than the Python ones? Do you work with Go systems that feel as much legacy as you've encountered with Python?

Yes, I think re:size, I've typically worked in (based on lines of code) larger Python codebases than Go ones, however, I'd still consider the Go codebases large.

In terms of legacy code, though, my metric is the following: When I haven't touched code in one year and need to go back to fix something, what language would I want that code to have been written in?

I prefer that code to be in a system that's easy and obvious to reason about, i.e. with a type system.

Think part of the rationale for building Go was to have something that would serve the truly massive scale of the codebase at Google. It seems like they’re already making sure it scales that way.

Ask your data scientists, who already use Python.

If they are opposed to Haskell or Go, then what are you going to do - fire them? Are you budgeting time/money to retrain them?

Your customers don't care what you use, unless you are selling them the actual software. (But then you would know what your customers want, and wouldn't be asking this question.

If you use language X because of a perceived marketing advantage that your customers will see you as "a cutting-edge, next-generation company" then can you estimate how much that marketing is worth? And compare it to other marketing approaches?

My view, as a long-time Python user, is of course Python.

It's not unlikely that data scientists can continue using Python, while development in general uses Go, though.

The data science code is delivered as Docker images. It doesn't matter what their code is written with.

Having worked in an environment where we had data science people, I can tell you that we talked a lot about helping them write code, and it never really happened. Let them use what they're productive with, and let your devs use what they're productive with. If those are both the same language then that's nifty, but I wouldn't bother making it a goal.

The data science team at my workplace mainly uses python, while the rest of all development is done in Go. Works mostly fine.

I have experience using each of these languages professionally, working in a team. Each of them have their own foibles that you'll be constantly railing against:

Python:

Large Python projects require discipline. To make it work, you'll need to adopt a rigid style, like DI, and use it religiously. It can be done; people do it, but if you think using Python will lower the barrier to entry to getting on the team, think again. Large projects in any language require talented people.

Go:

I don't like Go, so I have the least experience in it out of the three. There are positives, like fast compile times, but lacking generics and exceptions just makes Go annoying to me.

Haskell:

I have written a quite incredible amount of Haskell and before using it in a team, I was a huge proponent. Haskell is a well-designed language, but suffers a few major drawbacks. Large Haskell programs can take an age to compile; this is a productively killer. Universally agreed upon good styles for writing large Haskell programs don't exist. Library support is lacking. Space leaks will bite you. I would strongly advise against starting a large Haskell project.

To wrap up, in terms of your criteria, the language you use isn't going to change things very much.

* Each language has a good community for long term support,

* Complex code in any language is buggy; simple code in any language is less buggy,

* Good developers are hard to hire,

If performance is important, Python and Haskell perform similarly for code that people actually write. Go does better.

What constraints do you have? How important is scalability for this project? Do you need lots of parallelism, fast single-core execution, low memory usage, etc?

You mention long-term support. I'd have to give Haskell high marks on that one. You can use Stack to get highly repeatable builds with LTS releases of Haskell and the packages you rely on. More so than any other language I'm familiar with, Haskell does a great job with long term support and builds that should be 100% reproducible in 5 years.

As far as bugginess, Haskell obviously wins here again. If you're getting runtime exceptions in Haskell then you're doing something wrong. If rock-solid stability is important to you (and you list it as #2 on your list, so I assume it is), then Haskell is hard to beat.

Availability of developers is a tough one. Python clearly has the advantage here, despite being markedly worse on the first two sections. I don't know many Haskell developers, but the Haskellers I've met have all been exceptional software developers in general.

I find it unlikely that you're going to be able to hire 20 people who already know Haskell, unless you're willing to hire remotely. However, if you're willing to teach, I think it could work out. For example, the Elm language would be a fantastic gateway to Haskell. Build your front end with Elm and make new developers work on the front end for a few weeks. Once they're comfortable with it, switch them to the back end.

> More so than any other language I'm familiar with, Haskell does a great job with long term support and builds that should be 100% reproducible in 5 years.

Really? I've never used Stack, but the experience of building dependencies from Hackage has always been awful in my experience. Even if Stack did change the game (I think it pins down the exact versions of package dependencies, I would figure using third party Haskell libraries is still a major pain:

The reason is that the types in the APIs are very elaborate (elaborate types of course is generally a Haskell thing), which means very often they are not super stable. So upgrading libraries will be no fun. And you will want to upgrade, whether you use Stack or not.

(Note, I haven't used Haskell seriously in a long time. Maybe someone with more up-to-date experience can validate these thoughts).

Stack has helped things a lot. I recommend giving it a try. I've been very impressed.

Finding good developers is a struggle, almost regardless of where in the world you've set up shop. So finding 10-20 good developers, a significant portion of whom would have to be quite senior, probably means your "3. Availability of developers" should be "0. Availability of developers".

Basically, any language / ecosystem that should meet your most basic business and technological requirements should be heavily in contention if it is among the most widespread in the community where you're situated. And similarly, if a language is significantly less common than a language that meets the requirements, you probably shouldn't consider it.

Whether that is Python, Go, Haskell or something altogether different, only you know.

One of the chief advantages Haskell (and, to a much lesser extent, Go) has over vanilla Python is that static typing vastly improves upon #1 and #2.

If you do end up going the Python route, I suggest you enforce using Python 3 type annotations, and use an external validator (such as mypy) to try and capture as much of that value as possible.

As others have mentioned: It depends on what you are going to build, so pick the tools which fits the job best. In the end, you can build good products with all three of those languages, but not every product can be built well with any of them.

Long-term supportability: As long as you are not choosing a proprietary tech like Microsoft Access, you should be just fine. There are a lot more code bases which suffer from bad quality than from abandoned base technologies. So its much more important that you know exactly how you want to use a language and let your team create rules (bottom up) on what they want to allow themselves to do and what they don't want to (like a semantic style guide), than to pick the golden language in the first place.

My advise would be: Start by building a team. The technologies will be the result of what your team is able and likes to use. One condition: Only allow technologies they have positive personal experience with (no "I always wanted to try XYZ").

Go for the largest community and biggest number of mature libraries, go for Python 3 (make sure it's 3!). It's the most mainstream in your list and for data scientists it's your only choice I would also say (when looking at Tensorflow, Numpy, Scipy, Pandas etc.)

I initially read this as, "Choose Go for..." rather than "Opt for..."

I know it's not in the options you listed, but why not Scala?

It has the nice things of the languages above, combined together:

- a concise high-level programming language

- a compiler that helps avoiding bugs

- fast runtime

- access to a great ecosystem of libraries

(In better words: https://github.com/scala/scala-lang/pull/852#issuecomment-37...)

Moreover, if you work with Data Scientists you might find convenient working in Spark's native language.

A great thing about Scala is that you can either use as a better Java (availability of developers) or go fully functional-category theory like Haskell with libraries such as Cats.

Another argument for Python is The Pilot System rule from The Mythical Man-Month (https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pil...), which my experience completely supports. You need to focus on developer speed rather than execution speed or even correctness -- you will learn a lot and change your assumptions, take edge-cases into account etc. Only when you have a stable system it makes sense to start to isolate performance bottlenecks and replace them with optimised, low-level code.

A very high abstraction language for the glue (python, R, lua, ...) and a close to the iron compiled languange for the heavy lifting (C, C++, Fortran, Go, Rust, ...)

or you give julia a try.

This is exactly my approach to bioinformatics. Python for scripting. Go for speed. Find it fairly easy to switch between the two. Really hope Go catches on more in data science. Go equivalents of numpy and matplotlib, and it would me massive.

It really depends on what you are trying to do and whether this is well-supported by the language.

Data science stuff? Python of course. Haskell has things like repa but still very immature compared to Python. You will have to reinvent the wheel a lot if you choose Haskell.

But if your developers are going to do something very different from data science, say building a typical web app, Haskell can be a good choice. As usual refer to Gabriel Gonzalez’s State of the Haskell Ecosystem: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Haskell especially excels in (2): bugginess of typical code is pretty low even without extensive unit testing; Go probably fares pretty well but Python is terrible for a large code base. But on the other hand (3) could also potentially be an issue for Haskell, depending on the geographical location, whereas Python would likely not.

Having worked (and still working) in a Haskell startup, though I believe ultimately technology doesn’t really matter that much. The business is more important than the technology.

If you do choose Haskell though, my advice is that don’t use too many fancy type system features. A boring business app doesn’t usually need them. Stick to basic language features and perhaps just a dozen most popular language extensions; use the rest very sparingly.

You should at least mention what your business is actually aiming to achieve. Are you a web app, a data science startup, a service provider with a software stack, etc.

If you're a pure data science startup, most of your talent pool will be most proficient in Python, and the highest quality APIs will be in Python.

If you're a web app, going for Go makes more sense, as the language was built from the ground up with these things in mind.

If you're business tooling or service oriented.. I'd go for C#.. it has a huge talent pool, super high quality libraries and ecosystem, etc

No need to settle on one language. There is in fact room for 2 main languages (prolly some will simple come along like JS and Bash).

Python you already have, I'd not ditch it, it can live. Main thing it lacks, imho, is a type system which relates to 1 & 2.

I'd personally not care for 3 too much. You find less Haskellers, but also less competition, and according to many they are better.

I'd say all 3 langs you named allow point 1 "well enough". Point 2, I'd say: Haskell > Go > Python, with significant margins in between.

Didn't see anything for Haskell so I'll do that. Good link in general would be https://www.linkedin.com/pulse/haskell-data-science-good-bad...

- Python is established for Data Science vs Haskell You could use Haskell for whatever models you need (although finding 10-20 people for that might be a challenge) and it would be really easy to refactor for any changes you might have but I dunno if data science is something you'd use Haskell for. Most data science applications I can think of are either scripts to inspect/clean data (Python works well) and the rest involve a lot of trial and error (Haskell errors aren't great).

- Haskell libraries are awesome You could use Haskell for whatever important libraries you use on a regular basis - it's incredibly easy to write APIs for different languages in Haskell (which is great if you switch languages for some particular use) and it's easy to refactor (which is important in a new company that's likely to change a lot). Also, it's a lot harder to write shitty core libraries in Haskell.

I'd honestly recommend sticking to whatever language you already have code in. If you already have python models built, stick to them!

Whatever you choose, definitely pick a statically typed language if long term maintainability is more important than getting something out of the door quickly. Maybe a good middle ground would be python using mypy (type annotations) and if you can get any benefit from using the ORM, and the admin +and thus you are using a relational database) and building some kind of mostly CRUD app.

Nowadays, I'm in love with Typescript. Been using it for about 3 years and with the stricter settings it can be pretty safe, makes it very easy to refactor, vscode provides an "intellij and Java" like experience in the tooling side of things. No need to deal with threads, etc is a plus. No callback hell given asynchronous/await. You can use it for the backend and the frontend. Works wonderfully with react.

And if you really need performance and want something more "serious" and stable than the Js ecosystem, I can't recommend enough Dropwizard. Modern Java is not bad at all, and always you can use kotlin if you don't want to use Java for any reason.

I've been in a similar situation (choice between Scala / Python / Go), the first person I hired was a Go guy so that became the default. We ended up using Go for APIs / web stuff and Python for data science and modelling.

With Python your will be more agile. Python have many tools for you teams

- Data Science: Pandas, Scikit-learn, Numpy, ... - Web (Django,..) - APIs (Flask,..)

Also many Artificial Intelligence Tools and Apis of other services have support for Python.

The size the community is also very important. When There are a big community is more easy to find developers and events/meetups where the community talks about Python and use cases.

Haskell is also a good lenguaje and easy to learn but Python and Haskell are languages with differences https://wiki.python.org/moin/PythonVsHaskell

I apologize for going off topic here by saying go for language number 4. but hear me out.

I have been struggling with my business vs pleasure languages for some time now. I work 95% in C# but whenever I find willpower to do some hobby coding I go for Haskell.

Every time I go for a new hobby project after not coding in Haskell for a while I have to go through the hurdles of remembering how to set things up, downgrading from Visual Studio to Visual Studio Code with some broken Haskell language extension and last time before I started coding my new hobby project I asked myself: What would it take for me to make C# as lovable as Haskell.

I came up with these things which annoy me most (I know everyone has their own list): 1. Lack of higher order types 2. Lack of syntactic sugar for partial function application et al. 3. Lack of GADTs 4. Still waiting for those nullable reference types.

On the other hand I would get: 1. Great language server with support for refactorings, formatting etc. 2. Test tooling and frameworks and performance analysis tooling and frameworks. 3. Way bigger ecosystem of open source libraries.

While I see a reason to go for either C# or Haskell, I really don't think it's worth going for Python or Go instead in most cases. I just need a better type system than what Go has to offer (and Python doesn't do any type checks without 3rd party support). Hell, I'd go for TypeScript or PureScript before these 2.

C# has grown a lot in the past few years. With C# 7 you have all those fancy things like local functions, pattern matching, deconstruction, async improvements etc. You have a stable language and ecosystem, open source compiler and language server (Rosyln), free editor support if you want to save (Visual Studio Code) or if you want enterprise tooling you can go up to Visual Studio Enterprise. With .Net Core going into 2.0 the coverage of .Net is really broad, and Entity Framework and Asp.Net are being rewritten from scratch for all platforms. It's easy to do foreign language interfacing if you want to use some highly performant lib like LAPAC or something and someone usually already wrapped around it.

Btw, if not Haskell, check out PureScript

I think haskell is rapidly improving in this area. It suffered from every editor having it's own home-grown backend. Haskell IDE-Engine [1] is becoming quite stable in my experience (using it myself) and while providing all the basic features, it's based on the Language-Server-Protocol and thus has various plugins for your favourite Editor (vscode, vim, atom, sublime etc. I personally use vscode).

The development is also quite active and not run by one person anymore.

I am quite pleased to be honest.

[1] https://github.com/haskell/haskell-ide-engine

Have you considered F#? It doesn't enforce purity, but you get a lot of good stuff from the type system that you don't get in C#. Plus you get everything .NET gives you.

It depends a lot on what you are building. I'd recommend Python in general as it has more support but don't limit yourself to it as there might be some parts of your project were Go or Haskell can be more powerful.

Use the right tools for the job. If you are running your Python models in containers anyway, a suitable API will work with any backend language. Go and even the JVM (Java / Scala / Kotlin) ecosystem are great candidates. Our stack uses Python (models deployed as dockerized WSGI applications) for machine learning and web services written in Java for the backend. It is relatively easy to get developers who are comfortable in the JVM ecosystem and the tooling available makes it easier to build robust systems.

Who/what company is using Haskell at work? I'm really interested how/why it would be used those days.

I guess there are domains where it's adequate, but what are those?

Haskell can be fantastically fast (rivaling C for some tasks), and nothing can beat it for writing parsers. Relying on lazy IO can be risky if you don't know what you're doing, but I've been able to write log parsers that can crunch multi-gigabyte files as fast as my SSD can read them, all without ever going over 4MB of RAM.

Plus it's incredibly stable. Once you learn to avoid a few sharp edges (head, !!, etc.) you should never encounter an exception at runtime. Literally never.

Financial (some banks), crypto (HKIO), Facebook (spam fighting iirc), SaaS apps (JanRain, Wagon, etc.) ...

Haskell is a general purpose lang (unlike Go), and compiles to native code (unlike Python) which makes it quite fast running.

There's a list here:

https://wiki.haskell.org/Haskell_in_industry

Python because that's what your team knows. If they aren't already they probably should use Jupyter, pandas, numpy, ...

Then sprinkle it with a bit of Haskell on the stable algorithms for speed and correctness reasons. Haskell has fantastic abstraction and testing capabilities.

Go is probably not going to sit well with data scientists due to the lack of generics. It's a good language for API and CLI but not so much for developing generic algorithms.

Python is excellent for prototyping and small projects. When projects become older and bigger, the lack of strong typing makes maintenance very difficult. If you can keep your projects small, I recommend python. If your project needs to become big, why not using java? Even if I really do not like Oracle, the language (and tooling) works very well for big projects and java developers are as easy to find as python developers.

Python for all of the above.

To be more specific: Python 3.6, with type annotations and unit tests, and good libraries (pandas and others for the data, Tornado for Web, SQLAlchemy for databases etc).

But it's much more important to get your architecture right, to know exactly what is the data flow and what is supposed to happen when and where. No single language will give you answers to that, while the architecture might decide the choice of language(s).

My argument against Haskell is that you are likely to build the wrong thing righter. My experience watching those around me is that it takes longer to write, but 'if it compiles, it's correct.'

The problem is that you probably don't know what you're building, so you would want a more flexible language.

I would lean towards python for all things data science, and go for infrastructure.

That's interesting because my experience is the opposite. All code needs to change and grow, and Haskell's type system protects the functionality while allowing rapid iteration. I currently work in Python and I've worked in Haskell in the past. I certainly would prefer to still be using Haskell.

I'd choose Go. Has long-term support from Google. Generally easy to learn. Many less bugs in my experience than Python. Don't know enough about Haskell to comment.

Haskell. You'll be in a niche but a good niche to be in.

Actually, Python is a strongly typed language. What you mean in your comment is a statically typed language, which it's not.

Why not Kotlin?

I really like Kotlin too. Not very well established in data science though (maybe through Java interop, but Java is also not know for that application)

My default position for most business tasks would be to do this with Haskell. You asked for the three criteria: 1. Haskell as around for longer time than the other two options. It will enable new people to quickly grasp your code base, so even if some core members leave the team the system will support them actively.

2. A true winner. Haskell allows for using very abstract and generic code. If this works then it can be used in many contexts. In Go and Python your devs will write more low-level code that is less reusable. Just think about writing a function that adds 10 to its argument. In Haskell: add10 = (+10)

You can easily call this to add 10 to a number. You can never make a type error with this. But now: what happens if you are reading numbers from some incoming bad data? You may have been able to read a number or not. In Python you may have a value `x = None` and in Haskell x would be `Nothing`. In Haskell you can make your `add10` into a very reusable component which we call f: `f = pure . add10` and you can use it like this:

x >>= f

And it will work fine. In Python you need to write a new function which first checks if its argument is None and if yes it will return None, otherwise it calls add10() on it.

Or you have a list of numbers and we call it again `x`. To add 10 to each element in Haskell you do:

x >>= f

In Python (and Go) you would have to write a function which will map over x and apply add10 to each element.

What if you now have a function which may either return a number or an error message? In Haskell such a value can be used like this:

x >>= f

In Go or Python you would have to write a function which first checks if x is an error message and if yes returns it or otherwise calls add10() on its argument.

What if you wrote a function `x` which reads a number from the keyboard and returns it? In Haskell you would use it like this:

x >>= f

In Python you will first have write a function which calls x and then makes use of the return value.

In Go and Python you would have to write several different implementations to handle different contexts (absense of values, error handling, IO, DB requests, non-deterministic values, etc) and every single time they would look different. In Haskell this function will always have this body:

x >>= f

And this is only the beginning. Haskell allows you to write less code than dynamically typed languages. But your code will run very fast and have way less errors. In Python every function call needs to be looked up at runtime first. In Haskell you go to the function definition and save much overhead.

From my experience in 2017 with our production system was that nearly every bigger problem was due to some type error. Nearly always! This is what we get from a dyanmically typed language. The initial development time may be a tiny bit shorter, but then you will pay this many times with more debugging time and with time to write more tests. Only tonight one colleague had to stay some extra hours in the office because there was some strange bug in the Python code.

To outperform the competition you need to write ultra stable code that runs fast. Neither Go and certainly not Python can give you this. For scripting this is of course different. Our data scientists use R and this works fine for them. But with Haskell you can write very generic code, but without magic involved. In every single case you will know _perfectly_ what situation you are in thanks to the type system.

Your point 3: If you’ve got such a nice budget go visit some headhunter and try to find out what they have to offer. I can only say that I know people who are willing to move to get a Haskell job. You may want to consider to have some remote positions. But you may also need fewer Haskell devs because they will be more productive.

One other thing: nowadays Python and Go are pretty common. People learn it because those are popular languages and because the market has a demand. The days when Python was considered an esoteric language are long over. Haskell is learned because people are deeply interested in programming and not out of some necessity to earn money. Those might be the guys you are after.

For data science, python is the strongest language right now due to massive library support for anything you want to do. Its also the easiest to understand and find developers for (from your list of languages).

Go is also nice and will bring you support for types and high er runtime performance (but slower development speed and maintenance speed).

Haskell will be hard to find developers for, but the ones you find will be very good. But getting a team of 20 to use haskell will be a great challenge, and also the library support for data science is tiny.

It sounds like they already have a data science team, and they'll continue using Python. The OP seems to be talking about building a team of non-data-scientists to do UI, data fetching, and other user facing stuff. I don't think suitability for data science is a factor.

Surely the problems here are IPR opportunities?