[mixolydianagain]

> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language

The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.

[shakna]

Luajit and SBCL are very much performance competitive with the JVM? Why do you say that they're not?

Random example benchmark: https://madnight.github.io/benchmarksgame/lisp.html

[igouy]

That's someone's 8 year old mirror of the benchmarks game website.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[kscarlet]

These mean nothing. The C/C++ implementations use SIMD intrinsic while Lisp doesn't (it should have used sb-simd).

[igouy]

> The C/C++ implementations use SIMD intrinsic

Except when they don't.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[shakna]

Huh. And after eight years, SBCL and Java are side by side, still.

[igouy]

> Huh.

The hardware changed.

The way measurements were made changed.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The Java version changed.

The SBCL version changed.

> side by side

You'd have to say what you mean by that.

[shakna]

> You'd have to say what you mean by that.

They appear, literally, side by side, in the list. That is, they were competitive eight years ago. They are still competitive today.

[igouy]

By design, the 8 year old page you linked presented Lisp measurements side-by-side against Java measurements (by excluding the other programs).

There's overlap across most of the different language implementations:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[asa400]

They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.

[DoesntMatter22]

They don’t really need to be though. They take far fewer tokens and are still faster to develop with