6 ms·

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

steveklabnik 11y ago
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.
- merlincorey 11y ago
  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.
  - steveklabnik 11y ago
    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?
    - merlincorey 11y ago
      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?
the_mitsuhiko 11y ago
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 https://github.com/getsentry/sentry-cli
im_down_w_otp 11y ago
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."
- thenewwazoo 11y ago
  Holy shit I hadn't even thought about writing NIFs in Rust. mind: blown.
- hansihe 11y ago
  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 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 :)
Perceptes 11y ago
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/ https://www.jimmycuadra.com/posts/the-highs-and-lows-of-rust...
lmm 11y ago
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.

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.

merlincorey 11y ago
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.
- steveklabnik 11y ago
  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?
  - merlincorey 11y ago
    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?

the_mitsuhiko 11y ago

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 https://github.com/getsentry/sentry-cli

im_down_w_otp 11y ago

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

thenewwazoo 11y ago
Holy shit I hadn't even thought about writing NIFs in Rust. mind: blown.
hansihe 11y ago
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 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 :)

Perceptes 11y ago

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/ https://www.jimmycuadra.com/posts/the-highs-and-lows-of-rust...

lmm 11y ago

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.