1–8 of 8 posts
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?
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!
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.
Beyond that: If your team is most familiar with Python, it is probably best to stick with Python. 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/ - especially the "let's switch" part.
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
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.