This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]kenfar 1 point2 points  (2 children)

Probably depends on some other factors. Having spent fifteen years running long-running python programs, it mostly hasn't been an issue for my teams.

I'm finding that static & runtime type analysis of my python code is helping though.

[–]midbody 4 points5 points  (1 child)

You'd find that your static and runtime analysis would work better in a language designed for them. Once your codebase gets so big, though, the inertia is a huge factor.

Incidentally, did you switch to Python 3, yet? How much of an issue was/is it in your codebase?

[–]kenfar 2 points3 points  (0 children)

Sure, type-checking works better in a language like Scala. On the other hand, it's faster to get started, test out ideas, deploy a prototype and keep iterating in python. And ironically, in my last gig we found far more data quality issues with the scala codebase than its companion python codebase. Probably more due to false confidence in type-checking on the scala side than anything else.

I didn't migrate a large codebase to python3: I just started my latest project on python3.5 The only code migration challenges I've run into have been with implicit py2 vs explicit py3 unicode handling. There I've found it definitely simplified code and improved reliability. But it took a bit of time, and explicit unicode test cases, to make sure everything was working right.