6 ms·

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 t

by etra0 4y ago

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.

onei 4y ago
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.
- etra0 4y ago
  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.
- fulafel 4y ago
  Indeed. It's not far from eg Ocaml in this respect.
fulafel 4y ago
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.
- tracker1 4y ago
  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).
  - fulafel 4y ago
    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 https://github.com/babashka/babashka/releases)
- etra0 4y ago
  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++.

by etra0 4y ago

onei 4y ago

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.

etra0 4y ago
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.
fulafel 4y ago
Indeed. It's not far from eg Ocaml in this respect.

fulafel 4y ago

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.

tracker1 4y ago
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).
- fulafel 4y ago
  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 https://github.com/babashka/babashka/releases)
etra0 4y ago
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++.