Hacker News Reader

Comment by pests | Hacker News Reader

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.

View on HN

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.

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.

> 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".

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.

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.)

Do you know of any libraries in C that give me an easy way to manipulate tabular data by columns, like pandas does?

There is miller. But it's a CLI tool, not s library. Maybe it comes bundled with a library?

https://github.com/johnkerl/miller

What does that have to do with "lower level OS-dependent APIs"?

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.

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.

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.

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.

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/544b643bba018fb6bd302a5c46222...

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.

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.

The comment was about loading a large VM at each invocation, so only minimal example is sufficient.

Sure, technically.

We were talking about start up time when using a CLI tool. Loading a VM is only part of that.

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

In 150ms the other tool would be finished before any of those had even begun. Plus, this is for a print statement, you'd have to factor in dependencies as well to get a real idea of how long it took.

That 150ms is especially important if the tool is running in a loop in a bash command.

That is a long time, though. An eternity in terms of compute.

With a warm cache, ripgrep takes 80-100ms to search 500MB of files across all the projects that I have checked out (for a regex like /val\w+;/ which matches 500 lines). Python starts (also from a warm cache) in 30ms on my machine. 30-40% seems like a large percentage by most measures.

Reply on news.ycombinator.com