I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
I have seen this happen over and over with PHP, Ruby, js, and now Python.
The best solution is to stop using a slow language for these types of applications. Personally I don't see a point to investing so much in these projects, since all it does is encourage developers to continue their bad behavior.
"Oh don't worry about it, they're working on a JIT if performance is ever an issue" -- lead dev deciding to write something that is expected to handle 10k transactions per second a few years later in Python.
If performance is ever going to be important just use a high performance language and be done with it. Then you don't have to spend years and millions reinventing the wheel like Facebook did with PHP.
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
It's easy to explain.
1. Most languages are designed for personal satisfaction of the author, not for commercial success. Perl, PHP, and Ruby were all just personal projects. Python was a language intended for education, then pivoted towards Perl's niche in the 90s.
2. The vast majority of languages that are designed will fail and be abandoned without anyone having ever heard of them.
3. Designing a pretty and elegant language is hard, but fun. You don't even need to implement it.
4. Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance). It's also hard to prove that your design actually yields good performance, which is hard and not fun. Furthermore, the only point of designing such a language is to hope to someday fully implement it, which is very hard and extremely not fun. And hoping to implement such a high-performance language in a cross-platform way is, for any single person, basically impossible.
The modern resurgence of high-performance languages like Rust is because, thanks to retargetable backends like LLVM, the idea of a hobbyist designing a new high-performance cross-platform language has gone from "basically impossible" to "unbelievably tedious though possible but also on some level your language has to basically pretend that it's still C". And also the consolidation of platforms for the past few decades now mean that there's fewer targets to support in the first place, and hence fewer C compilers than ever, so if you just want to transpile directly to C you can, though you'll still spend the rest of your life adding hacks to your compiler to work around bugs in every combination of platform/C compiler/C compiler version out there.
> Designing a pretty and elegant language is hard, but fun. You don't even need to implement it.
The parts that make Python slow make it easier to hack on, but they don't make it elegant in any meaningful sense.
> Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance).
Elegant languages are usually amenable to being efficiently implemented without the implementor having to do anything special. That's because elegant languages guide you towards using the simplest, least powerful features that are powerful enough to solve your problem. For example, in Standard ML, I don't use higher-order functions that much, not because they suck (they don't), but rather because first-order functions and functors (which can't be recursive) are powerful enough for most things I want to do.
On the other hand, in a language like Python, it can be very difficult to find features that solve exactly your problem and nothing more, so often you have to reach for super-powerful hammers (operator overloading, metaprogramming, etc.). These hammers are almost invariably more general than the intrinsic demands of your problem, but, since the language designer can't provide an implementation that only works for your use cases, you must pay the price of the unnecessary generality of the feature.
Every single company that has invested heavily in JITs for PHP, Ruby, Python etc. has done so because they have vast codebases, often millions of lines, written in those languages and rewriting their codebase is infeasible: getting a 20% performance increase for everything from a dozen man-years is vastly cheaper than trying to optimize their entire codebase similarly yet alone rewrite large parts of the application in another language.
Why start writing something in one of those languages? They have high-quality frameworks that make it quite easy to ship early and ship fast: the vast majority of web-based startups fail, or at most stagnate with at most tens of thousands of users, and for them the performance of the common interpreters is fine. If we want to see a phase shift away from them, we need frameworks that allow quick prototyping written in languages which are more easily optimised (and, honestly, JavaScript really isn't bad in terms of writing a JITing compiler).
The point I was trying to make is that the idea that a JIT or compiled version will come along in a few years drives people to use slow languages for high performance projects in the first place. This creates a cycle where the language is used in a way that a JIT coming along is a self-fulfilling prophesy.
The irony is that the companies investing the most money into eventual JIT/compilation are the same ones that wrote code believing it would "come around" one day.
The only way to stop the madness is to avoid using these languages for high performance code in the first place.
Having used many fast/slow languages over the years I'll say I don't really notice any increase in productivity one way or another, and no difference in the richness of the library ecosystem.
Are there any studies that show more dynamic languages are more productive? Usually the argument is made that the more abstracted the language is from hardware the better it is to work in, but I don't notice a productivity difference in C#/Java vs Python/perl
I'm not sure people have this idea that a JIT or AOT compiled version will come along; certainly ten years ago nobody really had that impression, has the rise of the JS VMs really changed this so much?
To take FB as an example: AFAIK, it was written in PHP because Zuckerberg knew PHP. There was no expectation it would "come around" and it continued to be in PHP because bills had to be paid and rewriting everything would stop new features from being launched and hopefully reach profitability.
If you're a small startup your first goal is almost always to hit profitability, and then your goal is almost always to maintain that. As a result, language choices are frequently made by what founders know rather than any technical merit.
Instead of rewriting all their codebase at once, if a company choose to simply first target the performance-critical aspects of their software stack, and slowly replaced old code with new, then it doesn't sound so financially irrational. Isn't that what's happening with Dropbox?
1. There exist massive existing codebases in these languages, and simply the cost of a rewrite, retraining all of the engineers, and building new tooling is more expensive than making these languages run fast. In the case of V8, the cost for Google was to convince the entire web not to use V8.
2. These languages are in fact, the best tool for the job. The semantics of the language are the best tool for the job, and writing in another language is going to slow down the team (in the long run) more than making the language faster.
3. Opportunity cost is key when starting. I've seen this first hand with C* vs. Riak, and K8s vs. Mesos -- sometimes, choosing the language that lets you run faster, even at some sacrifice will put you ahead early in the game. You can figure out later how to replace all your duct tape, while dancing on the corpses of the competition.
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
Because CPUs are so fast there is usually no need to worry about performance and clarity of code and convenience is more important.
Also you have to remember that Python "grew up" from early 90s through early 2000s. That when most CPUs were not multicore and CPU speeds were doubling every year almost. You could write something in Python, and in a few years, it would speed up just by going to a better hardware.
You had the alternative of "here is 2000 of lines of C++ with templates, pointers, references, inheritance, constructors of various types, kind of meh standard library" vs "here is 500 lines of Python that you can read, understand and fix in much less time". Python was slower but that's ok. Getting faster machines was easier and cheaper than than work-hours poring over bugs and segfauls in the C++ code.
The one reason we talk about Python and speed is because it was widely adopted and in some cases companies wanted more "speed" from it. Then multi-CPU machines become commodity and there was more talk about the GIL and such.
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
Usually, it's many orders of magnitude less than billions of hours, and the reason is that raw machine language is fast, all higher level languages are designed around ideas of desirable abstractions.
There's a similar comment from the earlier thread [1]:
"I urge designers of future dynamic languages to study Lua and LuaJIT if you want your language to not inhibit JIT development."
and [2]:
"Agreed. Also Smalltalk's memory model was a lot easier to optimize than languages like Python and Ruby. (Java inherited some of that.) Not having syntactic sugar makes optimization easier.
In addition, language designers need to make parser tools easy to make and robust."
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
It's a tradeoff - what are you trying to accomplish, and what would you rather spend your time doing?
More flexible languages are often also more expressive and have better tooling (e.g. for a CRUD app it's hard to find something nicer than Django / Rails), but tend to be slower. The other end of the spectrum is more performance-oriented languages where everything is way more verbose, and has low expressiveness, there's a lot of boilerplate, writing any code that does something relatively simple is more onerous. So depending on what phase of development you're in and what you're doing, the "obvious" choice can be different. And as companies grow and mature, those goals also shift.
Granted, that gap is closing with compiled / systems languages getting more and more expressive (Rust, Nim, Go?, C++11/17?), but it's also closing with scripting languages getting faster (very blanket statements here).
The fact that python, and some Java, but decidedly not C++, is the de-facto standard tool for the scientist these days should give you pause. Machine learning, gpu computing stuff, large scale data processing with spark - you can all do it with python. Sure, it's all C and Fortran and Java behind the scenes, but who cares? No one wants to bother with that if they can avoid it. They just need to get their job done.
Another example, more towards your requests per second example, is Japronto (https://medium.freecodecamp.com/million-requests-per-second-...) - turns out if you take time to optimize the event handling and the http parsing, suddenly you're back in the ballpark of compiled languages. Sure, other bits of code are going to then become the bottleneck, but those can be made faster too.
The "high level developer interface + compiled and optimized internals" combo is just very hard to beat, because it's always going to be good enough where it counts.
Also, performance improvements for a language or specific libraries is something that can be done as a centralized effort by experienced and knowledgeable people on that specific subject. Chances are most people aren't going to write a matrix multiplication operation that'll beat BLAS stuff, so why bother unless you have an extremely good reason? This is much more efficient and happens "for free" from the point of view of the end-user developers (also computers are getting cheaper and faster, also for free). So why bother?
I think Facebook / HHVM / PHP was sort of the boundary of how far this can go, but I think it's a testament to it rather than against it. Granted, not every company is Facebook, but like I said, the gap is closing too. But I think more dynamic languages are always going to become "fast enough" faster than more static languages becoming more expressive and nimble, and will often beat the latter in available tooling (I remember "package management" and build tools in C++, ugh.)
I have seen this happen over and over with PHP, Ruby, js, and now Python.
The best solution is to stop using a slow language for these types of applications. Personally I don't see a point to investing so much in these projects, since all it does is encourage developers to continue their bad behavior.
"Oh don't worry about it, they're working on a JIT if performance is ever an issue" -- lead dev deciding to write something that is expected to handle 10k transactions per second a few years later in Python.
If performance is ever going to be important just use a high performance language and be done with it. Then you don't have to spend years and millions reinventing the wheel like Facebook did with PHP.