5 ms·

I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attem

I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion. the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, frankly.

plosi 11y ago
Additionally, even the microbenchmark barely supports it based upon the size of the error bars
- igouy 11y ago
  Incidentally, those are the upper and lower quartiles not error bars.
igouy 11y ago
At this point, the only response needed to "rust is slow" claims is - rustc is beta. Come back when it's cooked :)
- Manishearth 11y ago
  Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster. The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use. (Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)
  - karmakaze 11y ago
    Indeed for x64-one-core[1] the geometric mean is now closer to Fortran and Ada. [1] http://benchmarksgame.alioth.debian.org/u64/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64/which-programs-a...
  - igouy 11y ago
    > Also, those benchmarks are a year old IIRC < Why didn't you check the commit age in the repo?
jcranmer 11y ago
Correction: a set of microbenchmarks whose own documentation emphatically states the difficulty of drawing any conclusions from those results. Comparing different programming languages is notoriously difficult, particularly since the metric is underdefined. The best programmers might write faster code in language A compared to language B, but if average programmers write code that is no faster, does that mean language A is better than language B?
- igouy 11y ago
  > the difficulty of drawing any conclusions from those results < The difficulty of drawing general conclusions from program performance measurements -- not just "those results".
EugeneOZ 11y ago
This article is difficult to read in original (for native speaker) too. Just raw flow of minds, without any shape.

plosi 11y ago

Additionally, even the microbenchmark barely supports it based upon the size of the error bars

igouy 11y ago
Incidentally, those are the upper and lower quartiles not error bars.

igouy 11y ago

At this point, the only response needed to "rust is slow" claims is - rustc is beta. Come back when it's cooked :)

Manishearth 11y ago
Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster. The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use. (Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)
- karmakaze 11y ago
  Indeed for x64-one-core[1] the geometric mean is now closer to Fortran and Ada. [1] http://benchmarksgame.alioth.debian.org/u64/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64/which-programs-a...
- igouy 11y ago
  > Also, those benchmarks are a year old IIRC < Why didn't you check the commit age in the repo?

jcranmer 11y ago

Correction: a set of microbenchmarks whose own documentation emphatically states the difficulty of drawing any conclusions from those results. Comparing different programming languages is notoriously difficult, particularly since the metric is underdefined. The best programmers might write faster code in language A compared to language B, but if average programmers write code that is no faster, does that mean language A is better than language B?

igouy 11y ago
> the difficulty of drawing any conclusions from those results < The difficulty of drawing general conclusions from program performance measurements -- not just "those results".

EugeneOZ 11y ago

This article is difficult to read in original (for native speaker) too. Just raw flow of minds, without any shape.