9 ms·

The Alternative Implementation Problem

272 points by mpweiher 2y ago

pansa2 2y ago
> positioning your project as an alternative implementation of something is a losing proposition > don’t go trying to create a subset of Python I agree - a project that's marketed as "Python but with more X" is always going to struggle to compete with the canonical implementation. (Especially if X is speed - ultimately, if you're using a dynamically-typed language you probably don't care about execution speed). However, alternative implementations are not always doomed to failure. MicroPython seems to be somewhat successful, despite supporting little more than Python 3.4 (10 years old). It's designed to run on microcontrollers so it's not competing with CPython - it's competing with other microcontroller programming environments. OTOH, I'm sure the MicroPython maintainers get a lot of feature requests for more recent Python features. I once considered building an alternative implementation of Python that's lightweight and focused on embedding in applications - again, it wouldn't be competing with CPython, but with Lua. The number one feature request seemed to be "will it support NumPy?"
- jononor 2y ago
  Interestingly MicroPython is now getting attention/requests for usage one the web. Thanks to efforts from PyScript (which are fantastic). However there is much more expectations here (compared to a micro with 1MB RAM total) that existing code will run, and having full CPython experience/compatibility. Which is very challenging. At the same time though, there seems to be work ongoing in CPython to make it work better in frontend. Main painpoint is the package size.
wfleming 2y ago
I think the takeaway of how to succeed with this kind of project is good, but a missing element for why so many kind of never take off that I haven’t seen mentioned yet is that a lot of times the compatability of these alternative implementations is in practice lower than claimed even for old language features. E.g. it’s very common for Ruby and Python apps to have some native C extensions somewhere in their dependencies, and AFAIK the major alternative implementations have never supported them. (They’ve tried sometimes, but it’s never really worked out for obvious technical reasons, and the alternative of expecting libraries to provide multiple implementations has a rocky history as well.) Combine that with the fact these languages are often used to make CRUD websites where I/O is likely to be a bigger performance factor than CPU and the faster alternatives look a lot less appealing.
awinter-py 2y ago
I feel this way about all wrapper code where someone is like 'okay we need our own internal version of this API'. the reasons vary but are like 'we don't trust people to use the official API correctly' (which, fine, but yours is less standard and worse-documented). sometimes the answer is 'we need extra functionality' which, fine, but 1) don't wrap the entire API for gods sake, just add 3 functions, and 2) your codebase over time will end up 99% polyfills point being if you are not using the defaults you are inflicting great misery on whoever inherits your codebase
- vitalnodo 2y ago
  With such wrappers, it should help to have an interface there to interact with the lower library directly, I think. For example, there is the ziggy-pydust library to write native modules for Python in Zig, and it certainly looks prettier than the usual Python.h import. Still, there is also .ffi to address functions directly that are not yet implemented but are available in Python.h. If such an option is not available, one often wants to replace such a library and prefer the original one. However, even this is in a way a wrapper (a native module), and sometimes it is better to use ctypes directly, for example, for the sake of speed of development.
ofey404 2y ago
> positioning your project as an alternative implementation of something is a losing proposition. Insightful, as I witnessed the problem caused by TiDB's compatibility with MySQL.
lsc4719 2y ago
Is there any comment on Kotlin?
- wavemode 2y ago
  Kotlin succeeded precisely because it is its own language (though still interoperable with Java). If it were just a modified reimplementation of Java nobody would bother with it.
  - pjmlp 2y ago
    Kotlin succeeded because Google got in bed with Jetbrains for their IDE and programming language. Without Google pushing Kotlin no matter what on Android, Kotlin would be yet another JVM guest language.
tedunangst 2y ago
LuaJIT is mentioned, but I think it also demonstrates that this is not always the case. Lots of people and projects also selected luajit over lua as a deliberate choice.
- vedranm 2y ago
  Came to the comments to post just this. LuaJIT is enthusiastically used in the TeX community and luajittex executable is readily available in parallel to luatex.
physicsguy 2y ago
Even where the language is defined by a standards committee, you end up with similar problems. In C and C++ the number of compilers has been rapidly dwindling; Intel’s suite is now LLVM based, as is Microsoft’s. Borland and others are a thing of the past.
- wavemode 2y ago
  Huh? MSVC is now based on LLVM? Where can I read about this? Or am I misreading what you're saying
  - miffy900 2y ago
    MSVC is not LLVM based, but C++ MSbuild projects can optionally use clang/LLVM as the C++ compiler instead of MSVC. Microsoft is still actively maintaining MSVC
- pjmlp 2y ago
  C++ Builder just got a release last month, and even though it is now LLVM based, the whole set of extensions and Delphi interop from Borland days are pretty much part of the whole picture. Also another interesting tidy bit, all those compiler vendors that leech from clang/LLVM hardly contribute to upstream in regards to ISO C++ compliance, hence why nowadays clang is lagging behind versus its initial velocity.
SergeAx 2y ago
> If you want your Python software to be PyPy-compatible, you’re much more limited in terms of which Python features you use More so, you are also limited in terms of popular libraries versions, and it is much more cumbersome because of versioning hell itself.
n4r9 2y ago
The moral here seems to be that people will not switch to "the same but better/cheaper". As a consequence, being competitive does not work. To what extent is this an indictment of capitalism and/or free market ideology? The linked Thiel speech video is interesting. It says that the aim of a capitalist is not to compete, but to create a monopoly. This is starkly against the interests of the consumer, and we see the results of that today with the enshittification of modern tech. Are we at a stage where the capitalist elites themselves are freely admitting that the system works for them and against the general public?
- doubloon 2y ago
  That is not capitalism that is state socialism aka fascism , as a state is required to enforce a monopoly. Being rich does not make him smart or correct.
  - aleph_minus_one 2y ago
    > a state is required to enforce a monopoly There exist lots of kinds of monopolies; only for some of them a state is necessary to enforce them.
  - n4r9 2y ago
    That might be correct when it comes to an strict monopoly where a state provides exclusive rights to one company. Thiel is talking more loosely about tech firms with large market shares such as Google or Microsoft. Such corporations typically maintain their market share through a mixture of mergers & acquisitions, product bundling, consumer manipulation, and government lobbying. Only the last of these requires a state. Similar arguments apply to other industries with a small number of large-market-share players, such as oil, airlines, music eventing etc... . A lot of these industries operate at a global level, without being dependent on regulations from any individual state. See for example: https://www.upi.com/Top_News/Opinion/2015/03/26/The-Kraft-Heinz-merger-the-monopoly-on-food/4591427324041/ https://www.upi.com/Top_News/Opinion/2015/03/26/The-Kraft-He...
  - munificent 2y ago
    > as a state is required to enforce a monopoly. Citation needed.
crabbone 2y ago
> New versions of CPython come out regularly, always adding many new features, and PyPy struggles to keep up, is always several Python versions behind. If you want you Python software to be PyPy-compatible, you’re much more limited in terms of which Python features you use, and most Python programmers don’t want to have to think about that. Nothing can be further from the truth. A small minority, in any language, not just Python, will use the most recent version. In any language community, the most used version lags several iterations behind the most recently released. In a decade and a half of working with Python, changing plenty of companies and positions, I've never been in a situation where I was using the newest version right after it was released. Not for the "production" environment anyways. The reason PyPy is not popular is... if I had to guess that Python is a first language for many programmers (i.e. the its audience is mostly not very knowledgeable in general, and will struggle to install a Python, installing a special kind of Python will be too overwhelming for them). Python is also a popular language with people who aren't professional programmers, eg. researchers, statisticians. In many places where Python is used its speed makes no difference, even if its used by professional programmers (eg. various kinds of automation). So, there's no particular reason to choose PyPy. To top this: Python is a common language for OS scripting / automation, where interpreter starting time may be more important than the performance of the script. PyPy mostly doesn't support native Python modules, but even when it does, it offers no benefits in so doing. Finally, there's a low-hanging fruit for any Python programmer who makes Python packages: just run them through Cython. This alone gives a significant boost to speed (and some memory savings). Virtually nobody does this. Which is, imo, an indication that speed isn't important. (Also, fighting Python infrastructure and trying to understand the packaging process isn't for the faint of heart, which underscores my previous point of general low competency on the part of Python users). ---- Bottom line: PyPy doesn't offer anything of value to the overwhelming majority of Python users. It would've been a headache to work with even where there might be potential benefits. So... it's not used. Python's release schedule is laughably bad, and new features are laughably bad... well, worthless for the most part... but they aren't the reason PyPy isn't popular.
- pjmlp 2y ago
  If I learned anything from my startup days with Tcl, writing extensions in C, was to never ever use again a programming language for production code that doesn't have a JIT/AOT story, and keeps pushing for a dual language approach instead. I only use Python for portable OS scripting tasks because of that, if they don't need to be portable, it is either UNIX shell/Perl, or Powershell.
munificent 2y ago
This is a really excellent post. I love love love the sociology of technology. Maintainers of a language implementation would like to have maximum flexibility in designing and shipping new features that benefit their users. They don't want to be hamstrung by having to get multiple implementations to agree before they can get a feature out the door. As a case study, look at how glacially slow JavaScript evolution was for many years. And look at how comparatively fast TypeScript evolves. At the same time, alternate implementations can be a signal of the robustness of your language ecosystem, so there is an upside too. And if the alternate implementation is really good (even if just for some subset of users with niche requirements), it can be a real value add for your ecosystem. So if you're a language designer/maintainer, you might not be actively hostile to alternate implementations, but there are downsides. And, for the most part, the feedback you'll get from users will be towards encouraging you to ship new features and evolve the language. You won't get too many people asking you to slow down so that PyPy/IronRuby/LuaJIT/etc. can keep up. For a language consumer, choosing which implementation to build on is often a choice where the biggest priority is safety and stability. No one wants to find themselves sitting on a million-line codebase that happens to subtlely rely on the behavioral quirks of some languishing alternate implementation created by a very bright PhD student who has since moved onto other projects. So there's a very strong positive feedback loop where users tend to go to the most-used implementation, which then encourages other users to go to that implementation, which encourages... The network effects are quite strong. The end result is that unless there are quite strong forces pushing in the other direction, most languages tend towards a single canonical implementation. There's a good argument that that's a good thing: it means that almost all engineering effort put into implementing the language benefits all users instead of it being divided among a number of separate implementations. The downside, of course, is that the implementation can get stuck in a local maximum.
epotato 2y ago
[flagged]
phendrenad2 2y ago
I think a similar thing happened with PHP. There was no JIT, then a JIT was merged into the mainline codebase, and now we all have JIT. Yay! Alternative implementations like HipHop VM from Facebook really never took off except for the rare engineering org that wanted to experiment with it.
jurschreuder 2y ago
But what about Clang and gcc?
pfarrell 2y ago
I learned something similar founding a startup. If I could do it again, I would have aggressively avoided pursuing the table stakes feature in our space. Instead we should have done the minimal amount to be comfortable that our architecture could support the enterprisey things. We should have then concentrated everything on something that would set us apart, something we could demo and get a “wow… I see where this could go” instead of something like “oh this is just a clone of x”.
- Xcelerate 2y ago
  If I understand you correctly, you’re saying implement the bare minimum for enterprise customers—whatever their leadership requires to do business with you—but beyond that, forget about those features and focus on something very novel that sets you apart from the competition?
  - AnimalMuppet 2y ago
    If you're just like the competition, you lose, because you're more of an unknown. If you want to win business, you have to have something that your established competitors do not. (And, of course, it has to be something that your customers want, not just some random thing.)
    - lelanthran 2y ago
      > If you're just like the competition, you lose, because you're more of an unknown. That sword cuts both ways. The reason the competition in a field has converged on all the same features, all looking the same and acting the same is because they were all shaped by the same market forces: that's what the businesses wanted! If a potential client looks at your product and it doesn't look like a duck, doesn't talk like a duck and doesn't walk like a duck, they're going to assume that it's not a duck. I've pitched a fairly simple product (still iterating on it so not sharing details) that had some extra features (not AI) to a business, and the business eventually went with a more expensive competing product, with my contact at the place explaining "The stakeholders feel that your product is for a slightly different use-case." Yes, my product did have all the features of the competition. The added feature was low-code extensibility for the backend API. The business interpreted the API-extending-mechanism as "Something only big companies would use", not "Something we can ignore if we don't use". Now, fair enough, this is absolutely an outlier - in most cases extensibility is regarded favourably. But, in this edge-case the audience came away with the primary impression of "Great Development Tool", not "Great User Product"[1]. Humans still have this notion that a thing has a primary purpose and multiple secondary purposes, and they'll absolutely go with the product that has, as it's primary purpose, satisfying their need, even if some other product's secondary purpose also satisfies their need. [1] And yes, this was a failure of the pitch. For future pitches, I'll tailor to the audience, highlighting their needs and ignoring anything that the product does which isn't in their list of needs.
apitman 2y ago
Thias sounds similar to the situation with web browsers. In theory they're built on open protocols. In practice whatever chrome wants will eventually be where things go.
- marssaxman 2y ago
  That may be, but I'll only find out what that is when Firefox implements it...
- andrewla 2y ago
  Except that Chrome itself emerged as an "alternative implementation". We had Mosaic which lost to Netscape which lost to IE which lost to Firefox which lost (ish) to Chrome. And in the mobile space things are still kind of wild. If anything Chrome is an exception to the article's "Alternative Implementation Problem"; what started as Konquerer, an alternative browser, eventually mutated into the most common desktop browser currently in use.
- ikari_pl 2y ago
  it's like this only because nobody except me seems to prefer Firefox
  - kreddor 2y ago
    Oh, I use it as well, especially on Android where it has proper support for extensions.
  - gary_0 2y ago
    I don't use Firefox because it's Firefox, I use it because it's not Chrome.
    - gonzo41 2y ago
      I use FF because I want to browse the web without being signed in to everything.
      - 2y ago
breck 2y ago
Having worked on languages and compilers for many years, I thoroughly enjoyed this post. Another way to phrase the same idea: a language is _a lot more_ than just compile speed. Compile speed is very important, in the top 10 dimensions, for sure. Especially because improving compile speed increases the developer feedback loop clock speed which helps the core team improve all the other dimensions faster. But there are still >30 other dimensions that are very important in a programming language.
- mmoskal 2y ago
  The post seems to be about execution speed though. However, even there it's definitely not #1 factor as witnessed by popularity of CPython...
miki123211 2y ago
I'll add one more point which the OP missed, but which is also very important. If you're developing an alternative implementation, you probably have a different architecture from the canonical version, and things that are easy to do in the main implementation might be very difficult to do in yours. Let's say there's a piece of proprietary software for creating financial reports[1], which is using a weird binary format to store their documents. You want to make a free alternative, which can load and save these documents. The format is not fun to deal with, so you have a single function that loads the whole document into memory and one that dumps your data structures back to disk and entirely overwrites the file, but you operate purely on in-memory data while the software is running. What you don't know is that the proprietary software doesn't do this, it was developed in the days when users had very little RAM, so it only loads and saves the section the user is currently operating on, and knows how to modify the document in-place. Then, the proprietary software introduces a way to add attachments to their documents. People keep adding stupidly large files, recordings of investor calls, scanned PDFs with hundreds of pages and so on. THe proprietary software loads documents one section at a time, so this works just fine. You, on the other hand, always deserialize the entire document at once, which suddenly becomes a problem when the documents are bigger than the users' available RAM memory. You now basically have to re-architect the entirety of your software, to support a change that took a week of a single developer's time for the main implementation. [1] a purely hypothetical example, I've never actually worked in this space.
- 4death4 2y ago
  > things that are easy to do in the main implementation might be very difficult to do in yours. The author mentions this when they talk about the ease of implementing new features in an interpreted language vs. a compiled language.
  - foota 2y ago
    Hm, this is true, but I think it's worth pointing out that this is more general. The article was focusing on how JIT is harder than interpreting, whereas neither model in parent's post is inherently more complicated.
- 2y ago
phkahler 2y ago
Another less popular take is that people (yes me too at times) should check their ego. It can definitely be easier to make "your own" parallel project vs contributing to an existing open source project, but ask yourself who you're serving. Is it the project maintainers? The project itself? The users? Your own ego? Hint: if that last suggestion makes you mad it's probably in play ;-) Adding a JIT to an existing language is a major undertaking, so the canonical implementation will have a high bar for acceptance. But you should probably still aim for that. Forking or rolling your own can provide freedom to do big things too, but that should often be regarded as temporary. If your goal is to show what you can do, it probably won't go far. If your goal is to make something better for its good, you'll learn to work within others constraints.
- konstantinua00 2y ago
  Suprisingly, I have the opposite opinion All the people that preach about single project, contributing only to canonical project and having no alternative implementations need to check their egos, learn about existance of multiple approaches and why competition is better than monopoly As I see it, article shows how Python, Lua and Ruby failed many people by choosing this approach - causing thousands of devs and millions of users to have slower development and software. Not because it's not possible - but because administratively there's no insentive to do that
  - aleph_minus_one 2y ago
    > All the people that preach about single project [...] need to [...] learn [...] why competition is better than monopoly Then tell me: why is competition better than monopoly for these [!] people?
  - aragilar 2y ago
    At least in the case of Python, it's not obvious it's slower overall. PyPy has always had issues interfacing with C-extensions, and for lots of cases using something built on C-extensions is not only faster but easier to use (see the scientific ecosystem built on numpy). If core parts of your ecosystem don't run, or perform worse on your "faster" alternative, then don't be surprised it isn't widely adopted.
arnorhs 2y ago
Great post. Definitely some great lessons in there. It's missing a key ingredient though... I see this as any other competing alternative to any kind of product. It's like saying Amazon failed because the didn't have a brick and mortar book store like people were used to.. obviously that's not the case The reason all these jit-alts failed and were in a constant catch up, is because in practicality, most developers of x-language don't care that much about JIT. Or more importantly, they care more about language features and interoperability than they care about JIT. This is why a product that "joins them" rather than competing wins. Because you are not offering more stability and/or interoperability.

272 points by mpweiher 2y ago

> positioning your project as an alternative implementation of something is a losing proposition > don’t go trying to create a subset of Python I agree - a project that's marketed as "Python but with more X" is always going to struggle to compete with the canonical implementation. (Especially if X is speed - ultimately, if you're using a dynamically-typed language you probably don't care about execution speed). However, alternative implementations are not always doomed to failure. MicroPython seems to be somewhat successful, despite supporting little more than Python 3.4 (10 years old). It's designed to run on microcontrollers so it's not competing with CPython - it's competing with other microcontroller programming environments. OTOH, I'm sure the MicroPython maintainers get a lot of feature requests for more recent Python features. I once considered building an alternative implementation of Python that's lightweight and focused on embedding in applications - again, it wouldn't be competing with CPython, but with Lua. The number one feature request seemed to be "will it support NumPy?"

jononor 2y ago
Interestingly MicroPython is now getting attention/requests for usage one the web. Thanks to efforts from PyScript (which are fantastic). However there is much more expectations here (compared to a micro with 1MB RAM total) that existing code will run, and having full CPython experience/compatibility. Which is very challenging. At the same time though, there seems to be work ongoing in CPython to make it work better in frontend. Main painpoint is the package size.

wfleming 2y ago

I think the takeaway of how to succeed with this kind of project is good, but a missing element for why so many kind of never take off that I haven’t seen mentioned yet is that a lot of times the compatability of these alternative implementations is in practice lower than claimed even for old language features. E.g. it’s very common for Ruby and Python apps to have some native C extensions somewhere in their dependencies, and AFAIK the major alternative implementations have never supported them. (They’ve tried sometimes, but it’s never really worked out for obvious technical reasons, and the alternative of expecting libraries to provide multiple implementations has a rocky history as well.) Combine that with the fact these languages are often used to make CRUD websites where I/O is likely to be a bigger performance factor than CPU and the faster alternatives look a lot less appealing.

awinter-py 2y ago

I feel this way about all wrapper code where someone is like 'okay we need our own internal version of this API'. the reasons vary but are like 'we don't trust people to use the official API correctly' (which, fine, but yours is less standard and worse-documented). sometimes the answer is 'we need extra functionality' which, fine, but 1) don't wrap the entire API for gods sake, just add 3 functions, and 2) your codebase over time will end up 99% polyfills point being if you are not using the defaults you are inflicting great misery on whoever inherits your codebase

vitalnodo 2y ago
With such wrappers, it should help to have an interface there to interact with the lower library directly, I think. For example, there is the ziggy-pydust library to write native modules for Python in Zig, and it certainly looks prettier than the usual Python.h import. Still, there is also .ffi to address functions directly that are not yet implemented but are available in Python.h. If such an option is not available, one often wants to replace such a library and prefer the original one. However, even this is in a way a wrapper (a native module), and sometimes it is better to use ctypes directly, for example, for the sake of speed of development.

ofey404 2y ago

> positioning your project as an alternative implementation of something is a losing proposition. Insightful, as I witnessed the problem caused by TiDB's compatibility with MySQL.

lsc4719 2y ago

Is there any comment on Kotlin?

wavemode 2y ago
Kotlin succeeded precisely because it is its own language (though still interoperable with Java). If it were just a modified reimplementation of Java nobody would bother with it.
- pjmlp 2y ago
  Kotlin succeeded because Google got in bed with Jetbrains for their IDE and programming language. Without Google pushing Kotlin no matter what on Android, Kotlin would be yet another JVM guest language.

tedunangst 2y ago

LuaJIT is mentioned, but I think it also demonstrates that this is not always the case. Lots of people and projects also selected luajit over lua as a deliberate choice.

vedranm 2y ago
Came to the comments to post just this. LuaJIT is enthusiastically used in the TeX community and luajittex executable is readily available in parallel to luatex.

physicsguy 2y ago

Even where the language is defined by a standards committee, you end up with similar problems. In C and C++ the number of compilers has been rapidly dwindling; Intel’s suite is now LLVM based, as is Microsoft’s. Borland and others are a thing of the past.

wavemode 2y ago
Huh? MSVC is now based on LLVM? Where can I read about this? Or am I misreading what you're saying
- miffy900 2y ago
  MSVC is not LLVM based, but C++ MSbuild projects can optionally use clang/LLVM as the C++ compiler instead of MSVC. Microsoft is still actively maintaining MSVC
pjmlp 2y ago
C++ Builder just got a release last month, and even though it is now LLVM based, the whole set of extensions and Delphi interop from Borland days are pretty much part of the whole picture. Also another interesting tidy bit, all those compiler vendors that leech from clang/LLVM hardly contribute to upstream in regards to ISO C++ compliance, hence why nowadays clang is lagging behind versus its initial velocity.

SergeAx 2y ago

> If you want your Python software to be PyPy-compatible, you’re much more limited in terms of which Python features you use More so, you are also limited in terms of popular libraries versions, and it is much more cumbersome because of versioning hell itself.

n4r9 2y ago

The moral here seems to be that people will not switch to "the same but better/cheaper". As a consequence, being competitive does not work. To what extent is this an indictment of capitalism and/or free market ideology? The linked Thiel speech video is interesting. It says that the aim of a capitalist is not to compete, but to create a monopoly. This is starkly against the interests of the consumer, and we see the results of that today with the enshittification of modern tech. Are we at a stage where the capitalist elites themselves are freely admitting that the system works for them and against the general public?

doubloon 2y ago
That is not capitalism that is state socialism aka fascism , as a state is required to enforce a monopoly. Being rich does not make him smart or correct.
- aleph_minus_one 2y ago
  > a state is required to enforce a monopoly There exist lots of kinds of monopolies; only for some of them a state is necessary to enforce them.
- n4r9 2y ago
  That might be correct when it comes to an strict monopoly where a state provides exclusive rights to one company. Thiel is talking more loosely about tech firms with large market shares such as Google or Microsoft. Such corporations typically maintain their market share through a mixture of mergers & acquisitions, product bundling, consumer manipulation, and government lobbying. Only the last of these requires a state. Similar arguments apply to other industries with a small number of large-market-share players, such as oil, airlines, music eventing etc... . A lot of these industries operate at a global level, without being dependent on regulations from any individual state. See for example: https://www.upi.com/Top_News/Opinion/2015/03/26/The-Kraft-Heinz-merger-the-monopoly-on-food/4591427324041/ https://www.upi.com/Top_News/Opinion/2015/03/26/The-Kraft-He...
- munificent 2y ago
  > as a state is required to enforce a monopoly. Citation needed.

crabbone 2y ago

> New versions of CPython come out regularly, always adding many new features, and PyPy struggles to keep up, is always several Python versions behind. If you want you Python software to be PyPy-compatible, you’re much more limited in terms of which Python features you use, and most Python programmers don’t want to have to think about that. Nothing can be further from the truth. A small minority, in any language, not just Python, will use the most recent version. In any language community, the most used version lags several iterations behind the most recently released. In a decade and a half of working with Python, changing plenty of companies and positions, I've never been in a situation where I was using the newest version right after it was released. Not for the "production" environment anyways. The reason PyPy is not popular is... if I had to guess that Python is a first language for many programmers (i.e. the its audience is mostly not very knowledgeable in general, and will struggle to install a Python, installing a special kind of Python will be too overwhelming for them). Python is also a popular language with people who aren't professional programmers, eg. researchers, statisticians. In many places where Python is used its speed makes no difference, even if its used by professional programmers (eg. various kinds of automation). So, there's no particular reason to choose PyPy. To top this: Python is a common language for OS scripting / automation, where interpreter starting time may be more important than the performance of the script. PyPy mostly doesn't support native Python modules, but even when it does, it offers no benefits in so doing. Finally, there's a low-hanging fruit for any Python programmer who makes Python packages: just run them through Cython. This alone gives a significant boost to speed (and some memory savings). Virtually nobody does this. Which is, imo, an indication that speed isn't important. (Also, fighting Python infrastructure and trying to understand the packaging process isn't for the faint of heart, which underscores my previous point of general low competency on the part of Python users). ---- Bottom line: PyPy doesn't offer anything of value to the overwhelming majority of Python users. It would've been a headache to work with even where there might be potential benefits. So... it's not used. Python's release schedule is laughably bad, and new features are laughably bad... well, worthless for the most part... but they aren't the reason PyPy isn't popular.

pjmlp 2y ago
If I learned anything from my startup days with Tcl, writing extensions in C, was to never ever use again a programming language for production code that doesn't have a JIT/AOT story, and keeps pushing for a dual language approach instead. I only use Python for portable OS scripting tasks because of that, if they don't need to be portable, it is either UNIX shell/Perl, or Powershell.

munificent 2y ago

This is a really excellent post. I love love love the sociology of technology. Maintainers of a language implementation would like to have maximum flexibility in designing and shipping new features that benefit their users. They don't want to be hamstrung by having to get multiple implementations to agree before they can get a feature out the door. As a case study, look at how glacially slow JavaScript evolution was for many years. And look at how comparatively fast TypeScript evolves. At the same time, alternate implementations can be a signal of the robustness of your language ecosystem, so there is an upside too. And if the alternate implementation is really good (even if just for some subset of users with niche requirements), it can be a real value add for your ecosystem. So if you're a language designer/maintainer, you might not be actively hostile to alternate implementations, but there are downsides. And, for the most part, the feedback you'll get from users will be towards encouraging you to ship new features and evolve the language. You won't get too many people asking you to slow down so that PyPy/IronRuby/LuaJIT/etc. can keep up. For a language consumer, choosing which implementation to build on is often a choice where the biggest priority is safety and stability. No one wants to find themselves sitting on a million-line codebase that happens to subtlely rely on the behavioral quirks of some languishing alternate implementation created by a very bright PhD student who has since moved onto other projects. So there's a very strong positive feedback loop where users tend to go to the most-used implementation, which then encourages other users to go to that implementation, which encourages... The network effects are quite strong. The end result is that unless there are quite strong forces pushing in the other direction, most languages tend towards a single canonical implementation. There's a good argument that that's a good thing: it means that almost all engineering effort put into implementing the language benefits all users instead of it being divided among a number of separate implementations. The downside, of course, is that the implementation can get stuck in a local maximum.

epotato 2y ago

[flagged]

phendrenad2 2y ago

I think a similar thing happened with PHP. There was no JIT, then a JIT was merged into the mainline codebase, and now we all have JIT. Yay! Alternative implementations like HipHop VM from Facebook really never took off except for the rare engineering org that wanted to experiment with it.

jurschreuder 2y ago

But what about Clang and gcc?

pfarrell 2y ago

I learned something similar founding a startup. If I could do it again, I would have aggressively avoided pursuing the table stakes feature in our space. Instead we should have done the minimal amount to be comfortable that our architecture could support the enterprisey things. We should have then concentrated everything on something that would set us apart, something we could demo and get a “wow… I see where this could go” instead of something like “oh this is just a clone of x”.

Xcelerate 2y ago
If I understand you correctly, you’re saying implement the bare minimum for enterprise customers—whatever their leadership requires to do business with you—but beyond that, forget about those features and focus on something very novel that sets you apart from the competition?
- AnimalMuppet 2y ago
  If you're just like the competition, you lose, because you're more of an unknown. If you want to win business, you have to have something that your established competitors do not. (And, of course, it has to be something that your customers want, not just some random thing.)
  - lelanthran 2y ago
    > If you're just like the competition, you lose, because you're more of an unknown. That sword cuts both ways. The reason the competition in a field has converged on all the same features, all looking the same and acting the same is because they were all shaped by the same market forces: that's what the businesses wanted! If a potential client looks at your product and it doesn't look like a duck, doesn't talk like a duck and doesn't walk like a duck, they're going to assume that it's not a duck. I've pitched a fairly simple product (still iterating on it so not sharing details) that had some extra features (not AI) to a business, and the business eventually went with a more expensive competing product, with my contact at the place explaining "The stakeholders feel that your product is for a slightly different use-case." Yes, my product did have all the features of the competition. The added feature was low-code extensibility for the backend API. The business interpreted the API-extending-mechanism as "Something only big companies would use", not "Something we can ignore if we don't use". Now, fair enough, this is absolutely an outlier - in most cases extensibility is regarded favourably. But, in this edge-case the audience came away with the primary impression of "Great Development Tool", not "Great User Product"[1]. Humans still have this notion that a thing has a primary purpose and multiple secondary purposes, and they'll absolutely go with the product that has, as it's primary purpose, satisfying their need, even if some other product's secondary purpose also satisfies their need. [1] And yes, this was a failure of the pitch. For future pitches, I'll tailor to the audience, highlighting their needs and ignoring anything that the product does which isn't in their list of needs.

apitman 2y ago

Thias sounds similar to the situation with web browsers. In theory they're built on open protocols. In practice whatever chrome wants will eventually be where things go.

marssaxman 2y ago
That may be, but I'll only find out what that is when Firefox implements it...
andrewla 2y ago
Except that Chrome itself emerged as an "alternative implementation". We had Mosaic which lost to Netscape which lost to IE which lost to Firefox which lost (ish) to Chrome. And in the mobile space things are still kind of wild. If anything Chrome is an exception to the article's "Alternative Implementation Problem"; what started as Konquerer, an alternative browser, eventually mutated into the most common desktop browser currently in use.
ikari_pl 2y ago
it's like this only because nobody except me seems to prefer Firefox
- kreddor 2y ago
  Oh, I use it as well, especially on Android where it has proper support for extensions.
- gary_0 2y ago
  I don't use Firefox because it's Firefox, I use it because it's not Chrome.
  - gonzo41 2y ago
    I use FF because I want to browse the web without being signed in to everything.
    - 2y ago

breck 2y ago

Having worked on languages and compilers for many years, I thoroughly enjoyed this post. Another way to phrase the same idea: a language is _a lot more_ than just compile speed. Compile speed is very important, in the top 10 dimensions, for sure. Especially because improving compile speed increases the developer feedback loop clock speed which helps the core team improve all the other dimensions faster. But there are still >30 other dimensions that are very important in a programming language.

mmoskal 2y ago
The post seems to be about execution speed though. However, even there it's definitely not #1 factor as witnessed by popularity of CPython...

miki123211 2y ago

I'll add one more point which the OP missed, but which is also very important. If you're developing an alternative implementation, you probably have a different architecture from the canonical version, and things that are easy to do in the main implementation might be very difficult to do in yours. Let's say there's a piece of proprietary software for creating financial reports[1], which is using a weird binary format to store their documents. You want to make a free alternative, which can load and save these documents. The format is not fun to deal with, so you have a single function that loads the whole document into memory and one that dumps your data structures back to disk and entirely overwrites the file, but you operate purely on in-memory data while the software is running. What you don't know is that the proprietary software doesn't do this, it was developed in the days when users had very little RAM, so it only loads and saves the section the user is currently operating on, and knows how to modify the document in-place. Then, the proprietary software introduces a way to add attachments to their documents. People keep adding stupidly large files, recordings of investor calls, scanned PDFs with hundreds of pages and so on. THe proprietary software loads documents one section at a time, so this works just fine. You, on the other hand, always deserialize the entire document at once, which suddenly becomes a problem when the documents are bigger than the users' available RAM memory. You now basically have to re-architect the entirety of your software, to support a change that took a week of a single developer's time for the main implementation. [1] a purely hypothetical example, I've never actually worked in this space.

4death4 2y ago
> things that are easy to do in the main implementation might be very difficult to do in yours. The author mentions this when they talk about the ease of implementing new features in an interpreted language vs. a compiled language.
- foota 2y ago
  Hm, this is true, but I think it's worth pointing out that this is more general. The article was focusing on how JIT is harder than interpreting, whereas neither model in parent's post is inherently more complicated.
2y ago

phkahler 2y ago

Another less popular take is that people (yes me too at times) should check their ego. It can definitely be easier to make "your own" parallel project vs contributing to an existing open source project, but ask yourself who you're serving. Is it the project maintainers? The project itself? The users? Your own ego? Hint: if that last suggestion makes you mad it's probably in play ;-) Adding a JIT to an existing language is a major undertaking, so the canonical implementation will have a high bar for acceptance. But you should probably still aim for that. Forking or rolling your own can provide freedom to do big things too, but that should often be regarded as temporary. If your goal is to show what you can do, it probably won't go far. If your goal is to make something better for its good, you'll learn to work within others constraints.

konstantinua00 2y ago
Suprisingly, I have the opposite opinion All the people that preach about single project, contributing only to canonical project and having no alternative implementations need to check their egos, learn about existance of multiple approaches and why competition is better than monopoly As I see it, article shows how Python, Lua and Ruby failed many people by choosing this approach - causing thousands of devs and millions of users to have slower development and software. Not because it's not possible - but because administratively there's no insentive to do that
- aleph_minus_one 2y ago
  > All the people that preach about single project [...] need to [...] learn [...] why competition is better than monopoly Then tell me: why is competition better than monopoly for these [!] people?
- aragilar 2y ago
  At least in the case of Python, it's not obvious it's slower overall. PyPy has always had issues interfacing with C-extensions, and for lots of cases using something built on C-extensions is not only faster but easier to use (see the scientific ecosystem built on numpy). If core parts of your ecosystem don't run, or perform worse on your "faster" alternative, then don't be surprised it isn't widely adopted.

arnorhs 2y ago

Great post. Definitely some great lessons in there. It's missing a key ingredient though... I see this as any other competing alternative to any kind of product. It's like saying Amazon failed because the didn't have a brick and mortar book store like people were used to.. obviously that's not the case The reason all these jit-alts failed and were in a constant catch up, is because in practicality, most developers of x-language don't care that much about JIT. Or more importantly, they care more about language features and interoperability than they care about JIT. This is why a product that "joins them" rather than competing wins. Because you are not offering more stability and/or interoperability.