[dorfsmay]

The JVM?

What about the battle-tested Linux kernel? If you compile your racket apps to a native binary, you can run it directly on the Linux kernel, and benefit from 25 years of use in production! People deploy Golang and Rustlang apps everyday in prod using that approach it seems to work well for them. Note, both languages are younger than Racket.

[mruts]

Compiled Racket programs are nowhere near the speed of Rust or Go. Racket's GC is objectively much much worse than the JVM.

Of course you can serve millions of users with Racket, like HN. But the JVM today is much better choice. The JVM's GC is world-class and the number of man-hours put in it is probably many orders of magnitudes more than that of Racket's.

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

[dorfsmay]

So execution speed, fair enough.

FWIW, I've been staying away from Clojure because of the JVM. A lot of us are wearing the scars of the JVM battles!

[fiddlerwoaroof]

If you need performance and want to avoid the jvm, there are also lisps like Chez Scheme and various Common Lisp implementations (sbcl, in particular, can produce really well-tuned numerical code).

[hjek]

... which is why Racket-on-Chez[0] is a really exciting development.

[0]: https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...

[igouy]

"Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance."

[xfer]

racket compiled binaries are not "native", they are bytecodes jitted during runtime, and jvm's jit is highly performant.

[dorfsmay]

Oh, so like python. Explains the poor performance. I did not know that. thanks.

[gus_massa]

As a broad approximation from the results of The Computer Language Benchmarks Game, Racket is 5 times faster than Python and 5 times slower than C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (I can't find a direct comparison of Python-vs-Racket in the site.)

The difference with Python is probably bigger in programs with a big numeric part, and much smaller in programs with a lot of string. Take that number just as a general guide, not as a precise scaling factor.

[igouy]

> I can't find a direct comparison of Python-vs-Racket in the site

Now you will.

[gus_massa]

Why is not everything-vs-everything available?

Racket vs Python is a "common" comparison. I write the same comment once or twice per year :). (Probably because both are high level and have the batteries included. (The syntax is slightly different :) ))

[igouy]

1) Everything-vs-everything is available, here —

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

2) People show interest in just a few comparisons (much much fewer than are currently shown).

3a) Everything-vs-everything is available, here —

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

3b) Everything-vs-everything is available, here —

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

[gameswithgo]

no, python isn't jitted.