Replacing Python
I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either.<p>[1]: <a href="http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/" rel="nofollow">http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/</a><p>ATS makes everything more difficult than it's worth except for some very specific use cases. Unlike some of the other languages like Haskell and OCaml, I don't think this is just because it's different; rather, it's because ATS is simply so much more demanding. It gives you extremely solid static guarantees and high performance, but it's a tool that really sacrifices expressiveness and programmability to get there. Haskell and OCaml may be difficult to <i>learn</i>, but ATS is actually difficult to <i>use</i>--a very different concept.<p>Go, on the other hand, is neither difficult to learn nor difficult to use. But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings. If you're willing to put in a little bit of effort to learn something new, there are a whole bunch of options which are simply better. And you <i>should</i> be willing to put in the effort: your programming language is your single most important tool; it affects not only how you write your code and how you maintain it but even how you <i>think</i>. So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know!<p>Rust is awesome, but it's simply not ready yet. This is widely acknowledged by everyone in the project, and is part of their policy of open development. Once it <i>is</i> ready, it will be a very good choice for certain domains.