6 ms·

> I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how

> I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things. That doesn't surprise me at all. Writing it in C++ would probably take me a lot longer than writing it in Python too.

lmm 9y ago
Why is that the comparison point though? How long would it have taken in, say, OCaml or Haskell, which would have given similar correctness guarantees to Rust?
- kadenshep 9y ago
  Because Rust is a systems language?
  - lmm 9y ago
    What does that cash out as that the programmer cares about though? A task like "read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any special systems-ness (and maybe Rust is only a suitable choice for problems where you need that systems-ness, but people seem to be writing a lot of ordinary code in it and advertising it for non-systems uses).
    - kadenshep 9y ago
      Because C/C++ are systems languages. You can use a hammer for whatever you like, that doesn't make it the right tool for the job. If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give you some amount of "longer" just by virtue of Rust's general strictness and lengthy semantics (like any systems language), but you can't just squash together your unfamiliarity with the language or its libraries and use that to determine the base line difficulty of implementation. To highlight this, consider a seasoned C# developer trying to read an XML file in python for the first time. It would probably take them "10x" longer in python too, and it won't be because the languages have different purposes/audiences or the languages' rules and conventions.
      - lmm 9y ago
        > If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. I'd take the view that "a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any more speed than Python, but can benefit from more correctness. I'm willing to spend a bit more implementation time than Python to get more safety than Python, but I'm not willing to spend extra time just to make it faster (and frankly I'd question the priorities of someone who would). If implementing in Rust is slower than a more error-prone language, that's not necessarily a mark against it - but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.
        kadenshep 9y ago
        >but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance. Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? It's going to be less error prone and faster.
        lmm 9y ago
        > Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? CPU cycles are cheap - my CPU is idle most of the time - and my time is expensive. Given that the script in question is fetching a file over FTP, the time taken for that is going to swamp any compute time (even in the Python implementation). Even if you could make a version that ran instantly, how many times would I have to run the script to add up to saving 30 minutes of my time? It doesn't sound like the kind of script that's going to be in use for decades. > It's going to be less error prone and faster. Sure, but the overwhelming majority of the time "faster" doesn't matter. So I'm much more interested in comparing languages that have the same safety properties, and whether it's possible to get the same "less error prone" effect from a language that's easier to work in than Rust.
- Skunkleton 9y ago
  I can't imagine a new OCaml or Haskell programmer getting this done faster than a novice Python programmer. Personally, I don't think this is even an interesting metric. These are tools for experts, understanding expert experiences is more interesting.
- stirner 9y ago
  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 9y 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 9y 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 9y 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 9y 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
- SolarNet 9y ago
  Because Rust and C++ have similar domains.

lmm 9y ago

Why is that the comparison point though? How long would it have taken in, say, OCaml or Haskell, which would have given similar correctness guarantees to Rust?

kadenshep 9y ago
Because Rust is a systems language?
- lmm 9y ago
  What does that cash out as that the programmer cares about though? A task like "read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any special systems-ness (and maybe Rust is only a suitable choice for problems where you need that systems-ness, but people seem to be writing a lot of ordinary code in it and advertising it for non-systems uses).
  - kadenshep 9y ago
    Because C/C++ are systems languages. You can use a hammer for whatever you like, that doesn't make it the right tool for the job. If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give you some amount of "longer" just by virtue of Rust's general strictness and lengthy semantics (like any systems language), but you can't just squash together your unfamiliarity with the language or its libraries and use that to determine the base line difficulty of implementation. To highlight this, consider a seasoned C# developer trying to read an XML file in python for the first time. It would probably take them "10x" longer in python too, and it won't be because the languages have different purposes/audiences or the languages' rules and conventions.
    - lmm 9y ago
      > If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. I'd take the view that "a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any more speed than Python, but can benefit from more correctness. I'm willing to spend a bit more implementation time than Python to get more safety than Python, but I'm not willing to spend extra time just to make it faster (and frankly I'd question the priorities of someone who would). If implementing in Rust is slower than a more error-prone language, that's not necessarily a mark against it - but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.
      - kadenshep 9y ago
        >but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance. Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? It's going to be less error prone and faster.
        lmm 9y ago
        > Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? CPU cycles are cheap - my CPU is idle most of the time - and my time is expensive. Given that the script in question is fetching a file over FTP, the time taken for that is going to swamp any compute time (even in the Python implementation). Even if you could make a version that ran instantly, how many times would I have to run the script to add up to saving 30 minutes of my time? It doesn't sound like the kind of script that's going to be in use for decades. > It's going to be less error prone and faster. Sure, but the overwhelming majority of the time "faster" doesn't matter. So I'm much more interested in comparing languages that have the same safety properties, and whether it's possible to get the same "less error prone" effect from a language that's easier to work in than Rust.
Skunkleton 9y ago
I can't imagine a new OCaml or Haskell programmer getting this done faster than a novice Python programmer. Personally, I don't think this is even an interesting metric. These are tools for experts, understanding expert experiences is more interesting.
stirner 9y ago
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 9y 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 9y 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 9y 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 9y 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
SolarNet 9y ago
Because Rust and C++ have similar domains.