I'm concerned about using Python

I'm concerned about using Python

xkcd Python


Python is slow

Significant whitespace? Seriously?

"Oddly enough, Python's use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked." -- Eric Raymond

Python doesn't really have threads

Python can't take advantage of multiple cores

Python is big

Python uses too much memory

Python is hard to deploy as installed software

Python has errors at runtime that other languages detect at compile time

Python code reveals its implementation

Python isn't very popular, it is hard to find engineers

There isn't much user-installed software using Python

I want to debug the full stack, even if there's native code

I don't feel like a real programmer unless I'm writing native code

xkcd Real Programmers


Every programming language has its strengths and weaknesses. You need to consider the characteristics of the alternatives, not just pretend like there is a magic language that has no downsides. For example:


xkcd Compiling

I often think of C++ as my own personal Pit of Despair Programming Language. Unmanaged C++ makes it so easy to fall into traps. Think buffer overruns, memory leaks, double frees, mismatch between allocator and deallocator, using freed memory, umpteen dozen ways to trash the stack or heap – and those are just some of the memory issues. There are lots more "gotchas" in C++. C++ often throws you into the Pit of Despair and you have to climb your way up the Hill of Quality. (Not to be confused with scaling the Cliffs of Insanity. That's different.)

-- Eric Lippert

Why Python is awesome

Some of the above from Raymond Hettinger's PyCon 2013 talk.

When you're writing working code early as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!

This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process.

--Eric Raymond

What sucks about Python?

Other Resources

Execution speed

The argument is that the development speed benefits greatly outweigh the additional processing time + server costs, especially when the company is small. There are plenty of startups that will have great cost optimization from the beginning, but if they get out-maneuvered by a faster-moving competitor, it doesn't matter: the parameters of success don't matter if the magnitude is zero.

So we couldn't have afforded to not start with Python, I would say. At this point, we potentially can't afford to switch away from Python given how much we already have written in it. That said, the costs are being felt; there are people experimenting with using other languages (Go, typically) for new projects, and there are efforts like Pyston to try to bring the cost of Python down.

Also, I don't think t's right to say "Dropbox is IO bound". Any particular request might be IO-bound, but if that's the case you simply turn up the concurrency until the server as a whole is at the target utilization in some metric. For some services that will end up being network bandwidth or disk IO, but for many it's CPU. So at any given time, Dropbox does in fact have a large number of cores running Python code.

--Kevin Modzelewski, Dropbox Cofounder

Protecting code from reverse engineering

"Is there a good way to handle this problem?" No. Nothing can be protected against reverse engineering. Even the firmware on DVD machines has been reverse engineered and AACS Encryption key exposed. And that's in spite of the DMCA making that a criminal offense. Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods.

  1. Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component.
  2. Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive.
  3. Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering.
  4. Offer customization at rates so attractive that they'd rather pay you do build and support the enhancements.
  5. Use a license key which expires. This is cruel, and will give you a bad reputation, but it certainly makes your software stop working.
  6. Offer it as a web service. SaaS involves no downloads to customers.

--S.Lott, StackOverflow answer

This doesn't really address competitors learning something from your code, though.