5 ms·

This is oft-repeated, but I don't really agree in most cases anymore. These days 90% of software like web application front ends & back ends, mobile applicatio

This is oft-repeated, but I don't really agree in most cases anymore. These days 90% of software like web application front ends & back ends, mobile applications, desktop applications, data pipelines, etc. are all written with some library in a language like Java, C++, Obj-C, Python, Ruby, or maybe Go. Arguably modern software is going to be more efficient for the vast majority of cases if the author sticks to the best practices for their chosen platform/library than trying to roll their own C implementation or tweak what's going on underneath. Writing C from scratch for anything other than an embedded device or low-level system library is probably ill-advised.

jerf 10y ago
"Java, C++, Obj-C, Python, Ruby, or maybe Go." If you want to write efficient software, which is certainly not always necessary, you're looking at a ~50x factor difference between the top and the bottom of that list, which even in this age of "let's just spin up another couple dozen instances" is non-trivial.
- mi100hael 10y ago
  Sure, even within languages you can be looking at nearly a 50x difference based on things like framework & database choice. Hence my suggestion that raw language speed should not be a deciding factor for most projects these days. For example, look at the difference between the gemini-postgres and dropwizard-mongodb: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune&s=1&l=9r6ek https://www.techempower.com/benchmarks/#section=data-r12&hw=...
  - greenshackle2 10y ago
    I think you're both correct... the big question here is whether there is a good library to do the heavy lifting in your app. If there is, then choice of library will matter more than the app language, as long as there are bindings for your language of choice. IF, and this is a big IF, you're doing something weird enough that you have to do the heavy lifting yourself, choosing an efficient language will matter a lot. At least for the heavy-lifting parts - you could still implement most of the the app in an easy inefficient language, and only do the heavy parts in C. That's what happens in Python, and that's why my Python apps are only 3-10 times slower than pure C ("only" considering that Python is likes 100x slower than C).
- emodendroket 10y ago
  Only if your app is CPU-bound. How many are? And even then often a better algorithm is going to get bigger gains than a faster language.
  - jstimpfle 10y ago
    Face it, often the available processing time is very much finite, and the slower version just doesn't cut it. And the same holds for memory. Your system has only so much of it, and for applications with many small objects most high level languages are very memory-inefficient if written in an idiomatic style. This can easily amount to a size factor of 20x in what's processable at all (disregarding execution time). Add garbage collection (which can "drown" processing) and the factor might even be higher. Try adding a few Integers to a Java map and you will be surprised how inefficient it is.
    - emodendroket 10y ago
      I suppose in many applications it is. My career has pretty much been in Web apps and generally most work is I/O-dominated
  - jerf 10y ago
    "If you want to write efficient software, which is certainly not always necessary, ..."
- gozur88 10y ago
  50x? That would surprise me, though I'm no expert in Ruby or Go. The problem with writing things in C or C++ is in the time it takes you to finish the first working cut of a nontrivial program you could have done the same thing in Java and finished four or five tuning cycles. If you stop there the Java will most likely be faster. How often do you get to write, say, a driver or a utility where "fast enough" won't do and there is enough of a business case to wring out those last few cycles?

jerf 10y ago

"Java, C++, Obj-C, Python, Ruby, or maybe Go." If you want to write efficient software, which is certainly not always necessary, you're looking at a ~50x factor difference between the top and the bottom of that list, which even in this age of "let's just spin up another couple dozen instances" is non-trivial.

mi100hael 10y ago
Sure, even within languages you can be looking at nearly a 50x difference based on things like framework & database choice. Hence my suggestion that raw language speed should not be a deciding factor for most projects these days. For example, look at the difference between the gemini-postgres and dropwizard-mongodb: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune&s=1&l=9r6ek https://www.techempower.com/benchmarks/#section=data-r12&hw=...
- greenshackle2 10y ago
  I think you're both correct... the big question here is whether there is a good library to do the heavy lifting in your app. If there is, then choice of library will matter more than the app language, as long as there are bindings for your language of choice. IF, and this is a big IF, you're doing something weird enough that you have to do the heavy lifting yourself, choosing an efficient language will matter a lot. At least for the heavy-lifting parts - you could still implement most of the the app in an easy inefficient language, and only do the heavy parts in C. That's what happens in Python, and that's why my Python apps are only 3-10 times slower than pure C ("only" considering that Python is likes 100x slower than C).
emodendroket 10y ago
Only if your app is CPU-bound. How many are? And even then often a better algorithm is going to get bigger gains than a faster language.
- jstimpfle 10y ago
  Face it, often the available processing time is very much finite, and the slower version just doesn't cut it. And the same holds for memory. Your system has only so much of it, and for applications with many small objects most high level languages are very memory-inefficient if written in an idiomatic style. This can easily amount to a size factor of 20x in what's processable at all (disregarding execution time). Add garbage collection (which can "drown" processing) and the factor might even be higher. Try adding a few Integers to a Java map and you will be surprised how inefficient it is.
  - emodendroket 10y ago
    I suppose in many applications it is. My career has pretty much been in Web apps and generally most work is I/O-dominated
- jerf 10y ago
  "If you want to write efficient software, which is certainly not always necessary, ..."
gozur88 10y ago
50x? That would surprise me, though I'm no expert in Ruby or Go. The problem with writing things in C or C++ is in the time it takes you to finish the first working cut of a nontrivial program you could have done the same thing in Java and finished four or five tuning cycles. If you stop there the Java will most likely be faster. How often do you get to write, say, a driver or a utility where "fast enough" won't do and there is enough of a business case to wring out those last few cycles?