5 ms·

simply because of battle-tested jvm.

by xfer 8y ago

dorfsmay 8y ago
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 8y ago
  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/faster/racket-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - dorfsmay 8y ago
    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 8y ago
      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 8y ago
        ... which is why Racket-on-Chez[0] is a really exciting development. [0]: https://blog.racket-lang.org/2018/01/racket-on-chez-status.html https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...
        igouy 8y ago
        "Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance."
- xfer 8y ago
  racket compiled binaries are not "native", they are bytecodes jitted during runtime, and jvm's jit is highly performant.
  - dorfsmay 8y ago
    Oh, so like python. Explains the poor performance. I did not know that. thanks.
    - gameswithgo 8y ago
      no, python isn't jitted.
    - gus_massa 8y ago
      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/which-programs-are-fast.html 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 8y ago
        > I can't find a direct comparison of Python-vs-Racket in the site Now you will.
        gus_massa 8y ago
        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 :) ))
        8y ago

simply because of battle-tested jvm.

by xfer 8y ago

simply because of battle-tested jvm.

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 8y ago
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/faster/racket-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- dorfsmay 8y ago
  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 8y ago
    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 8y ago
      ... which is why Racket-on-Chez[0] is a really exciting development. [0]: https://blog.racket-lang.org/2018/01/racket-on-chez-status.html https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...
      - igouy 8y ago
        "Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance."
xfer 8y ago
racket compiled binaries are not "native", they are bytecodes jitted during runtime, and jvm's jit is highly performant.
- dorfsmay 8y ago
  Oh, so like python. Explains the poor performance. I did not know that. thanks.
  - gameswithgo 8y ago
    no, python isn't jitted.
  - gus_massa 8y ago
    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/which-programs-are-fast.html 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 8y ago
      > I can't find a direct comparison of Python-vs-Racket in the site Now you will.
      - gus_massa 8y ago
        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 :) ))
        8y ago