6 ms·

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. Lon

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.

dmytrish 9y ago
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?
- sudhirj 9y ago
  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.
- sarabande 9y ago
  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.
8fingerlouie 9y ago
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 https://www.python.org/dev/peps/pep-0484/#non-goals
- sarabande 9y ago
  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.
  - icebraining 9y ago
    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.
- cies 9y ago
  This may bring it to more-less Go's level, but is nothing close to what Haskell can do for you type-wise.
- stewbrew 9y ago
  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.
  - icebraining 9y ago
    No, it's static. You run the "mypy" command, which statically analyzes the Python code.
  - 9y ago
deleted 9y ago
[deleted]

dmytrish 9y ago

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?

sudhirj 9y ago
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.
sarabande 9y ago
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.

8fingerlouie 9y ago

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 https://www.python.org/dev/peps/pep-0484/#non-goals

sarabande 9y ago
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.
- icebraining 9y ago
  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.
cies 9y ago
This may bring it to more-less Go's level, but is nothing close to what Haskell can do for you type-wise.
stewbrew 9y ago
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.
- icebraining 9y ago
  No, it's static. You run the "mypy" command, which statically analyzes the Python code.
- 9y ago

deleted 9y ago

[deleted]