The original Dartmouth BASIC had a JIT like approach, the REPL would compile to machine code before execution.

It was the limits of 8 bit home computers hardware that made the interpreter version be more widely known.

Same to Lisp, Smalltalk, and many other languages.

Fully agree with you.

A few other small and fast JITs: https://github.com/zherczeg/sljit (used by libpcre), https://github.com/asmjit/asmjit (RPCS3 and FBGEMM) and https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... (only used by JSC in Webkit, I think)

This is absolutely a JIT-compiler. It compiles code into machine code. This is a surprisingly efficient way to get noticeable speedup relative to interpretation. Also it is much safer than proper optimising compiler. Say ebpf jit-compiler functions very similarly, because it is fast and _secure_ way to jit. (well, there's a bit of cheating because before emitting bpf bytecode it goes through gcc/clang pipeline).

LLVM is a large dependency if you need to JIT. There are plenty of smaller (and much faster) alternatives which are much better fit for smaller projects. Larger projects usually roll out their own jit-pipeline because they can integrate better with the source language/interpreter and apply tricks LLVM is not well suited to (say, LLVM is not great at deoptimisation). I think only Julia is really a heavy user of LLVM JIT, also it is known for extremely slow repl from time to time.

A non-optimizing compiler is a real compiler.

This absolutely is real JIT compilation. Copy and patch is a very well known JIT compilation technique.

is an xtensa lx7 (esp32-s3) target available that does not use llvm?

Not in typical builds of SBCL: all code is compiled before evaluation.

Is it really interesting though? It's essentially just vibe-coded by people who are unqualified for this kind of work. One of the authors claimed that what qualified them was having worked on a large-scale postgres cluster; they never actually worked on databases or compilers.

Anyone who thinks AI is good with writing code that is hard to write for the operator, not due to lack of basic software engineering know how but complexity of the domain, either has access to models beyond what is available to the public or is completely lost.

I believe this because every time I use AI for domains that I consider myself above competent, if it is anything beyond UI components or a simple CRUD endpoints, I cringe at the quality of what it generates.

This has made me to be extremely cautious of starting working in a new domain with AI if I want anything beyond throw away quick hacks or junk, shy of quick bug fixes perhaps.

So what, are you willing to go away from von-neumann architecture where instructions are data and data are instructions, i.e. the instruction-data hominocity that underpins JIT compilation? Are you willing to go to a pseudo-Harvard architecture where the ability of JIT compiling is soft locked by other means like VM or strong code authentication or policy protection, which is what Apple is doing.

Fun fact: even Apple themselves have JIT. JavaScriptCore on iOS has JIT, it's just that the App Store policies forbid any application submissions with JIT or trying to mmap/mprotect an executable region. There used to be apps on TrollStore that runs JIT

You're entirely correct because JIT requires violating Write xor Execute security policy. This is the reason on iOS, it is limited to Apple shipped software.

https://en.wikipedia.org/wiki/W%5EX

Maybe, but surely there are users who are willing to trust all users of their db instance.

It is the core of ClickHouse for example, for many years. Is it secure enough in your opinion?

In rust, is jit equivalent to an "unsafe" block ?

Machine code is insecure, we should all run interpreted code in a formally verified interpreter.

Alternatively, only allow for the execution of cryptographly signed static linked binaries, this naturally includes the interpreter above.