Python 3.13 Gets a JIT

> Python is also much easier to learn than, say, Rust

I don't doubt it, but learning is only the first step to using a technology for a series of projects over years or even decades, and that step doesn't last that long.

People report being able to pick up Rust in a few weeks and being very productive. I was one of them, if you already got over the hill that was C++ then it sounds like you would be too. The point is that you and your team stay that productive as the project gets larger, because you can all enforce invariants for yourselves rather than have to carry their cognitive load and make up the extra slack with more testing that would be redundant with types.

Outside of maybe a 3 month internship, when is it worthwhile to penalize years of software maintenance to save a few weeks of once-off up-front learning? And it's not like you save it completely, writing correct Python still takes some learning too, e.g. beginners easily get confused about when mutable data structures are silently being shared and thus modified when they don't expect it. People who are already very comfortable with Python forget this part of their own learning curve, just like people very comfortable with Rust forget their first borrow check header scratcher.

I never made a performance argument in this thread so I'm not sure why 0.01 or 0.1 seconds matters here. Even the software that got you into a commercial market has to be maintained once you get there. Ask Meta how they feel about the PHP they're stuck with, for example.

It's a lot about popularity / stigma.

Microsoft developed both JScript and Node.js. They could've continued with JScript, but obviously decided against it because JScript didn't earn the reputation they might have hoped for. Even if they invested efforts into rectifying the flaws of JScript, it would've been just too hard to undo the reputation damage.

Microsoft made multiple attempts to "befriend" Python. IronPython was one of the failures. They also tried to provide editing tools (eg. intellisense in MSVS), but kind of given up on that too (but succeeded to a large degree with VSCode).

The whole long-term Microsoft's strategy is to capture and put the developers on a leash. They won't rest until there's a popular language they don't control.

are there any cl implementations that use jit? there are a lot of cl implementations so i assumed there must be one

Note that interpreter in the Lisp world by default has a different meaning.

A "Lisp interpreter" runs Lisp source in the form of s-expressions. That's what the first Lisp did.

A "Lisp compiler" compiles Lisp source code to native code, either directly or with the help of a C compiler or an assembler. A Lisp compiler could also compile source code to byte code. In some implementations this byte code can be JIT compiled (ABCL, CLISP, ...).

The first Lisp provided a Lisp to assembly compiler, which compiled Lisp code to assembly code, which then gets compiled to machine code. That machine code could be loaded into Lisp and functions then could be native machine code.

The Newton Toolkit could compile type declared functions to machine code. That's something most Common Lisp compilers do, sometimes by default (SBCL, CCL, ... by default directly compile source code to machine code).

SBCL:

    * (defun add (a b) (declare (fixnum a b) (optimize (speed 3))) (+ a b))
    ADD
    * (disassemble #'add)
    ; disassembly for ADD
    ; Size: 104 bytes. Origin: #x7006E1789C                       ; ADD
    ; 89C:       0000018B         ADD NL0, NL0, NL1
    ; 8A0:       0A0000AB         ADDS R0, NL0, NL0
    ; 8A4:       E7010054         BVC L1
    ; 8A8:       BD2A00B9         STR WNULL, [THREAD, #40]        ; pseudo-atomic-bits
    ; 8AC:       BC7A47A9         LDP TMP, LR, [THREAD, #112]     ; mixed-tlab.{free-pointer, end-addr}
    ; 8B0:       8A430091         ADD R0, TMP, #16
    ; 8B4:       5F011EEB         CMP R0, LR
    ; 8B8:       E8010054         BHI L2
    ; 8BC:       AA3A00F9         STR R0, [THREAD, #112]          ; mixed-tlab
    ; 8C0: L0:   8A3F0091         ADD R0, TMP, #15
    ; 8C4:       3E2280D2         MOVZ LR, #273
    ; 8C8:       9E0300A9         STP LR, NL0, [TMP]
    ; 8CC:       BF3A03D5         DMB ISHST
    ; 8D0:       BF2A00B9         STR WZR, [THREAD, #40]          ; pseudo-atomic-bits
    ; 8D4:       BE2E40B9         LDR WLR, [THREAD, #44]          ; pseudo-atomic-bits
    ; 8D8:       5E0000B4         CBZ LR, L1
    ; 8DC:       200120D4         BRK #9                          ; Pending interrupt trap
    ; 8E0: L1:   FB031AAA         MOV CSP, CFP
    ; 8E4:       5A7B40A9         LDP CFP, LR, [CFP]
    ; 8E8:       BF0300F1         CMP NULL, #0
    ; 8EC:       C0035FD6         RET
    ; 8F0:       E00120D4         BRK #15                         ; Invalid argument count trap
    ; 8F4: L2:   1C0280D2         MOVZ TMP, #16
    ; 8F8:       0AFBFF58         LDR R0, #x7006E17858            ; SB-VM::ALLOC-TRAMP
    ; 8FC:       40013FD6         BLR R0
    ; 900:       F0FFFF17         B L0
    NIL

I've entered a function and it gets ahead of time compiled to non-generic machine code.

Calling the function ADD with the wrong numeric arguments is an error, which will be detected both a compile and at runtime.

    * (add 3.0 2.0)

    debugger invoked on a TYPE-ERROR @7006E17898 in thread
    #:
      The value
        3.0
      is not of type
        FIXNUM
      when binding A

Redefinition of + will do nothing to the code. The addition is inlined machine code.

It's fascinating to me that this process seems to rhyme with that of the path PHP took, with HHVM being built as a second implementation, proving that PHP could be much faster -- and the main project eventually adopting similar approaches. I wonder if that's always likely to happen when talking about languages as big as these are? Can a new implementation of it ever really compete?