And because Emacs Lisp a lisp, you get extensive syntactic malleability that you can use to build DSLs and convenience facilities.
Elisp is actually a very nice little language.
For what it’s worth, V8 among with some other JITs are some of the fastest engines in the world: https://arewefastyet.com/#machine=29&view=breakdown&suite=as...
I find that doubtful, when the jvm is so close to native code in terms of performance, and mozilla said that wasm (or was it asm.js? Forget which) was still 50% slower theoretically than native code.
Not saying that JavaScript is faster, but JavaScript is fast. If you look at the benchmarks I posted, you'll notice that 50% slower is hardly the norm -- many benchmarks have the VMs performing at a near-native performance, and the VMs are even faster in some cases.
In fact, number crunching in JavaScript has been fast for a long time, and even faster than Java in some cases: http://www.stefankrause.net/wp/?p=144
I'm not trying to advocate JavaScript's performance in anyway however. I'm merely pointing out the fact that performance cannot be single-handedly described as "fast" or "slow", especially "for sure". Context matters. A lot.
How can something be theoretically slower? What's the difference between theoretically slower and practically slower?
Only practical implementations have a speed that you can talk about.
I don't know what you mean by 'theoretically' as an adverb there.
It annoys me, actually, that "theory" has this negative connotation of noncorrespondance.
EDIT: Also, Emacs is bloated is bloated because it's not just a editor its's an Web Browser, Email Client, News Reader, Music Player and File Manager. If people want a light emacs, they can go use uEmacs or become the last JEDi.