Hacker News Reader

Comment by Kratisto | Hacker News Reader

So I don't know a whole lot about Rust. Can anyone give a summary of why/when I should use Rust?

Someone asked a similar question on /r/rust the other day, here's what I had to say:

Rust is a programming language. It's a general programming language, so it's good for a large variety of things. Different people have different reasons for using Rust. There are three large constituencies, as I see them: systems programmers, functional programmers, and scripting language programmers.

Before I get into details: all generalizations are false ;)

Systems programmers come to Rust because it's able to do the lowest levels of software: operating systems, device drivers, stuff like that. Where it improves on existing systems languages is "safety." The Rust compiler does a lot of compile-time checking to make sure you don't do things wrong. Existing languages force you, as the programmer, to double check your work. We have the compiler double-check your work, and force you to get it right.

Functional programmers see all that static checking, and it feels like home. But a home where they have significant speed gained. Functional languages can be fast, but not always C level fast. Rust is. It's easier to get that level of performance out of Rust.

Scripting language programmers come to Rust for two reasons: the first of which is to write extensions to their language for speed. You can write a Ruby gem in Rust, rather than in C. This is useful because this low-level stuff is not their expertise, and so the extra checks are really nice. Related: we have a lot of the nice tooling that scripting language folks have come to expect from their language. No need to write makefiles, we have Cargo. The second is sort of related, but these checks also mean it's easier to learn low-level stuff, so if they want to expand their universe, Rust is a nice way to do so. We're seeing a lot of people for whom Rust is their first systems language.

I didn't know where to put this one, but Rust focuses on a concept called "zero-cost abstractions." This means that a lot of our features that feel very high level are extremely efficient. You don't write manual for loops, you se iterators. You don't deal with pointers directly, but with references. Structures like Box and Vec do memory management, but you don't need a garbage collector, and you don't need to manually manage it, but you also don't need to explicitly call free().

These are very broad strokes. Lots of other people have other reasons too. But that's some of them.

Thank you for your insight. I have but one question.

What does Cargo the rust package management tool have to do with make, the declarative build system? It would seem they are unrelated to an outsider such as myself.

Part of managing packages is how those packages are actually built. For example, let's say that I'm starting a project in C. I'd write some code, and write a makefile to make it easier to build, so that just a 'make' suffices. In Rust, you use Cargo instead of make: "cargo new foo" will give you a Cargo.toml pre-filled, and a src directory to put your code in. "cargo build" will then build your project.

Work goes on, and how I want to use, say, a library for a hashmap of some kind. In my C project, I would probably be adding a git submoule, and then modifying my make files to build the dependency, and configure how to link it in with my code. With Cargo, I add a line to my Cargo.toml, and "extern crate bar" to my source file, and upon the next "cargo build", Cargo will handle the downloading, compiling, and linking of that library, as well as any sub-dependencies it has.

Now, it's also true that make is broadly more general than Cargo, and so in some circumstances, you'll use them together. I have a hobby OS project, for example, and so I have a Makefile which calls nasm to compile the assembly, cargo to compile the Rust, and ld to link the two together. Eventually, I would hope that Cargo can do it all, and I could probably make it work, but it's not inherently bad to use make either. Stuff like operating systems are the only case where I've felt that need; Rust itself is currently built with Make, because it pre-dates Cargo, but we're in the process of cargo-ifying our build as well.

Does that make sense?

Yes thank you for the clarification. I have been mostly pleased with the things I've seen and heard from the rust community and I really should dive in.

I am pleased to hear that Cargo, rather than attempting to be a rust-specific make replacement, is a tool that obviates the need for using make or make-like tools by automating the things you would have used it for, only.

Make and Cargo together sounds like just what I wanted to hear, and your hobby OS project sounds like fun.

Finally, I think it's great that Rust will be using Cargo itself soon, but I am curious if the reverse is possible -- if I want to put in the extra effort, can I build my own rust software in make alone WITHOUT Cargo?

You can absolutely use Rust without Cargo, you'd just call `rustc` yourself directly.

That's just what I wanted to hear!

Thanks again.

To elaborate on Steve's comment, Cargo fundamentally operates by calling rustc itself. You can pass the `--verbose` flag to Cargo to see the commands that it generates.

A lot of scripting language folks I've talked to like Rust not because it lets them write extensions or whatever, but because static typing is awesome (and their use case works perfectly well with Rust as much as it does Python). In the static typing world, C++ has its own set of problems (namely, having to worry about pointers), and there's not much love for Java amongst some communities. Both Rust and Go provide an interesting new alternative here. Some extra static typing and free speed; sign me up!

I feel like for many of those people something like OCaml/Haskell/F#/Scala (which have been around for many years) would be better options. It's very rare to actually need the very last ounce of performance you get by moving to a non-GC language compared to a fast typed GCed language, whereas there is a real cost to having to manage object lifetimes in Rust.

> there is a real cost to having to manage object lifetimes in Rust.

I disagree. For the most part, you don't have to worry much about lifetimes in Rust once you have programmed in the language for a bit. It's a learning curve, like any other (functional languages have their own learning curve). There are cases now and then when you do have to think about it, but mostly it's either quickly fixing mistakes caught by the compiler (like any other type error, and this reduces as time goes by), or writing the correct code from the get-go.

That doesn't make Rust a better choice than the functional languages, but it certainly doesn't make it worse.

(of course, there are other reasons as to why Haskell/etc might be a better option for these people)

This is a really excellent summary, I think it really says a lot more than the previous summaries I've heard which put a lot of emphasis on the safety bit. That is of course a very important aspect, but I feel like over emphasising it sells Rust short. I'm most excited about it for parts 2 and 3, part 1 is just a bonus.

Thanks. It's easy to get lost in the safety bit, because from a PLT perspective, it's the most interesting. But there's a lot more going on.

Sean Griffin, the current maintainer of ActiveRecord, has been writing an ORM in Rust. He specifically has been saying quite a bit that the safety aspect is almost irrelevant to him, he sees Rust as a "practical Haskell".

It's also true that there's a lot of stuff we have that's _because_ of safety but isn't interesting because of safety. For example, memory safety is at the core of our concurrency story, but the end result is "compile-time errors for concurrency bugs", which is much more interesting than "safety".

TL;DR: marketing is difficult. Messaging is tough.

Where do Java, Go and C# programmers fall? Perhaps just more on the order of more complexly implemented and designed scripting languages? Those three make up a good swath but systems, functional and scripting don't so map well to those.

Rust excels in writing fast and efficient libraries that are portable and caller-agnostic. Java, C# and Go all have GC-endowed runtimes, so they might fare not as well on that field.

On the other hand, GC allows for faster and easier programming without the need to reason about lifetimes, like you would have to do in non-GC-languages like C and Rust. Java, Go and C# are fast enough to do a lot better than scripting languages, plus they are statically typed and safe.

I think that what Rust provides for user of those languages, has more limited scope: mainly squeezing the last drops of perf, and especially doing some realtime programming.

Edit: One additional pro of Rust is that it managed resources like files and sockets very robustly with its type system, which may help prevent bugs. That's a thing CG won't do for you.

You might like https://llogiq.github.io/2016/02/28/java-rust.html

TL;DR: Java is awesome, Rust is awesome, let's code even more awesome stuff!

Thank you for the summary!

You're very welcome.

I'd say Rust is a generically sensible language, in terms of the modern state of the art of language design (that is to say, it has a powerful but lightweight type system and is designed in ways that are amenable to writing correct programs) - this sounds like a low bar but is surprisingly rare (at least for a language that qualifies as at all mainstream). Distinctive things are that it compiles to native code and has manual but safe memory management (i.e. you have to tell it what the lifetimes of your values are, unlike a garbage-collected language, but you'll get compilation errors if you do it wrong, rather than silent memory leaks or crashes).

It's a reasonable first choice for when you absolutely need to avoid GC, or need code without a runtime (e.g. for embedding into another language). IMO a lot of people overestimate their performance requirements though (or assume that all GC languages must be as slow as Python/Ruby, or as slow to start as Java), and would be more productive overall writing in a language that doesn't require manual memory management and then spending a little time profiling. So for general-purpose programming where the target is native code I would recommend starting with OCaml or Haskell (if VM languages are suitable then also consider F# or Scala), and only falling back to Rust if you've spend a bit of time profiling and optimizing your app (or a representative benchmark/example) and find you really can't get the performance you absolutely need.

I started using it for distributable command line executables. It compiles everything into a single binary and is easy to deal with. The upcoming sentry command line executable uses it for instance: https://github.com/getsentry/sentry-cli

I've been slowly iterating toward building "safe" abstractions around the Erlang NIF interface in Rust, because a broken NIF can bring down the entire BEAM VM, and I very, very much want to have the kinds of compile-time safety checks that Rust provides me when writing NIF modules for Erlang software.

For me it's become, "Anywhere I would use or have to directly interface with C; evaluate using Rust instead."

I have been working on a project for writing safe NIFs in Rust. I feel like I have the rough details of the API sketched out, but there is still work to do. https://github.com/hansihe/Rustler

There are still some rough edges on it, and if you see any obvious improvements, I would be more than happy to take suggestions or push requests :)

Holy shit I hadn't even thought about writing NIFs in Rust.

mind: blown.

I wrote a post recently that gives a summary of my experience with the language so far and attempts to answer why and when someone should use it: https://www.jimmycuadra.com/posts/the-highs-and-lows-of-rust...

Reply on news.ycombinator.com