Frameworks Round 6

I'd say a vanilla Python application without ORM would perform similar to a flask app without ORM. According to http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

flask (on Gunicorn): 6,138

flask (on PyPy): 8,167

Django + ORM : 4,026

cpoll-cppsp : 114,711

So while a light weight Python app without ORM might be 50% faster than a full-blown Django app, it's still almost 20 times slower than a C++ app.

That shouldn't be surprising, by all accounts Python is at least an order of magnitude slower than C++.

You could speed up your Python program by running PyPy. According to the benchmark that gives it a 30% speed boost, which is in line with my experience. Another way is to deploy on uWSGI or Meinheld instead of Gunicorn.

No matter what you do, Python will not be close to the speed of C++. But what really matters is: is it fast enough for your need?

> Testing is, as far as I can tell, the reason that these problems don't come up.

Testing is a cost. It is more code to write, more code to maintain. It gives no guarantees about correctness, even of the exact feature under test.

Consider the 10 lines starting from https://github.com/yairchu/red-black-tree/blob/master/RedBla...

They guarantee the correctness of the invariants of the Red Black Tree, and they easily replace hundreds of lines of test code which give no guarantee.

We might still need to write tests, but a lot fewer of them. Also, those we write will give us far more "bang for buck" because we can use QuickCheck property testing.

> Note that both of these languages allow shared mutable data, both allow null pointers.

Scala shuns null - and only has it for Java interop. All Scala developers I've discussed this with program as if null did not exist, and never use it to signify lack of a value.

> I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler.

When "arguing with a compiler", you're really being faced with bugs now rather than later, when the code is no longer in your head - or worse, in production. If the type checker rejects your program, it is almost certainly broken, and it is better to "argue with a compiler" than to just compile and get a runtime error later.

Availability of engineers is a good point, though as a Haskeller, I know both companies seeking Haskell employees and Haskellers seeking employment (preferably in Haskell).

Consider the flip-side of the engineers availability is the "Python paradox".

It doesn't appear that there's been any real speedup on the Ruby on Rails results for the last several rounds, so... why is that? Does nobody in the community care about speed? Is there no way to speed up Rails? Is it not clear where the bottlenecks are? Are the profiling tools not good enough? I'd sincerely like to know if someone has taken on the task and just been frustrated, or if no one has actually tried.

You could use JRuby and Rails if you need the JVM.

Groovy's OK for wraparounds testing and/or running Java classes, what it was originally intended for, bringing closures and terser list/map syntax (altho JRuby et al have those too). It's all rather slooooow though. Grails uses Groovy's MOP which was added later, but I don't use them much. I toyed with Groovy's interceptors and categories when they were added, even wrote notes on them, but they broke in the upgrade from 1.5 to 1.6. There's a lot of such cruft in Groovy which just lapses from version to version through lack of use and support. They brought in AST transforms to get programmers to extend Groovy's functionality, but when they do, the Groovy managers wil swipe the code and pass it off as their own in the next version of Groovy (e.g. Groovy++ written by Alex Tkachman was cloned as the static compilation in Groovy 2.0 and the static traits in the upcoming Groovy 2.2).

tldr... Use grOOvy for quickies handling Java classes, and for Grails where it's required, but look at a serious programming language for anything larger.

> Testing is a cost. It is more code to write, more code to maintain.

I'm not saying you write tests to protect against NPEs. I'm saying that you write tests to ensure correctness of your code, and as a side-effect NPEs are flushed out of your code. This is my theory explaining why NPEs are not a timesink for me.

> They guarantee the correctness of the invariants of the Red Black Tree, and they easily replace hundreds of lines of test code which give no guarantee.

Code with mathematical invariants seem like such a niche area, though. The average type of test that I write is "ensure your service calls service X first checking for values in a cache; ensure that it can handle cache unavailability, service X unavailability, cache timeout, service X timeout". Maybe you could figure out a way to encode that in a typesystem, but I'd wager that it wouldn't be as readable as the equivalent written as a test.

> Scala shuns null - and only has it for Java interop. All Scala developers I've discussed this with program as if null did not exist, and never use it to signify lack of a value.

That's exactly right. Languages with nulls, and mutable shared state are perfectly reasonable to use if programmers do the right thing by convention.

> When "arguing with a compiler"...

I misspoke. I was thinking of the learning process, not the process of writing code.

Although my current focus is backend systems, I have worked across the spectrum in the past. I've worked (not including languages I dabble at home) in JS (for browser UIs), Java (for Android UIs and servers), Obj-C (for iOS UIs), Python (for servers and scripts), Scala (for servers), Ruby (for servers), and C++ (for servers). These languages represent a wide spectrum on the dynamic to static spectrum. I don't find myself writing much safer code when I go from JS to C++. The same for a shift from Ruby to Scala. The same for Python to Java. These shifts are relatively large on the type-system spectrum, as they go from dynamically typed languages to statically typed ones. You claim that a significantly smaller shift, removing nullability from a language would be a big deal for reliability. That doesn't seem likely to me.