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.
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.
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.
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.