Writing software that's reliable enough for production | Hacker News Reader

Writing software that's reliable enough for production

pythonspeed.com

48 pointstodsacerdoti16 comments

I tried writing a production software system in Python in about 2009 using TurboGears (RoR but for Python). The whole system suffered from the well-known GIL problems so the project was rewritten in JavaEE. My understanding is that the GIL problem has been eliminated (or at least minimized) but I've moved on to Go for backend software. I still love Python but now only use it for scripting system tasks and data science.

I agree, I really like both Java and Python and I've typically used Java for anything that's a service and I've never been let down. I've owned a few python services and have been... disappointed with them overall but generally never because of *python* specifically. Usually the code just being an enormous untyped spaghetti blob and also being just bad code on top of it (the kind of thing where you look at it for 5 mins and could probably cut the runtime by 70% but you don't because nobody asked you to and this internal web page being slow is not high on your list of things that annoy you overall).

I recently started a side project and decided to use python for the backend and I'm not too far into it so far, but I can already tell I'm going to miss 2 main things:

1. the ridiculous amount of information a jvm provides by default (e.g. jmx) 2. java's speed/jit

So far, python seems fast enough, and I feel like I'll be able to make anything that I need to do scale in python, and that if I end up with enough users to make that not the case, I have bigger problems (like "my side project's customer support is competing materially with my day job for my time"). So I don't even think the tech, much less python, will be the scaling weak point with this project. But I'm still keeping an eye on it.

The article is about using Rust (for a Python memory profiler, to be fair).

GIL is hindering data science too. For instance, PyTorch DataLoader has somewhat limited throughput for any datasets where any part of item retrieval is implemented in Python.

For web backends people just use process/vm level parallelism behind load balancers, like with Node, Ruby, Lua etc.

There has been a lot of evolution since 2009.

Async I/O, type annotations, etc.

What do type annotations actually get you? So far, cpython only stores them and makes them available for retrieval. This is a sore point for me -- batteries not included; so there's an ever-growing list of third party bolt-ons that are mutually incompatible, a vast departure from the Zen "one obvious way to do it".

I use type annotations. They make it a lot easier to do things like refactoring. I've written a ton of Python since the early 2000s, and my experience is that projects above a certain size (and it's not really that large, like a few thousand loc) start getting hard to modify. There are also a few types of errors that reliably get caught by type checkers that you can easily encounter in Python code... for example, misspelling an exception name, or constructing an exception wrong. Simple typos in code paths that are not exercised in tests. The annotations also help you acclimate faster to code you haven't seen before (you can navigate to definitions / call sites more reliably), and lets Emacs / Vim / VS Code make better autocompletion suggestions.

In short, it helps me code faster.

Do you not test exceptions? It's really easy°, and I strongly encourage testing them.

  with pytest.raises(ZeroDivisionError):
    1/0

° note, it's not always easy to exercise all exceptions -- just, it's easy to make tests that fail if an exception isn't raised

I do test exceptions, I just don't test 100% of code paths.

Do you encourage 100% code coverage? Because I think that 100% code coverage is insane...

The problem is that as you approach 100% code coverage, the amount of effort it takes to test the remaining code paths skyrockets. At some point, you decide to stop writing tests. Then static typing steps in, and catches some bugs that were not cost effective to catch with testing. The exceptions are sometimes there because I am programming defensively... as in, "I don't think that it's possible for this condition to happen, but if it does, I'd rather raise an exception." Then I run mypy, and it tells me that there's no such thing as a VauleError.

The other factor here is that when I exercise poorly tested code paths (which again, I'm going to assume exist), it's often because I'm in the middle of working on something else. The simple typo or bad call is an interruption.

> Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... [ed. note, wow you added a lot as I was typing out my response to this]

Not as a hard and fast rule, but as a target to aim for. If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. I do a lot of my work in strongly typed languages; believe me when I say that code without type errors or variable misspellings can still be chockablock with bugs.

In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.

> ed. note, wow you added a lot as I was typing out my response to this

I only spend, like, two minutes editing a comment after I post. You must have had a stale browser window open.

> If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient.

That's an extremist viewpoint. It's unreasonable. It's a waste of time and money.

You have tons of tools at your disposal for finding bugs in your code. You have automated tests, manual tests, unit tests, integration tests, type systems, static analyzers, linters, code review, logging, analytics, and bug reports from production. Use a mixture. As you increase the sensitivity of any one tool, the cost of development increases.

For most projects, if you don't see bugs in production, you are not shipping soon enough. The cost of shipping late is, at some point, going to be larger than the cost of shipping bugs to production.

> In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.

My experience is that there are only a few explanations for why you would see a code base with 100% test coverage:

1. The code is so critical that high test coverage is justified (e.g. SQLite),

2. The code is so trivial that high test coverage is easy, or

3. The engineers in charge are just fucking nuts.

I'd like to share this recent quote from @tef_ebooks:

https://twitter.com/tef_ebooks/status/1434706902366228480

> trying to work out how to impress on people that i'm an incredibly masculine programmer, and although people have suggested comparing it to hunting animals for food, as far as i can tell the most 10x macho behaviour that programmers do is working unpaid overtime

> the best thing about being a macho programmer is that you can do it by saying one thing like "write 100% test coverage" or the opposite "i don't write tests" because nothing shouts status like extreme viewpoints in a land of tradeoffs

You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that. I hope you've enjoyed fighting that person, but that's not me. Have a nice day.

edit: I feel like I should remind you that I responded only to the first 2 paragraphs of that comment I'd quoted. I wasn't trying to shame you for editing your comment or anything, just trying to clarify what I was responding to.

> You seem to have assumed that I'm a 100% test coverage no matter the context or costs person, and ran with that.

I was talking about using type annotations to catch "simple typos in code paths that are not exercised in tests." Those are the exact words I used.

And you responded, first explaining how to catch those bugs with tests, or how the existence of these bugs is a signal that your tests should be better.

Like, I just don't get what you are trying to say. If you accept that your code doesn't have 100% test coverage, then you accept that there will be bugs in untested code paths that are not caught by your tests. But you said that you "take that as evidence that your coverage isn't sufficient." As far as I can tell, that means you're aiming for 100% test coverage or somewhere close.

Type inference is something that computers are better at doing given enough information.

So, let computers do it. Use human time for more important things, like things that require human intelligence.

If you don't have type safety you will end up writing 10x more unit tests anyways, while getting less certainty about your code.

Sounds nice, but my gripe is that type annotations do not provide type safety. For that, you need one of many type checkers, which aren't mutually compatible. How certain are you of your certainty?

Reply on news.ycombinator.com