Except in the end, the author switches to OCaml[1]. So Python might be good enough, but he certainly found OCaml better.

And since when are we willing to settle for good enough?

[1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/

(In fact, the author writes that he's basically willing to move to OCaml in the conclusion of this post.)

"Good enough" the way I'm using it is nothing to be ashamed of. It is very difficult to find computing systems that are "good enough."

Here are some of the motivating factors identified by the author at the outset of the search for a better language:

- Canonical’s Colin Watson is worried about Python’s performance on mobile phones.

- Marco Jez and Dave Abrahams proposed a C++ version.

- Bastian Eicher would like a .NET version (though IronPython might work here).

It doesn't seem like OCaml effectively addresses the above very well. On the other hand, here are some items the author liked about Python which may now be lost:

- Widely known and easy to learn.

- A large standard library.

- You only need to ship source code (interpreted).

- Can run inside a Java or .NET VM (using Jython/IronPython).

- All current 0install contributors know it.

- The current code is all Python and is well-tested.

Of course the last item is the most alarming: see http://www.joelonsoftware.com/articles/fog0000000069.html (2000), Brooks' Mythical Man Month (1975) for the Second System Effect, etc.

Although F# isn't OCaml it is fairly similar, and compatible if you skip certain features of each: http://stackoverflow.com/questions/179492/f-changes-to-ocaml

> since when are we willing to settle for good enough?

Ever since we decided to get shit done, ship, finish our weekend project, etc. Ever since we first read "premature optimization is the root of all evil" and understood it as wide, abstract truism.

I seriously doubt OCaml's benefits over Python are so great that they overweigh not being able to hire someone proficient in it.

In practice, people have found that hiring good programmers is actually easier with certain more obscure languages. Paul Graham, amusingly enough, called this the "Python paradox" because, back in 2004, Python was one of the obscure choices! Oh how things change.

This certainly holds for OCaml as well. The main OCaml company I'm familiar with is Jane Street, and they certainly have no issues finding OCaml programmers. More importantly, many of their programmers come in with no OCaml experience or even no functional programming experience, and yet they have no trouble getting up to speed. In fact, these days they even teach their traders--often complete non-programmers--OCaml. And it works. I don't think I'd ever want to hire somebody incapable of learning a language like OCaml in a reasonable time frame.

So yeah, this is not an issue in the least. If anything, it seems to work out more favorably for the companies using OCaml, Haskel and the like!

I'm pretty sure that at Jane Street you get to solve engaging problems and get paid 250K+. OCaml or not, they're not going to have problems with hiring.

The other thing is his only complaint (slowness) isn't really a problem. If you have a critical hot spot in your server code, extract it, implement it in C / C++, and use ctypes to call it.

Having recently started doing python full-time, I would say that by far the biggest problem with python is its propensity to explode in your face. Code written in python seems so fragile; except for the most blatant bugs like syntax errors or too few arguments, nothing gets caught. You end up having to write tons of unit tests, which often expose bugs that would be trivially caught with any kind of typing. Performance is great, but code reliability is much more important. With python you get neither - just rapid development (slowed down by having to write a ton of tests) and expressiveness (which is excellent).

Don't let its ease of use fool you, there are a lot of ways to shoot your foot off in Python. Typically, it's kind of like pulling the trigger (make the mistakes), only to see your foot get blown off a few months/years down the road. I find that your luck with larger Python projects is largely determined by two things:

* Experience with Python, and general experience in duck typed environments.

* Discipline. Not just your own, but anyone else working on your project.

There are certain mistakes that will make your life miserable down the road. These could be bad organizational conventions, inconsistent exception raising/handling policies, lacking a strategy for documentation, etc. If you make mistakes like this, you probably won't get bitten by it until later.

Writing good Python can be harder than writing good <X Language with more rigidity>. With experience and time, this gets a lot easier.

This was exactly my sentiment when I started doing Ruby full-time.

I appreciate all the niceties that dynamic-typing language like Ruby provides. But I am not sure the trade-offs are enough (all you already described).

CFFI is the latest trendy way to call C, compatible with PyPy ;)

"slowness" is not the problem here - it's "slow program startup". If your process only lasts for tens of milliseconds, you're not going to make it any faster by embedding C code because 99% of time is still going to be spent initializing the python VM.

So, effectively, Python is not enough - you and your team have to be experts in C/C++ too?

If your team can't write a few hundred lines of critical section code in another language, or at least pick it up in a week - especially when the syntaxes are very similar (this isn't going from closure to java here) - you have bigger issues with your team than their language choice.

Yep, no single language except C(/C++) is enough by itself (potential exception here is Java, but even there it's still useful).

C has become the lingua franca of computing. You can call everything (except Go) from C and you can call C from everything. So you want to actually reuse standard libraries, you will want to know C. And if you're a good C hacker you'll know C++. I'm not saying you'll necessarily use it, but you'll know it.

The vast majority of python programmers do not know how to call C/C++ code and are therefore limited to pure python libraries exclusively. They usually use writing to files and os.system() as an alternative. Needless to say, the performance of this approach can be questioned.