Hacker News Reader

Comment by tracker1 | Hacker News Reader

Interesting to see how many of these types of tools are starting to be written in Rust. I think it's the structure that kind of lends itself to this type of thinking/work, with better performance than tooling in the scripted language(s). Similar to Rome.tools, was amazed at the performance difference from eslint and similar in the JS/TS space.

View on HN

I think this is because now one of the fastest languages is also safe. Before, the usual options for writing 'performant code' were usually C or C++, and even though modern C++ has better tools for memory management and safety, it was still scary to most people and you could still have some sort of memory bugs.

Now, we also have Rust in the performant side of things, and the guarantee that 'if compiles, it'll work' (aside from logic bugs), is quite a big one. Also, considering how helpful the compiler is, and the mentioned guarantees, more people are enthusiastic about having faster things.

I think it's less about safe, and more about Rust's other qualities. The language lends itself to writing parsers thanks to its syntax and zero-cost abstractions. Match expressions in particular made parsing a breeze when I last dabbled in writing compilers. The way it makes you think about memory management saves allocations you'd accidentally make in languages with GC. And it probably doesn't hurt that rust/cargo are nice tools that guide developers onto writing similar CLI experiences.

In short, it shines for this problem domain in my experience.

I agree, I should have phrased it as *I believe it's one of the reasons*. Developer ergonomics matters a lot, too. The compiler is incredibly helpful, it makes these kind of projects less scary to contributors too, and I agree that pattern matching is fun as hell.

Indeed. It's not far from eg Ocaml in this respect.

Lots of safe languages are close enough to C speed, like Ocaml, Go, many JVM languages (w Graal native image if fast startup is needed like here), Ada, Swift, etc. You can still have kinds of memory bugs in all of these incl Rust, esp leaks.

Well, in the JS space, also seeing tooling come out in Go as well (esbuild) so I don't think it's just Rust... I do think the story to get an executable to a given environment is quite a bit better for Go or Rust than say C# or JVM... Distributing tools in those languages feels dirty by comparison, even if containers make applications much cleaner (in terms of dist/usage).

Re distribution - for JVM, w GraalVM native image you can do that as well.

For example Babashka is distributed like that (https://github.com/babashka/babashka/releases)

It might been my ignorance but I haven't seen any tools written in JVM or Swift for these kind of scenarios, but I haven't looked too hard either.

I do think Go has have success in the same space because it is fast, but IMO the ergonomics in Rust for this problem space are a bit better. Of course, that's just my opinion.

> You can still have kinds of memory bugs in all of these incl Rust, esp leaks.

You're right. Leaks are not covered in the memory safety guarantees by Rust, neither are OOMs, but you can't deny you're on a way more safer space than with either C or C++.

The original Unix app philosophy was these piped C programs, right?

Just today I made a simple app in C translating text files to an array you could put in a .c-file, as a piped build tool with a small twist compared to xxd. I thought about doing it in Python first, but I realized it was way simpler to do in C. Both as a user and programmer.

I guess Rust have the same lure.

Reply on news.ycombinator.com