
Ask HN: Keep Python or switch to Rust/OCaml/Haskell? - mccajm
Using Python makes hiring easy, but it&#x27;s hard to verify and bugs are frequently missed when code is pushed to production. Safe languages with strong typing like Rust, OCaml, Haskell catch more bugs before deployment and are easier to verify, but are hard to learn and hard to hire for.<p>Does any one have experience of introducing these in mission critical environments? Was the shift worth the effort or is sticking with the status quo a better policy?
======
trcollinson
Before going down this path, I suggest you pick up and read The Mythical Man-
Month. The experience the author has closely matches my own experience.

What you’re describing has very little to do with python and a ton to do with
your software developers and your environment. If you have bugs that are not
caught before you reach production, how is your testing? Do you have a good
level of unit test converge which can easily catch type safety issues? Do you
have integration test and regression tests?

As the mythical man-month states there is no silver bullet. No change in
language will solve any significant portion of issues without further changes
to your process. Nor will it increase productivity in any significant way.

It also mentioned the theory of irreducible numbers of bugs. Changing
languages will change where you see bugs but not the number or severity of the
bugs.

Of course you also have the second system effect which can be quite
interesting. It basically states you’ll have many of the similar issues from
your first system but also a bunch of new ones from your second.

So what do you do? All is not lost. I would focus on making small but
meaningful changes within your current team and environment. You’ll find the
most long term success there.

Going with a new language is new and exciting but it’s also extremely risky.

------
cjbprime
Are you using the optional types in Python? Plenty of people (i.e. most) are
using non-functional languages in production. There are probably many best
practices you could adopt to cut down your bug count without throwing away
your code base.

------
a-saleh
It depends.

If I would have at least one other developer excited about more advanced
static types, I would try to sell to the project lead something along the
lines "Hey, me and $OTHER_DEV would like to take
$SMALL_PART_OF_THE_APPLICATION and try to rewrite it in
$LANGUAGE_OF_YOUR_CHOICE ... we think the type-system should catch quite a lot
of those bugs we have been dealing in prod!" If the lead will take you up on
that, you might have a nice way to introduce the language and figure out if it
really is that much better.

If that is not an option (i.e. no easily identifiable sub-component/service)
you still might be able to add types through mypy, and maybe even investigate
something like mokeytype

If there is really strong pushback to do static-type checking, you can still
make mission critical systems in untyped language. Erlang does this, and you
can take the lessons learned from i.e. erlang and apply it in your python
code-base. Based on my experience, limitting local state, and use more
functional approach does wonders to testability and stability.

If the team is not a fan of functional programming, Maybe even throw in some
advanced testing techniques, like fuzzing endpoints, doing property-based
tedts or if it is applicable something like chaos-monkey :)

If there is no time for that, then focus on the process. Good review culture,
good test-writing culture, have CI and integration tests ...

To be honest, I would try all of these, starting from the last suggestion,
making my way to the first :D

[1]
[https://github.com/Instagram/MonkeyType](https://github.com/Instagram/MonkeyType)

------
kjeetgill
Naturally there are tons of aspects to consider for a change like this; the
biggest probably being your team's existing experience, preferences, and the
kind of software you're building.

A ton of python programmers love go (aka golang) and at least where I work
thats what out python codebases are turning into. Those are mostly command
line tools but go should work well for services.

If you're building service I'm going to throw out an alternative that you
might not want to hear: Java or Kotlin. I personally prefer Java but coming
from python it is going to feel repetitive and verbose. They're a kind of
sweetspot between straight-forward, battle-tested, and popular.

Compared to Rust, OCaml, Haskell either Java or Kotlin will probably: \- Have
a larger talent pool to hire from similarly to python. Java programmers won't
have a ton of trouble getting on board to Kotlin. \- Have a large ecosystem of
library support similar to python. Kotlin has access to java's substantial
library ecosystem. \- Have fewer new programming language concepts to learn.
(I think java just has primitives and generics?) Kotlin has more going on but
you won't need it all at once. \- Produce a codebase more architecturally
similar to your python code base. I imagine it will be fairly more straight
forward to migrate.

Nothing against Rust, OCaml, Haskell, I've dabbled in them and they're all
compelling. But as a frequent python programmer myself I'd say Java and Kotlin
make more sense given your concerns about hiring and migrating python.

Disclaimer - I'm a big fan of JVM land. I suppose most of what I said could
apply to C# and F# too but ... ehhh.

Hope this helps! Let us know what you do!

------
oftenwrong
Define "mission critical". Are people going to die if bugs get shipped? If so,
be aware that static type checking will not get you there alone, but it should
be considered mandatory.

Beyond that: If your team is most familiar with Python, it is probably best to
stick with Python. [http://mypy-lang.org/](http://mypy-lang.org/) might be the
best option: you get static type checking for new code, you can add static
type checking to your existing codebase, and you get to use something you're
already familiar with.

I recommend reading
[http://boringtechnology.club/](http://boringtechnology.club/) \- especially
the "let's switch" part.

------
rs86
I used elixir at work for a few projects, and we will use it in more projects.
We rewrote a rails app using the Phoenix framework and now we are using elixir
in services.

From my anecdotal experience functional programming leads to code that is
easier to understand and test. You can make quality code in OOP, but I think
functional programming makes it easier.

We also used Elm for a few prototypes and we're immensely pleased. We do not
use it in production because static typing + purity is not something you can
do easily find devs for.

Also, Erlang's OTP and BEAM are a pleasure to use.

------
steveklabnik
[https://www.rust-lang.org/friends.html](https://www.rust-
lang.org/friends.html) is a list of companies using Rust in production
environments, and [https://www.rust-
lang.org/whitepapers.html](https://www.rust-lang.org/whitepapers.html) is a
list of whitepapers we're building up. Both may be of interest!

