5 ms·

Neither OCaml[1] nor Haskell[2] has performance competitive with Rust. It’s impressive how many high-level functional features Rust was able to include, but it’

Neither OCaml[1] nor Haskell[2] has performance competitive with Rust. It’s impressive how many high-level functional features Rust was able to include, but it’s ultimately a systems language—and it’s unique precisely because it’s a fast systems language that can give the sorts of high-level guarantees usually reserved for GC languages. [1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... [2] https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=rust https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

lmm 8y ago
Depends what you're competing on. IIRC (can't view your link) OCaml/Haskell performance is much closer to Rust than it is to Python (runtime tends to like x for rust, 2x-5x for OCaml/Haskell, and 70x or more for Python) - if IshKebab's starting point was "my Python script is too slow, I need something an order of magnitude faster" then OCaml/Haskell would be competitive with Rust in that space.
- igouy 8y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... stirner seems to mean something different by "competitive".
pjmlp 8y ago
If I have a budget of 300ms and 100MB, am able to deliver it within 150ms and 30MB, why should I spend more money to make it lets say 50ms and 10MB?
- stirner 8y ago
  There are many reasons why you might use a systems programming language [1]. > System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical (AAA video games) or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based word processors). [1] https://en.m.wikipedia.org/wiki/System_programming https://en.m.wikipedia.org/wiki/System_programming
  - pjmlp 8y ago
    A few languages do support such low-level controls to have such fine grain memory control outside GC hands. So the question is, having been able to achieve half of the allowed budget, why pay for more development effort? Of course, if the bugdet is only achievable with a lower level language, there is no way around using it.
    - iopq 8y ago
      Because sometimes there's no budget, there's "we spend less money on hardware the less resources our program uses" so faster is always better.

lmm 8y ago

Depends what you're competing on. IIRC (can't view your link) OCaml/Haskell performance is much closer to Rust than it is to Python (runtime tends to like x for rust, 2x-5x for OCaml/Haskell, and 70x or more for Python) - if IshKebab's starting point was "my Python script is too slow, I need something an order of magnitude faster" then OCaml/Haskell would be competitive with Rust in that space.

igouy 8y ago
https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... stirner seems to mean something different by "competitive".

pjmlp 8y ago

If I have a budget of 300ms and 100MB, am able to deliver it within 150ms and 30MB, why should I spend more money to make it lets say 50ms and 10MB?

stirner 8y ago
There are many reasons why you might use a systems programming language [1]. > System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical (AAA video games) or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based word processors). [1] https://en.m.wikipedia.org/wiki/System_programming https://en.m.wikipedia.org/wiki/System_programming
- pjmlp 8y ago
  A few languages do support such low-level controls to have such fine grain memory control outside GC hands. So the question is, having been able to achieve half of the allowed budget, why pay for more development effort? Of course, if the bugdet is only achievable with a lower level language, there is no way around using it.
  - iopq 8y ago
    Because sometimes there's no budget, there's "we spend less money on hardware the less resources our program uses" so faster is always better.