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.
There's nothing inherently unique, they're just a good combo of features.
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".
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.
(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.)
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.
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.
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...
That's barely even making use of those languages runtimes as well.
Importing the regex libs won’t affect the results by more than a rounding error.
We were talking about start up time when using a CLI tool. Loading a VM is only part of that.
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.