My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and build up some CRUD pages in no time flat, and then once you've got enough traffic to care, move parts of the application to more performant platforms (Go/JVM usually) as necessary.
That's a serious question: I find it's often hard to tell what the bottleneck might be in these applications.
A python application can be anywhere from 10x to 50x slower than a native application. It also probably consumes at least 5x more memory.
Writing the same app in a compiled language is not even an optimization. It's just baseline work to ensure the code is not super slow.
Like, if you know you will sort a list of 10 items, choosing quicksort from the stdlib instead of bubble sort is not even an optimization. It's just common sense.
For concurrency (number of requests handled at once) instead of speed (end-to-end time of of a single request)
Why waste 10x more memory?
That sort of question is totally missing the point of why people use these languages, yeah? Languages in the web world don't tend to be chosen based on memory requirements (or speed as this suggests). Are there cases where you want to think about that? Sure.
People have plenty of reasons they'd want to use Python over Go, and vice versa.
"and vice versa" < Sorry, but no. There's no equivalency here.
The only reason I would ever use python is for small scripts that I only run on my machine and don't need to deploy anywhere.
Maybe 10 years ago Python was an attractive language because Java sucked and C# only runs on windows and there weren't many other good choices.
Now there are many expressive languages that are also statically typed and fast. D, Swift, Kotlin, etc.
Java is the only static language that features roughly equivalent levels of support ecosystem wide.
Good luck getting more than 100 calls per second out of the slow languages
Anyway, if you're locally looping for hundreds/thousands of queries to the database, instead of writing one query or calling a stored procedure, you're probably doing things wrong.
Java/Go with pretty much any database can manage about 50,000 individual queries+REST calls a second.
https://www.techempower.com/benchmarks/#section=data-r14&hw=... has some interesting benchmarks, apparently we should be using Dart or C++. Go does slightly better than JS but not a lot. Some newer Python frameworks aren't on there yet. None of them reach near 50k, but I don't know the details of the benchmark and they aren't all using the same DB. Certainly you can get crazy numbers depending on what you're testing. e.g. https://github.com/squeaky-pl/japronto gets one million requests per second through async and pipelining but those requests aren't doing much.
And you can make Python or even PHP fast if you try hard enough.
My argument is that the engineer overhead for Go and new breeds of Java frameworks are small enough that it makes no sense to use anything else if you're planning on scaling for real.
If you start with something else the cost of making a slow language fast and the multiples of extra machines you need costs far more than just using the faster language to start with
For the benchmark you posted, take a good look at the "realistic" vs "stripped" implementations and whether the test used an ORM. You'll quickly see that the realistic test applications with any kind of ORM are exclusively C#, Java, Go, and C++
Cost difference is another topic. While servers can be cheaper than developers, saving 90% of server cost can definitely clear some budget for enhancements.
You answered your own question. Why bother with those languages when the language isn't the bottleneck? In those cases, what language one uses becomes an entirely subjective matter.
> All the big companies are [...]
For every large company using Java, Go, Rust, C, etc. There's another one (hell, probably the same one) also using Python, Ruby, PHP or JS.
Arguments about what language is better are pretty flamey but it's hard to argue that performance is not an advantage of Go/Java
And I never even remotely argued such a thing so I'm confused as to why you are saying this in reply to me.
My current company has 15 Java & React engineers where 2 or 3 Rails would suffice. Load tops out at maybe a dozen requests/second. Feature development is super-slow. System complexity is off the charts.
That probably has little to do with language/stack and everything to do with constantly changing requirements/system growth.
To your required engineers comment, Spring Boot + jOOQ is easily one of the most productive backend stacks I've ever used. A single engineer could easily build a large API leveraging the stack.
If you're only using them for a REST API they offer similar features. Spring Boot supports loads of other stuff you probably don't need for something API driven
Because mature companies in competitive markets live or die by operational cost effectiveness.
Growth-phase companies or one with moats live or die by other means; if they are around long enough and are targeting a valuable enough market, they'll eventually probably be a mature firm in a competitive market, but a good way not to get there is to focus on the needs that such a firm would have rather than the needs the firm they actually are now actually has.
Please cite “all the big companies.” Also exclusively? No seriously, that is a bold claim. Google isn’t one of them because most of those hotepots are still written in C++. I don’t know how you can claim this. Based on some occaion company blog posts, changing just one or two endpoints out of say 100?
What about Rust? I also know companies rewrote some hotspots in Rust too.
Easy to find out just by looking at their open job positions.
Microsoft is an exception because they built C# which is basically a more modern but less popular variant of Java. There was even a project for a long time that let you use Java code in C# projects by converting the bytecode, they're that similar.
The notable exception is Facebook. They were stuck in PHP hell for so long that they redesigned the language to make it work.
The new generation of Python web frameworks is pretty fast (check out Sanic[0][1] for example), Python has a huge growing ecosystem, you get rapid time to marked and if you find some part of your application to be the bottleneck, you can replace it with C/Rust, which you probably don't need, because your company won't ever scale as far.
[0] https://github.com/channelcat/sanic
[1] https://magic.io/blog/uvloop-blazing-fast-python-networking/
For large web apps it's still pretty much a nonstarter unless you want to not be able to take full advantage of libraries like sqlalchemy.
Nodejs had a great advantage by starting with asyncio from the beginning.
M:N threading would have been a much better fit, though that's out of question given the GIL.
Reddit has some scattered Engineering blogs and my insight into youtube comes from a previous HN article by the author of GrumPy (who works on youtube at Google) in case you're curious.
Higher level languages might offer lower raw performance and more bugs. But they offer more features per dollar.
That isn't really specific to programming. You might also wonder why McDonalds is popular, even though their food is...meh.
For me as a Python/Rails/C++ dev Java has a reputation of being too large, too complex and otherwise.. unwieldy.
Hearing things like "To test a bug I had to start 6 services on my computer and then I ran out of memory (computer had 16GB)" doesn't encourage me to try to do web dev in Java.
Wicket is a true OO approach to GUI which is quite different from the page-template style of Rails/Django/..., but I find it makes for much more compositional style, with lots of small reusable components that are just compositions of a few smaller components. And while not being able to monkeypatch everything can chafe initially, when you come to upgrade to a newer version of the framework you'll really appreciate the safety a compiled/typechecked language can offer.
These days, i write most of my applications using the JDK's built-in web server. They're intended for internal use by single-digit numbers of people, and it works fine. It doesn't give you anything except the ability to serve HTTP, though.
Before that, i was writing apps using Spring Boot, which is a framework covering pretty much everything. It's easy to get started with, and requires no XML, but gets complicated fast as soon as you want to do anything even slightly unusual.
A more production-grade alternative to the built-in web server is Undertow, which again just does HTTP, but is fast and scalable, and fairly simple:
http://undertow.io/undertow-docs/undertow-docs-1.4.0/index.h...
Some people swear by Dropwizard as a more lightweight but still framework-sized alternative to Spring:
http://www.dropwizard.io/1.2.0/docs/getting-started.html
The tutorial there uses a smidgen of XML for Maven, but that's all. You can use Gradle instead of Maven, which lets you avoid XML and is generally much better, but you'd have to work that out yourself, or find someone else who has, perhaps this person:
http://automationrhapsody.com/build-dropwizard-project-gradl...
There's also Java EE, the 'offical' framework for Java. It's actually not bad to program with, but you need an application server to run your apps, and although those are miracles of engineering, the user experience is still stuck in the dark ages.
> Hearing things like "To test a bug I had to start 6 services on my computer and then I ran out of memory (computer had 16GB)" doesn't encourage me to try to do web dev in Java.
If you need to start six services, you must be doing some kind of microservice / SOA thing, and if you need >2 GB for each service, you must be using some very heavy-weight application server. Neither of those things are smart, and in combination, they're deadly!
One especially useful feature in Pyramid (and some other Python frameworks, Flask, Django etc) is the debug console, when I get an exception somewhere, then on the 500 page I can see the call stack and get a shell at each line in the calls stack, print the variables, view the last n requests, see the request variables and so on.
Really though, you should invest some time in learning typescript and react. These days most apps are just API calls on the back end and you deal with templating, forms, and other bs in the frontend.
Because most apps are built this way now, you won't find any "modern" Java frameworks that support what you want, and you're pretty much gonna be stuck with the older clunkier stuff.
The learning curve for new SPA frontend stuff is high but I've found it much more productive now that I'm into it. With HTML generated on the server it's too damn hard to get pages to do what you want
Spring (with Spring Boot) has approachable tutorials [1] on how to get started but will get intimidating pretty fast.
I highly recommend using Kotlin instead of Java when trying out the JVM, though.
[0] http://sparkjava.com/ [1] https://spring.io/guides/gs/rest-service/
It's important to remember that Java has been around for 20-30 years and it certainly has not stood still. Many of the complaints people have are from Java of 10+ years ago.
Exactly. I spent about 5 years away from Java after J2EE made me swear it off. I learned a bunch of other languages and frameworks and recently went back. Java is awesome now. Unlike 5 years ago is relatively easy to avoid all the clunky old crap if you want to.
This leads to a lot of "first languages" being the latter and a perpetual glut of recent grads that know nothing else so will do those jobs for less
First: Because squeezing every last nanosecond's worth of performance out of your web app is actually an extremely rare problem to have. And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly, but I'd bet a lot of money that you don't do that.
The typical web application -- I'd be willing to bet over 99.999% of all deployed production web applications serving requests today -- has a bottleneck at the database and the network that dwarfs any overhead from language performance.
I remember a bit over ten years ago when there was debate in the Python web world about which templating engine to use to generate HTML. And people argued endlessly over microbenchmarks of them, to figure out which was fastest, but I remember one blog post which showed a pie chart of time spent in the average request/response cycle. Nearly all of it was accessing the database, and template rendering was a tiny, tiny sliver, so the author humorously labeled it "obviously this is the part we need to focus all our optimization work on". Language choice is similar.
Second: Because what else your company does matters. Where I work, web applications are how we expose data and interfaces to that data. But there's a gigantic stack behind that, of data intake, data parsing, data processing, analytics, the whole nine yards. It's all in Python, because Python has hands-down the strongest ecosystem of any popular programming language for that stuff. So the web applications which serve as the interfaces to the data are also written in Python; it means we have one language to worry about, one language to work in, one language every software engineer knows. I've been pulled onto projects doing things that didn't involve web applications at all, and I've been able to be productive because those projects were still in Python, and I could read code and get up to speed on what was happening, and take care of mundane things for a more domain-experienced person whose domain expertise was then free to apply to things I couldn't do.
Third: Because programmer convenience really and truly does matter. When I first started doing this nearly twenty years ago, people posted comments like yours, incredulous at the idea that someone would use PHP or Perl given their performance characteristics compared to Java (or C -- plenty of web apps used to be written in C!). But even then we knew: servers are cheaper than people. The average salary of a quality software engineer (or "web developer" as we were known then) would buy you a lot of compute time, either on your own (in-house or colo'd) metal, or nowadays on someone else's cloud.
So you choose based on convenience to humans. PHP, for all its faults, was an incredibly convenient language to write web apps in, and compared to the usual CGI model that preceded it, was a breath of fresh air when it took off. Today, frameworks written in Python, Ruby, PHP, etc. are similarly in a good position compared to more heavyweight things like the Java world (which for better or worse is still suffering the lingering effects of its mid-2000s "enterprise" reputation), or even Go (which is still young and still seems to come up short, both language- and ecosystem-wise, on some of the things actual working web programmers want. In particular, programmer-friendly ORMs in statically-typed language really really really want generics or a good equivalent, and Go's historic attitude toward that has not been great.
The performance gain from Python/Ruby to Java/Go is an order of magnitude larger than the performance gain from Java/Go to assembly. The productivity loss from Python/Ruby to Java/Go is an order of magnitude smaller than the productivity loss from Java/Go to assembly.
Therefore, going from Python/Ruby to Java/Go might be a good idea for web apps, but going from Java/Go to assembly is virtually never a good idea for web apps.
Or a bottleneck in a process which can be optimised into better data structures. Changing the language can only lower your constant cost and the scale - it will not change the complexity on its own, so it should be really the last resort.
I have seen MS SQL server handle over 10k database queries per second on a regular machine in a real, huge application (over a million lines). Can Python handle 10k queries per second? Definitely not. In Java or go that load could probably be handled by a single AWS box that costs $10 a month.
I have never seen a database maxed out that wasn't stuck because of table locks. I've seen applications like WordPress die at 10, requests a second
Secondly, the majority of websites that make up the Internet (and Intranets) are not serving 10k/second. They're serving a 100th of that.
Third, because your database can handle 10k queries, and your database can aggregate and manipulate data, and it's optimised to do this -- it might be a good idea to perform these functions at the DB-level, as opposed to the web application.
Finally, as stated previously, for most businesses, it's easier to buy more beefy servers, or get a more experienced PHP dev (that understands how to optimise code) than it is to find a Go programmer.
Common Lisp, Scheme, JavaScript, ML variants come to mind.
Having been part of a startup that used a dynamic language without a world class JIT/AOT compiler (Tcl) back in the first .COM wave, teached me to never do it again.
A language is not just about overhead, it's also about capability. For example, your database is slow, and your web page needs to render by executing 20 queries. Will your programming language allow you to parallelize those queries? While your database/network may have high latency, they can still have good throughput.
This particular example is very real, and is incidentally relevant to the original post, since Python and Go implementations have different capabilities.
Erlang is much slower in raw performance than both go and jvm: https://benchmarksgame.alioth.debian.org/u64q/erlang.html
Async approache similar to Erlang was reproduced for Java and Go already: https://akka.io
It'd be great if there were better benchmarks for common use cases of various languages. Spring on the Java side tends to be heavy on reflection usage, which is orders of magnitude slower than JIT'ed JVM methods. Benchmarks like the benchmark game don't capture this. Still despite that the Erlang VM performs very well on the benchmarks game compared to other dynamic/scripting languages. Often it's easily 5-10 times faster than Python or Ruby. Given the parents comment, I'd argue many programmers who enjoy developing with dynamic languages can do so with Elixir with comparable performance to Go/Java for high concurrency web applications.
Somebody should make those.
(People may have different ideas about which use cases are common).
As you can see, erlang is far from the top there.
However it gets more interesting if you look at the Latency tab. There Phoenix comes in with an average of 7.9 ms. In comparison Gin averages 5.8 ms, Spring at 12.1 ms, Flask Py3 at 23.1 or Py2 at 14.7 ms.
Where it's really interesting is looking at the max latency. Presuming this indicates roughly how 99th and 95th percentiles measurements would compare. In this category Phoenix comes in second with a max of 22.0 ms, behind only lib-mongodb at 20.8 ms. The lib-Mongolia is one of the fastest frameworks by raw req/s.
Appreciate the link to the benchmarks! Much more interesting, especially if you're concerned about max latency (and likely 99/95 th percentiles). In this case BEAM/Phoenix would let you plan capacity to minimize max latency fairly well as it appears very consistent.
But raw java servlets delivered 100+k req/s. It may mean that all this event loop/async/actors hype is overrated, and regular blocking approach can also deliver.
… and "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."
FAQ 1.4 What sort of problems is Erlang not particularly suitable for?
But it also has native coroutines embedded into language, which provide excellent asynchronous performance.
Java and Go are terrible.
Simple as that.
I think people obviously enjoy using Python/Ruby or whatever for small scripts, and by inductive reasoning they think they can enjoy programming even larger projects in these languages.
They also rationalize the slowness by pretending that performance doesn't matter or that the bottle neck is the database.
They abuse the adage about "premature optimization" being a bad thing. Not realizing that while it's stupid to prematurely optimize everything, it's equally unwise to write everything in a slow language. Using a fast language is not premature optimization; it's just the basic thing you need to do in order to not have a crappy optimization, which is a good thing , and everyone should do that.
Or, you know... You can actually measure those things. And unless you're growing like crazy, or have a massive initial audience, you're likely to find that 90%+ of the app time is spent in the database and your CPU time isn't even close to maxed out.
Why would you assume people would pretend any of that is true?
[0]: https://www.slideshare.net/Blaine/scaling-twitter/3-First_So...
Also, if your audience is small enough that a slow python can suffice, why even bother using a database server such as postgresql or mysql when you can just use sqlite and simplify the architecture?
EDIT:
[1] It's been 10 years since 2007 but people still do this more or less all the time. Write a webapp in js/ruby/python and spawn 20 instances of the application server
Recent benchmarks of a properly setup Ruby environment vs Go/Gin are showing Ruby/Sinatra as having 50% of the throughput https://www.techempower.com/benchmarks/#section=data-r14&hw=...
You can also just use JRuby and use a single JVM process. For small CLI apps, MRuby can even be compiled to C, then compiled as an executable.
If you want to do anything interesting, Python/Ruby are slow as hell, which is why you cannot do anything interesting in them.
For example, while in Go, you can load say 1000 rows from the db and perform some data manipulation on it in the code to get a desired result, you cannot do this in Python because it will very very slow.
So what you do is you write complicated sql queries and essentially offload all your work from the application server(s) on to the database server.
Now imagine that these rows on the database don't actually change very often. You could just load them once, keep them in memory (in a global object), and only update them once in a while (when needed). You can always do whatever search/manipulation operation directly on the data that is readily available and always respond very quickly.
This would be _unthinkable_ if you are using Ruby or Python, so instead you keep hammering your database with the same query, over and over and over again.
Is Python/Django performance significantly worse than Ruby/Rails? The situations you describe are things I do every day in Ruby. Getting 1000 rows from the DB and performing some operation only takes a couple of milliseconds in Ruby.
Ruby/Python are meant to be glue, and you can most certainly use them to glue together "interesting things", like image processing or audio processing in a web layer.
Memory caching rarely changed, often accessed, but ultimately persisted in a DB things like exchange rates in a global object is exactly what you do in Rails. There's a specific helper for doing it. http://api.rubyonrails.org/classes/ActiveSupport/Cache/Memor...
It's similar with Ruby/RoR - yeah, they can do async. But not on their own. With unicorn server, you still get no threading and just a bunch of processes. With puma you can do threading (async cooperative really) - as long as you keep the configuration/code within the limits of what's allowed.
And due to the extra care needed whenever you do caching/storage things, I expect unicorn is still the king in RoR deployments. (GH uses that for example)
What about memory usage? That's an un-appreciated axis, IMO: for example, all of crates.io takes ~30mb resident, which is roughly the overhead for MRI itself, let alone loading code.
Anyway, the Rust team loves helping production users succeed, so if there's anything we can do, please let us know!
You will have to close that IT-only part of your brain for a moment, and keep in mind that people create software for a reason. And every nascent project lives or dies by how promptly it adapts against incorrect assumptions or changes in the environment.
Difference in hardware costs do not even enter into the radar. They happen in a different universe that good decision making completely ignores at this point.
After you have a proper solution to a problem, and enough scale so that it's worthwhile to collect those gains, you move your software to another language. It's not a big deal.
FWIW, it always seems like a mostly zero sum game to me. Whatever efficiency you gain in using (e.g.) Python+Latest Frontend Framework+Backend Framework, you lose through having to wade through yet another set of new concepts and documents for those frameworks.
Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important.
Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own.
All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit.
Java has come a long way since J2EE. These days it's asynchronous, non-blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.