All the things I hate about Python

Given that it was about 150 lines of code and I did a fairly straightforward rewrite in a performant language in about a day, and the performance was acceptable, yes.

It's worth noting that autotools for building C/C++ was so broken that ESR declared that SCONS (written in python) was a much better way to build C/C++ code.

I've used Java/C/C++/Ada/Perl/Go and most recently Python all professionally in one aspect or another. I settled on Python.

So being a professional Python/Django coder, I was aware of all these issues. And yet, those issues do not seem to stop the Python train from moving forward.

A couple of issues to note in his article: Everything he says is true, but the conclusions are mostly false.

1. Optimizing databases and data access are the number one scalability issue. It's the hardest thing going from a monolith to a microservice architecture. Goroutines, threads, etc. don't solve that for you.

2. Threads are terrible in any language (except Erlang maybe), and reliable code cannot be used with primitive thread constructs. Goroutines are good enough, sure. Also python asyncio. But not threads. I've seen production systems that no one could debug, because 3000 threads ran amok, thread deadlocks, race conditions, etc. And you can't unit test threaded code effectively either.

3. All software has multiple build systems. C/C++ and autotools, CMake, Scons, Waf. Java and Ant or Maven or Gradle or whatever. Go is sane for the most part, until you get to dependency management -- goglide, govendor, etc.

4. Strongly typed, statically typed systems (Java, C++) usually aren't. Usually people rely upon that as a crutch to think they don't have to worry about types, until they see NullPointerExceptions (java) or segfault (C/C++) in production.

5. Python code is only as reliable as the person who wrote it. But that's true of C/Java/C++ etc. People have to understand where the pitfalls of a language are, and that's usually documented in coding standards or style guides.

You mean:

  def myfunc():
    try: 
      while x in someiterator(): 
        a = x
        dosomethingwith(a)
    except:
      # Does a exist here or not?

If someiterator() raises then a won't exist in the function block. Otherwise it will.

I have exactly the same reaction to C#, C, Forth, Pascal, Prolog, etc: regardless of the typing strength or compiler nitpickiness there will be scenarios where stuff doesn’t go as planned because I didn’t understand the problem domain sufficiently, and these errors serve to enhance my understanding of the same.

Regardless of language, x -> a + 1 is not going to work if a never has a value. In many cases handling “a doesn’t have a value” is the wrong way to address the problem, because the problem should be solved as “figure out why the data collection didn’t work, and propose a strategy for handling our dataset when either a value is missing or is provably wrong.”

As an example one might assume that a video feed has exactly as many frames per second as it says on the tin (eg: 24fps will have exactly 24 frames for each second of video) but in reality there will be missing frames due to data corruption, or even a mismatch in clock speeds meaning that over 100 seconds you have 2398 frames instead of 2400. How do you handle the missing two frames? The problem is there are no frames missing, it’s just that they were never there to start with, and frame 1237 of another source has no direct equivalent in the slightly-faster stream. You might alter the clock for processing, duplicate one or two frames, use interpolated frames, or otherwise process the various sources so that you get a consistent synthesised data stream with which to do further processing.

Strong typing doesn’t help solve real problems.