Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

I mean, PyPy is over a decade old now, and micropython is a mere 7 years old. What's another fork? If anything, I strongly prefer languages that have more than one implementation.

View on HN

MicroPython isn't really an alternative implementation of Python so much as it is an embedded scripting language that looks pretty much identical to normal Python.

I do not disagree with you.

However, I would speculate part of PSF's hesitancy is likely specifically around the perceived violence that gross' "GIL-less" changes may incur to the runtime semantics' backwards compatibility.

PSF in particular has a responsibility here as well I feel in that CPython is arguably the working spec or standard from which these other implementations work and are defined.

Do you also strongly prefer languages with different underlying concurrency semantics? While stackless and pypy etc. are around and available and this could suggest the answer could be "yes" we've been lucky that they haven't fundamentally changed the experience of writing Python.

The possibility that a ton of libraries might now be able to use efficient multi-threaded execution where they were previously constrained to multiprocessing will be a landslide of changes on its own, and likely reminiscent of python 2 -> 3 compatibility if we have to preserve "two ways of doing things."

I can certainly agree that multiple implementations has overhead and creates pain points, but it's not world-ending and it does have advantages.

I think it’s important to ask “what guarantees are in place to keep multiple implementations consistent and what is the fallout if they are not” as a lens to determining the degree to which it is or isn’t “world-ending”

The Python ecosystem once fell apart not too long ago because it was supporting two versions where one moved from “print “ to “print(“ and these were incompatible and broke things such as doc tests.

There’s a reason that ppl strongly started advocating to hard pivot to 3: there was a very real chance that Python 2 could fork the ecosystem.

Incompatible concurrency semantics would be a much worse can of worms.

> If anything, I strongly prefer languages that have more than one implementation.

What popular languages fall into this category ? I can only think of C/C++ and JavaScript - both seem like terrible examples of languages that took forever to evolve (people still compile down JS to ES5). I'm not sure what the Java story is but I would argue it has been terrible at evolving the language as well.

I much prefer languages that have one implementation as a de facto standard, worked on by core team (eg. C#, Rust, TypeScript). Sure they might be a few random implementations - but the language is basically what the main compiler supports. Standards and specifications add so much overhead and I really don't see the value.

> What popular languages fall into this category ?

Not all, but many. Going down the list of most popular languages from https://www.tiobe.com/tiobe-index/ -

Python - CPython, PyPy, MicroPython

C - numerous (gcc, clang, msvc, tcc, etc.)

Java - https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

C++ - gcc, clang, msvc, etc.

C# - Microsoft's version and mono

Visual Basic - probably only one implementation

JavaScript - https://notes.eatonphil.com/javascript-implementations.html

SQL - assorted dialects, not sure that counts

PHP - probably only one implementation

ASM - assorted dialects, not sure that counts