6 ms·

During Perl’s hegemony as The Glue Language, I feel like the folk wisdom was: “Performance is a virtue; if Perl ceases to be good enough, or you need to write

During Perl’s hegemony as The Glue Language, I feel like the folk wisdom was: “Performance is a virtue; if Perl ceases to be good enough, or you need to write ‘serious’ software rewrite in C.” And during Python’s ascension, the common narrative shifted very slightly: “Performance is a virtue, but developer productivity is a virtue too. Plus, you can drop to C to write performance critical portions.” Then for our brief all-consuming affair with Ruby, the wisdom shifted more radically: “Developer productivity is paramount. Any language that delivers computational performance is suspect from a developer productivity standpoint.” But looking at “high-level” languages (i.e. languages that provide developer productivity enhancing abstraction), we can rewind the clock to look at language families that evolved during more resource-constrained times. Those languages, the lisps, schemes, smalltalks, etc. are now really, really fast compared to Python, and rarely require developers to shift to alternative paradigms (e.g. dropping to C) just to deliver acceptable performance. Perl and Python exploded right at the time that Lisp/Scheme hadn’t quite shaken the myth that they were slow, with Python/Perl achieving acceptable performance by having dropped to C most of the time. Now the adoption moat is the wealth of libraries that exist for Python—and it’s a hell of a big moat. If I were a billionaire, I’d hire a team of software developers to systematically review libraries that were exemplars in various languages, and write / improve idiomatic, performant, stylistically consistent versions in something modern like Racket. I’d like to imagine that someone would use those things :-)

edflsafoiewq 4y ago
Perl/Python/Ruby grew up in the 90s, the "Bubble economy" of the single core performance world, the likes of which had never and probably will never be seen again on the face of the Earth. In the post-Bubble world, throwing out 90% of your performance before you even start writing code, especially when the same dynamic features could be delivered via JIT without the cost, seems crazy.
- rockyj 4y ago
  So true, excellent point! I just do not understand startups choosing Python/Ruby in 2022 when you can get most of the features, type safety, concurrency, async and 5 times more speed in other languages.
  - WJW 4y ago
    I don't think it is such a surprise. The ecosystems around Rails (for Ruby) and numpy/pandas/etc (for python) are orders of magnitude larger than you get in the modern languages. In Rails for example, adding an entire user management system (including niceties like password reset mails and must-haves like proper security for obscure vulnerabilities most people will have never heard of) is literally a single extra line in the gemfile and two console commands. In python the ML and numerics ecosystem are completely beyond anything another language has to offer at the moment, even more so when you compare the time to get started. In addition, "real" performance is often tricky to measure and may be irrelevant compared to other parts of the system. Yes, Ruby is 10-100x slower than C. But if a user of my web service already has a latency of (say) 200ms to the server then it barely matters if the web service returns a response in 5 ms or in 0.5 ms. Similarly for rendering an email: no user will notice their email arriving half a second earlier. Similarly for a python notebook: if it takes 1 or 2 seconds to prepare some data for a GPU processing job that will take several hours, it doesn't really matter that the data preparation could have been done in 0.1 seconds instead if it had been done in Rust. Especially for startups where often you're not sure if you're building the right thing in the first place, a big ecosystem of prebuilt libraries is super important. If it turns out people actually want to buy what you've made in sufficient numbers that the inefficiency of Ruby/Python/JS/etc becomes a problem then you can always rewrite the most CPU intensive parts in another language. Most startup code will never have the problem of "too many users" though, so it makes no sense to optimize for that from the start.
    - SemanticStrengh 4y ago
      > are orders of magnitude larger than you get in the modern languages. This is plain wrong, Kotlin has access to the whole JVM/Java ecosystem. In fact in theory you can even access Python libraries via graalPython. Machine learning is one of the only niche to be language specific as if it's true that there are major Java deep learning libraries (such as the standford parser) they are increasingly obscolete vs Python.
  - ReflectedImage 4y ago
    Well if you choose Python/Ruby you only need 1/3 of the developers as if you choose another language. The productivity gain is so great it outweights everything else. It's as simple as that.
peatmoss 4y ago
Is it gauche to offer my own counterpoint? Another possibility is that the requirement to "drop to C" is a virtue by de-democratizing access to serious performance. In other words, let the commoners eat Python, while the anointed manage their own memory. I personally find this argument a bit distasteful / disagree with it, but there was a thread the other day that talked about the, uh, variable quality of code in the Julia ecosystem (Julia being another language where dropping to C isn't important for performance). In Julia, the academics can just write their code and get on with their work—the horror!
munificent 4y ago
> Those languages, the lisps, schemes, smalltalks, etc. The main reason those languages got fast despite being highly dynamic is because of very complex JIT VM implementations. (See also: JavaScript.) The cost of that is that a complex VM is much less hackable and makes it harder to evolve the language. (See also: JavaScript.) Python and Ruby have, I think, reasonably chosen to have slower simpler implementations so that they are able to nimbly respond to user needs and evolve the language without needing massive funding from giant corporations in order to support an implementation. (See also: JavaScript.) There are other effects at play, too, of course. Once your implementation's strategy for speed is "drop to C and use FFI", then it gets much harder to optimize the core language with stuff like a JIT and inlining because the FFI system itself gets in the way. Not having an FFI for JS on the web essentially forced JavaScript users to push to make the core language itself faster.
- peatmoss 4y ago
  Spending a weekend or two writing a Scheme that beats Python in performance has been a pastime for computer science students for at least a couple decades now. I'm not sure that I believe that a performant Scheme implementation has more complexity than e.g. PyPy. In fact, I'd wager the converse.
  - mrtranscendence 4y ago
    You're either exaggerating or the computer science students you're familiar with are wizards. I've never known the student who could write a Scheme implementation, from scratch, in one weekend that is both complete and which beats Python from a performance perspective.
    - peatmoss 4y ago
      If it's an exaggeration, it's not much of one. Two parts to your argument: - Writing a Scheme implementation quickly: Google "Write a Scheme in 48 hours" and "Scheme from scratch." 48 hours to a functioning Scheme implementation seems to be a feat replicated in multiple programming languages. - Performance: I haven't benchmarked every hobby scheme, but given the proliferation of Scheme implementations that, despite limited developer resources, beat (pure) Python with it's massive pool of developers (CPython, PyPy), I still don't buy the idea that optimizing Scheme is a harder task than optimizing Python. Again, I'd strongly suggest that optimizing Scheme is a much easier task than optimizing Python simply by virtue of how often the feat has been accomplished.
zdw 4y ago
This sounds a lot like what some Python package developers are trying with Rust (example being the cryptography package), which also has the unfortunate side effect of limiting support for some less popular platforms.
pyuser583 4y ago
My remembering of Python is, “developer experience is paramount; if you need more performance use PyPy.” To increase Python performance, you only need more Python!

edflsafoiewq 4y ago

Perl/Python/Ruby grew up in the 90s, the "Bubble economy" of the single core performance world, the likes of which had never and probably will never be seen again on the face of the Earth. In the post-Bubble world, throwing out 90% of your performance before you even start writing code, especially when the same dynamic features could be delivered via JIT without the cost, seems crazy.

rockyj 4y ago
So true, excellent point! I just do not understand startups choosing Python/Ruby in 2022 when you can get most of the features, type safety, concurrency, async and 5 times more speed in other languages.
- WJW 4y ago
  I don't think it is such a surprise. The ecosystems around Rails (for Ruby) and numpy/pandas/etc (for python) are orders of magnitude larger than you get in the modern languages. In Rails for example, adding an entire user management system (including niceties like password reset mails and must-haves like proper security for obscure vulnerabilities most people will have never heard of) is literally a single extra line in the gemfile and two console commands. In python the ML and numerics ecosystem are completely beyond anything another language has to offer at the moment, even more so when you compare the time to get started. In addition, "real" performance is often tricky to measure and may be irrelevant compared to other parts of the system. Yes, Ruby is 10-100x slower than C. But if a user of my web service already has a latency of (say) 200ms to the server then it barely matters if the web service returns a response in 5 ms or in 0.5 ms. Similarly for rendering an email: no user will notice their email arriving half a second earlier. Similarly for a python notebook: if it takes 1 or 2 seconds to prepare some data for a GPU processing job that will take several hours, it doesn't really matter that the data preparation could have been done in 0.1 seconds instead if it had been done in Rust. Especially for startups where often you're not sure if you're building the right thing in the first place, a big ecosystem of prebuilt libraries is super important. If it turns out people actually want to buy what you've made in sufficient numbers that the inefficiency of Ruby/Python/JS/etc becomes a problem then you can always rewrite the most CPU intensive parts in another language. Most startup code will never have the problem of "too many users" though, so it makes no sense to optimize for that from the start.
  - SemanticStrengh 4y ago
    > are orders of magnitude larger than you get in the modern languages. This is plain wrong, Kotlin has access to the whole JVM/Java ecosystem. In fact in theory you can even access Python libraries via graalPython. Machine learning is one of the only niche to be language specific as if it's true that there are major Java deep learning libraries (such as the standford parser) they are increasingly obscolete vs Python.
- ReflectedImage 4y ago
  Well if you choose Python/Ruby you only need 1/3 of the developers as if you choose another language. The productivity gain is so great it outweights everything else. It's as simple as that.

peatmoss 4y ago

Is it gauche to offer my own counterpoint? Another possibility is that the requirement to "drop to C" is a virtue by de-democratizing access to serious performance. In other words, let the commoners eat Python, while the anointed manage their own memory. I personally find this argument a bit distasteful / disagree with it, but there was a thread the other day that talked about the, uh, variable quality of code in the Julia ecosystem (Julia being another language where dropping to C isn't important for performance). In Julia, the academics can just write their code and get on with their work—the horror!

munificent 4y ago

> Those languages, the lisps, schemes, smalltalks, etc. The main reason those languages got fast despite being highly dynamic is because of very complex JIT VM implementations. (See also: JavaScript.) The cost of that is that a complex VM is much less hackable and makes it harder to evolve the language. (See also: JavaScript.) Python and Ruby have, I think, reasonably chosen to have slower simpler implementations so that they are able to nimbly respond to user needs and evolve the language without needing massive funding from giant corporations in order to support an implementation. (See also: JavaScript.) There are other effects at play, too, of course. Once your implementation's strategy for speed is "drop to C and use FFI", then it gets much harder to optimize the core language with stuff like a JIT and inlining because the FFI system itself gets in the way. Not having an FFI for JS on the web essentially forced JavaScript users to push to make the core language itself faster.

peatmoss 4y ago
Spending a weekend or two writing a Scheme that beats Python in performance has been a pastime for computer science students for at least a couple decades now. I'm not sure that I believe that a performant Scheme implementation has more complexity than e.g. PyPy. In fact, I'd wager the converse.
- mrtranscendence 4y ago
  You're either exaggerating or the computer science students you're familiar with are wizards. I've never known the student who could write a Scheme implementation, from scratch, in one weekend that is both complete and which beats Python from a performance perspective.
  - peatmoss 4y ago
    If it's an exaggeration, it's not much of one. Two parts to your argument: - Writing a Scheme implementation quickly: Google "Write a Scheme in 48 hours" and "Scheme from scratch." 48 hours to a functioning Scheme implementation seems to be a feat replicated in multiple programming languages. - Performance: I haven't benchmarked every hobby scheme, but given the proliferation of Scheme implementations that, despite limited developer resources, beat (pure) Python with it's massive pool of developers (CPython, PyPy), I still don't buy the idea that optimizing Scheme is a harder task than optimizing Python. Again, I'd strongly suggest that optimizing Scheme is a much easier task than optimizing Python simply by virtue of how often the feat has been accomplished.

zdw 4y ago

This sounds a lot like what some Python package developers are trying with Rust (example being the cryptography package), which also has the unfortunate side effect of limiting support for some less popular platforms.

pyuser583 4y ago

My remembering of Python is, “developer experience is paramount; if you need more performance use PyPy.” To increase Python performance, you only need more Python!