bakery2k

Isn't Pyodide just an interpreter that runs in the browser? So it could never be significantly faster than the regular Python interpreter?

> And they're all used extensively.

That's the key. MicroPython is significantly less dynamic than full Python, and would be much easier (but still not easy) to write a fast JIT for. Unfortunately such a JIT wouldn't be very useful - MicroPython won't run much code that hasn't been written specifically for it. Without the dynamic features, MicroPython is essentially a different language from regular Python.

The article claims that most professional software engineers are "makers" - people who build things for other people to use. I would put myself in this category, but I really struggled when I was a professional software engineer because the job seems to be set up for "poets" and "hackers", not for "makers".

Once I've finished building something, as a "maker", I want to be involved in communication with customers and to see how my work is being used. If I've done the hard work of programming something that's useful to others, the reward I need is to see how useful they are finding the thing I've made.

However, for a professional developer the reward for finishing a programming task is just "more programming". I can see how this would appeal to "poets" and "hackers" - it gives them the opportunity to "write more poetry" or "do more hacking" - but not to "makers".

Don't all the keys in a Go map have to have the same type? So if you use structs as keys, they all need to have the same length?

In Python, you can use (1, 2), (3, 4, 5) and (6, 7, 8, 9, 10) all as keys in the same map.

I thought strings in Go could contain arbitrary byte sequences?

> I wrote up a list of "things I wish python would fix but I think probably never will"

What else is on your list? I'd be interested to see what other parts of Python you would wish to change.

> Ends not means, almost entirely, for most people who aren’t full-time programmers.

And for many who are. Maybe not on our main projects, but at least for helper tools, side projects etc.

I haven't seen anything about `StopIteration` being removed?

In fact, the Python developers recently doubled-down on the design by introducing `StopAsyncIteration`.

What's wrong with parallelism in Go?

> Conclusion:

> * Programming language implementations cannot establish confidentiality on today's hardware

> * Don't run untrusted code in the same process with secrets it could steal

I understand that because of this, browsers are moving towards running untrusted JavaScript code in separate processes, so that confidentiality is provided by process boundaries.

Does anyone know whether other applications that embed scripting languages and run untrusted code (e.g. games that embed Lua[JIT]) are also moving towards a multi-process architecture?

Not in terms of performance. No interpreter comes anywhere near the speed of JIT compilers such as LuaJIT, V8 and PyPy.

I have a small, CPU-intensive benchmark which shows the performance of QuickJS to be comparable to other interpreters written in C. It's on par with MicroPython and recent versions of Ruby, and a little faster than CPython and Lua.

However, it's still 2-3x slower than the optimized, CPU-specific interpreters used in LuaJIT and V8 (with their JITs disabled), and 20-100x slower than the LuaJIT, V8 and PyPy JIT compilers.

What if I'm writing code that's strictly single-threaded? Presumably malloc could be simpler and/or faster in this special case?

Is there a production-ready allocator that's optimized for single-threaded use?

Does anyone know what Matz thinks of Sorbet? He has previously been opposed to adding type annotations to Ruby [1].

This is in sharp contrast to Python, where Guido has overwhelmingly embraced type annotations.

[1] https://bugs.ruby-lang.org/issues/9999#note-13

The article does not mention Python, other than to reference CPython's "Flexible String Representation". However, it's interesting that alternative Python implementations have decided against that model and indeed use UTF-8 strings internally.

MicroPython saves memory by simply making indexing into its strings O(n) [1], while PyPy's UTF-8 strings have "an optional extra index data structure to make indexing O(1)" [2].

For compatibility, of course, Python implementations have to provide indexing of code points - it would be interesting to examine the pros & cons of the different string representations. I wonder if new high-level languages would be better off using one of these representations, or taking the Go/Julia approach of only indexing bytes.

[1] https://github.com/micropython/micropython/blob/a4f1d82757b8...

[2] https://twitter.com/pypyproject/status/1095971192513708032

> a dynamic scripting language that is designed to have a good, simple JIT

Julia is designed along these lines - its JIT compiler is really just does AOT compilation at runtime. JavaScript JITs tend to work along the lines of:

    1. Interpret (and gather profiling data including type information)
    2. JIT compile hot code, making assumptions based on profiling data
    3. Deoptimize (fall back to the interpreter) if an assumption is broken

Julia does none of this - it can only work with types that are explicitly stated or that can be inferred statically. For extremely dynamic source code, Julia's compiler must emit slow, highly generic machine code.

This is why Julia code tends to contain many more explicit types than code in other dynamic languages. Compared to other JIT-compiled dynamic languages, Julia trades-off some dynamism for compiler simplicity.

As I understand it, the JVM can assume that local variables are not modified by other threads. My question is why can't CPython make the same assumption?

On the contrary, the Global Interpreter Lock provides many thread-safety guarantees. These are based on the fact that threads can only be interrupted between, not within, byte code instructions.

For example, a single list can safely be extended (as in `l += [1]`) concurrently from several threads.

I'm not sure which "side channel results" you refer to, but I don't think Python tries to prevent Spectre-style attacks at all. I don't believe it's necessary because, unlike JavaScript and Lua, Python doesn't try to support running within an in-process sandbox.

Unladen Swallow had a small fraction of the resources that Google allocated to V8, though. I think it was only worked on by a few interns.

Pyston was better supported, but I think just too ambitious - IIRC it was initially intended to be a full rewrite and to be compatible with C-extensions.

> any thread can change the internal variables of any other thread at any time

Why is this different from Java, where the JVM can assume that local variables cannot be changed by other threads?

That is, in the absence of special cases, which I believe include `volatile` and function calls. (Any other special cases?)

> Every implementation of Python is based on CPython.

Not quite true - there are notes in the documentation that call out parts of CPython's behaviour as "implementation-specific".

These are quite rare though. I seem to recall the suggestion being made that MicroPython shouldn't call itself "an implementation of Python" simply because its internal string encoding is UTF-8.

> This also leads to the sad fact that every non-CPython implementation has to provide C API that's compatible with CPython if they want to be adopted widely.

A specification for the C API wouldn't necessarily help with this. The problem for alternative implementations is that the C API is closely tied to CPython internals - there is no reason that having a specification would change that.

Designing and specifying a more abstracted API would be useful - but I don't see it happening.

Thanks for this - I hadn't seen it before. Looks like an implementation of the core Python interpreter designed to work more like the reference interpreter for Lua.

Unfortunately it seems to be incomplete - and even if support for exceptions etc were added, I suspect some of Python's more highly dynamic features (e.g. inspection of stack frame objects) would be extremely difficult to support in a compatible way.

I think supporting such niche dynamic features would be essential - I've found the Python community to be strongly against the idea of changing (or removing) such features in the pursuit of increased performance.

LuaJIT is the same, as is V8 (at least with Ignition & TurboFan). The article's assumption that fewer instructions = faster does not necessarily apply to these implementations, but is approximately correct for CPython (because it's a simple bytecode interpreter).

Nvidia have used nonsensical model numbers for a long time. Remember the GeForce 4 MX?

How would your Python derivative differ from RustPython?

Compatibility with C extensions seems to be the most difficult thing for an alternative implementation to achieve. PyPy struggled with this for a long time, and IIRC extension compatibility also caused the failure of Dropbox's Pyston.

Is there really no situation in which an alternative implementation that only supports "pure Python" would be useful?

Does an RTG count as "nuclear power"?

It's a really good article! Nothing too advanced, but concisely explains a lot of the basic concepts of both a compiler and an interpreter.

Isn't this how Python itself implements function calls, using the host (C) stack? Hence Python's lack of support for stackful coroutines?