5 ms·

A lot of CLI tools are quick scripts or other programs that will start, execute, and then die quickly. If a tool is written in an interpreted language or has t

by pests 8y ago

A lot of CLI tools are quick scripts or other programs that will start, execute, and then die quickly. If a tool is written in an interpreted language or has to load a large VM on each invocation than a large percentage of the total runtime of the CLI tool will be spent on language-specific tasks. With a non CLI tool such as a server or daemon the expectation is you start it once and it runs for awhile. In these cases startup time does not matter as much. Furthermore, for interpreted languages like JS/Python/PHP and languages that require a VM such as Java or C#, not everyone will have or want to install each languages runtime.

colanderman 8y ago
Yes, but Rust is far from unique in this regard. Maybe I shouldn't be surprised that "written in language without onerous runtime and installation overhead" is apparently now rare enough to be a selling point.
- wybiral 8y ago
  Languages like Rust and Go are just really easy to cross-compile compared to working with lower level OS-dependent APIs in C or something. There's nothing inherently unique, they're just a good combo of features.
  - saagarjha 8y ago
    > Languages like Rust and Go are just really easy to cross-compile compared to working with lower level OS-dependent APIs in C or something. You make it seem like C has no standard library. C is really easy to cross compile: you just add a -arch flag to your compiler frontend and, provided you're staying inside POSIX (which you should!) it should "just work".
    - hsivonen 8y ago
      C's standard library is completely broken for text handling (depends on external locale instead of caller-specified locale) and on Windows broken for file system access if your paths contain non-ASCII. (At least until the latest dev version of Windows 10.) Rust has the best file system abstraction for exposing Windows file paths in a way that allows you to write common file path handling application code for Windows and *nix.
  - colanderman 8y ago
    For basic load/munge/save stuff (like CSV processing) the C standard library more than suffices, and is cross-platform. You don't need OS-dependent stuff (like POSIX) to do that. (I'm not arguing C vs. Rust though... just pointing out that "cross-platform" is a much more meaningful descriptor for a CLI tool than "in Rust". The latter just reads like noise to me.)
    - jaipilot747 8y ago
      Do you know of any libraries in C that give me an easy way to manipulate tabular data by columns, like pandas does?
      - petre 8y ago
        There is miller. But it's a CLI tool, not s library. Maybe it comes bundled with a library? https://github.com/johnkerl/miller https://github.com/johnkerl/miller
      - colanderman 8y ago
        What does that have to do with "lower level OS-dependent APIs"?
        jaipilot747 8y ago
        Nothing, honestly. I was just looking to learn if there was a tool in C that could let me be just as productive as Pandas.
- paulddraper 8y ago
  Java, C#, Python, Ruby, Perl, PHP, Visual Basic, Scala, Clojure, Dart, Groovy, F#, Kotlin, JavaScript, and Lua are (almost always) interpreted languages. So that leaves C, C++, Rust, D, Pascal, Haskell, and maybe Go (depending how large the binary gets and if the GC gods are on your side). Whether or not it is "unique", it is a highly significant choice.
  - zmmmmm 8y ago
    Slightly semantic argument, but most of those languages are normally considered compiled. They have an interpreter, but it operates on a compiled form of the language. Eg: Java is "compiled", Java Byte Code is "interpreted". Slightly semantic but not completely, as a tremendous amount of optimisation can actually be done by that compile step.
    - paulddraper 8y ago
      Yes that is semantic. And not real distinguishing, given that most languages have bytecodes. This is true even of many "scripting" languages such as Python, PHP, and Ruby. > as a tremendous amount of optimisation can actually be done by that compile step. Not really. Look at something like Proguard which (among other things) is the #1 JVM bytecode optimizer. And yet the runtime performance differs very little before and after optimization. As long as you deliver reasonable bytecode, the JIT will capture every optimization and more that you could make to it. --- At the end of the day, machine code is thing that actually moves the needle on performance, whether JIT machine code or AOT machine code.
shawn 8y ago
If a tool is written in an interpreted language or has to load a large VM on each invocation than a large percentage of the total runtime of the CLI tool will be spent on language-specific tasks. This is a myth, FWIW. LuaJIT, python, and node all load within 150ms. And it's usually closer to 70ms: https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222ca6 https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222...
- pests 8y ago
  A single print statement? That is extremely artificial. I'd like to to see numbers wheb you're loading dependencies and on a real workload. That's barely even making use of those languages runtimes as well.
  - shawn 8y ago
    Why load dependencies when the task is text transformation? It’s not artificial. Importing the regex libs won’t affect the results by more than a rounding error.
  - londt8 8y ago
    The comment was about loading a large VM at each invocation, so only minimal example is sufficient.
    - pests 8y ago
      Sure, technically. We were talking about start up time when using a CLI tool. Loading a VM is only part of that.
- lifthrasiir 8y ago
  While it us technically possible to optimize dependency relations to minimize the startup cost for minimal tasks, it is very hard to do in reality. In the "oxidation" plan of the Mercurial SCM [1] this problem was directly addressed and one of the first suggested targets to switch to Rust was an alternative CLI frontend. [1] https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan

by pests 8y ago

colanderman 8y ago

Yes, but Rust is far from unique in this regard. Maybe I shouldn't be surprised that "written in language without onerous runtime and installation overhead" is apparently now rare enough to be a selling point.

wybiral 8y ago
Languages like Rust and Go are just really easy to cross-compile compared to working with lower level OS-dependent APIs in C or something. There's nothing inherently unique, they're just a good combo of features.
- saagarjha 8y ago
  > Languages like Rust and Go are just really easy to cross-compile compared to working with lower level OS-dependent APIs in C or something. You make it seem like C has no standard library. C is really easy to cross compile: you just add a -arch flag to your compiler frontend and, provided you're staying inside POSIX (which you should!) it should "just work".
  - hsivonen 8y ago
    C's standard library is completely broken for text handling (depends on external locale instead of caller-specified locale) and on Windows broken for file system access if your paths contain non-ASCII. (At least until the latest dev version of Windows 10.) Rust has the best file system abstraction for exposing Windows file paths in a way that allows you to write common file path handling application code for Windows and *nix.
- colanderman 8y ago
  For basic load/munge/save stuff (like CSV processing) the C standard library more than suffices, and is cross-platform. You don't need OS-dependent stuff (like POSIX) to do that. (I'm not arguing C vs. Rust though... just pointing out that "cross-platform" is a much more meaningful descriptor for a CLI tool than "in Rust". The latter just reads like noise to me.)
  - jaipilot747 8y ago
    Do you know of any libraries in C that give me an easy way to manipulate tabular data by columns, like pandas does?
    - petre 8y ago
      There is miller. But it's a CLI tool, not s library. Maybe it comes bundled with a library? https://github.com/johnkerl/miller https://github.com/johnkerl/miller
    - colanderman 8y ago
      What does that have to do with "lower level OS-dependent APIs"?
      - jaipilot747 8y ago
        Nothing, honestly. I was just looking to learn if there was a tool in C that could let me be just as productive as Pandas.
paulddraper 8y ago
Java, C#, Python, Ruby, Perl, PHP, Visual Basic, Scala, Clojure, Dart, Groovy, F#, Kotlin, JavaScript, and Lua are (almost always) interpreted languages. So that leaves C, C++, Rust, D, Pascal, Haskell, and maybe Go (depending how large the binary gets and if the GC gods are on your side). Whether or not it is "unique", it is a highly significant choice.
- zmmmmm 8y ago
  Slightly semantic argument, but most of those languages are normally considered compiled. They have an interpreter, but it operates on a compiled form of the language. Eg: Java is "compiled", Java Byte Code is "interpreted". Slightly semantic but not completely, as a tremendous amount of optimisation can actually be done by that compile step.
  - paulddraper 8y ago
    Yes that is semantic. And not real distinguishing, given that most languages have bytecodes. This is true even of many "scripting" languages such as Python, PHP, and Ruby. > as a tremendous amount of optimisation can actually be done by that compile step. Not really. Look at something like Proguard which (among other things) is the #1 JVM bytecode optimizer. And yet the runtime performance differs very little before and after optimization. As long as you deliver reasonable bytecode, the JIT will capture every optimization and more that you could make to it. --- At the end of the day, machine code is thing that actually moves the needle on performance, whether JIT machine code or AOT machine code.

shawn 8y ago

If a tool is written in an interpreted language or has to load a large VM on each invocation than a large percentage of the total runtime of the CLI tool will be spent on language-specific tasks. This is a myth, FWIW. LuaJIT, python, and node all load within 150ms. And it's usually closer to 70ms: https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222ca6 https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222...

pests 8y ago
A single print statement? That is extremely artificial. I'd like to to see numbers wheb you're loading dependencies and on a real workload. That's barely even making use of those languages runtimes as well.
- shawn 8y ago
  Why load dependencies when the task is text transformation? It’s not artificial. Importing the regex libs won’t affect the results by more than a rounding error.
- londt8 8y ago
  The comment was about loading a large VM at each invocation, so only minimal example is sufficient.
  - pests 8y ago
    Sure, technically. We were talking about start up time when using a CLI tool. Loading a VM is only part of that.
lifthrasiir 8y ago
While it us technically possible to optimize dependency relations to minimize the startup cost for minimal tasks, it is very hard to do in reality. In the "oxidation" plan of the Mercurial SCM [1] this problem was directly addressed and one of the first suggested targets to switch to Rust was an alternative CLI frontend. [1] https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan