6 ms·

I completely agree. The biggest reason I haven't seriously tried Rust yet is because, despite all the vocal pro-Rust opinions we've all been inundated lately, I

I completely agree. The biggest reason I haven't seriously tried Rust yet is because, despite all the vocal pro-Rust opinions we've all been inundated lately, I struggle to name a single interesting thing about the language apart from "safety". I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very good reasons) and talk more about other aspects of their language. The tooling seems nice, but far from unique (D, Go and other languages are quite competitive there). It would be far more interesting to hear more about, say, traits (can it compete with C++ in compile time polymorphism?) and other technical aspects that make Rust stand apart from its competitors.

zerofan 10y ago
Rust did a nice job with algebraic data types. Haxe has a very similar approach, and I've loved it since I first saw it. I think this is a very elegant way to define data structures. I listed plenty of complaints about Rust in my other comment, but this one stands out as a "single interesting thing" worthy of praise.
twblalock 10y ago
> I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very good reasons) and talk more about other aspects of their language. Seriously. However, I've seen a lot of comments to that effect from C and C++ programmers who don't want memory safety. I come at it from a different angle: I'm a Java developer, so I already have memory safety. Pointer arithmetic, dangling pointers, and buffer overflows are not allowed, there is a garbage collector, and so on. In fact, most of the currently popular languages other than C and C++ are memory safe in similar ways. So, in terms of memory safety, Rust does not give me anything critical that I don't already have. When choosing among the memory-safe languages for a real-world project, I'm going to need a pretty compelling reason to choose Rust instead of Java, Scala, Go, Ruby, Python, etc. -- especially when it is so much easier to hire developers for more popular languages.
Manishearth 10y ago
I see a lot of folks talking about this, but I live in a Rust bubble. From my POV a lot of the folks using Rust use it for primary reasons other than memory safety; many could afford to use python or something and get away with it. I suspect there are fewer blog posts about this, however. I'll take a shot at some of the advantages: Algebraic datatypes: Seriously. These are amazing. C++ has them with Boost's variant (and now std::variant), but they're awkward to use, making them somewhat a niche instead of the very central place they take in Rust programming. Till now ADTs were mostly the domain of functional languages, so I'm very happy that Swift and Rust giving them first class support and making them essential. ADTs in Rust work with the enum keyword: enum Shape { Rectangle(Point, Point), Circle(Point, u32) } let some_shape = Circle(Point::new(1, 2), 5); match some_shape { // like switch, but with pattern matching Rectangle(p1, p2) => println!("Rect from {} to {}", p1, p2), Circle(p, radius) => println!("Circle at {} with radius {}", p, r) } An enum is essentially an "or" type; i.e. "a Shape is a Rectangle (X)OR a Circle". You are forced to handle this fact when you access this data -- if you try to access the stuff inside some_shape, you must match (or use a method that does this for you), and the match must be exhaustive (cover all cases). This is how null works in Rust -- if you want to say something is nullable, you use `Option<T>` -- `Some(T)` for when it's there and `None` for when it's null. You're forced to check for the none case if you want to be able to get to the inner data. You can call `.unwrap()`, but internally that's a method that just does a match and panics in the error case. Traits: I mention this elsewhere in the thread, but Rust metaprogramming via generics cannot and will never beat C++ TMP's level of expressivity. Rust is going to get procedural macros which make it easier to fill in that gap of metaprogramming in a less hacky way, but if you just compare generics and templates then templates can do a lot more. However, that's not necessarily a good thing. The way templates are structured; they basically get "monomorphized" at something akin to parse time. This means that the error messages can be atrocious, and an API can never be self-documenting since you have to explain what kinds of types can be passed in. On the other hand, in Rust, if you get a function from a library you can pretend that it's a black box. The error messages will never mention the contents of the box. You can adequately figure out how to not make the compiler error out by looking at the type signature. The way Rust traits work is that you first define them: trait Frob { fn frob(&self, frobbee: &str); } Then you implement them: impl Frob for SomeType { fn from(&self, frobbee: &str) { println!("{} frobs {}", self, frobbee) } } Now, you can write functions (or types, or methods, or whatever) which accept these: fn frob_something_10x<T: Frob>(frobber: T, frobbee: &str) { for _ in 1..10 { frobber.frob(frobbee) } } If I did not have the `T: Frob` bound, I would not be allowed to write this method; the compiler would say that type `T` doesn't have a frob method, and I'd be forced to add a bound that gives it one. If a library user passed the wrong type to the function, the compiler will tell them that their type doesn't implement Frob, at which point they can add an implementation or use a different type or whatever. It's a very nice, clear API separation which leads to clear error messages and makes it easier to figure out what kinds of types to use. It also means that in the autogenerated docs I can just click on the trait to find out what types I can feed to the function -- in C++ many codebases have their own bespoke "trait" system using template specialization but it won't work with the docs and still lends itself to rabbit-hole-y error messages. Moving: I personally find the lack of copy/move constructors and default construction to be very nice. In Rust, uninitialized types aren't a thing; initialization is always explicit. Copies are just copies, moves are also just copies, and moving is the default (except for POD types). There's no unknown overhead to deal with when I push to a vector, for example. Move-by-default and affine types IMO make it very easy to think about the program.
kazagistar 10y ago
Compared to a lot of C++ and other compile time polymorphism, the error messages are consistently excellent, if sometimes long, and some of this is due to the simplicity of traits. I am also extremely fond of pattern matching and algebraic data types (first class tagged unions). It is a style of data modeling borrowed from ML/Haskell and is quite distinct from OOP. The key distinction is that by making a datatype with multiple variants closed to extension, you can clearly see and handle all possible cases for a particular purpose (with checking from the compiler) which is often more natural then having fragments of implementation across many child classes.
mmstick 10y ago
You're only going to anger people by referring to another group as 'evangelists' when you yourself have already made note that you don't know enough about Rust to see why they are promoting it. There's much more to Rust than safety. You should actually spend a few months with it, and then give your opinion.
- shadowmint 10y ago
  I've used rust extensively and my opinion mirrors the parent comment precisely. Safety is a cool feature, but Rust is more than just safety, and pitching it as 'rust is safe' when it's not (and, often, it's not...) and when people dont care about that, doesn't convince people. There are a lot of people who blog about rust, and almost invariably the 'killer feature' they come up with is safety. It's not the killer feature; it's the side effect of strong memory management without a GC on an excellent general purpose programming language. We could certainly do with more posts about how great and practical rust is, what the state of rust tooling is, and what great rust libraries there are with no mention at all of safety. (... because safety is a cool technical feature; but the others; tooling, libraries and productivity are active barriers to adoption)
- tempodox 10y ago
  > ...you don't know enough about Rust to see why they are promoting it. If you have to know a lot about Rust to find out why you're using it in the first place, you certainly do have a chicken-or-the-egg problem. And, if the promotion doesn't leave you with a clear idea of why you might want to use Rust, that promotion couldn't have been very successful.
  - mmstick 10y ago
    The same is true of any technology. One cannot give an informed opinion without first being informed about the technology in the first place. Technology moves forward because there are many whom are willing to leave the comfort of their boxes into the unknown to try things without being required to be convinced.
- keldaris 10y ago
neandrake 10y ago
I've not seen it mentioned here (unless included under generic "safety"), but prevention of data races in concurrent code seems like a big thing for Rust. Most examples of Rust being "safe" compared to C are usually about buffer overflows use-after-free, but elimination of data races to me seems like a huge win in its own right. I'm primarily a Java developer and a lot of the practices I'm learning from Rust apply to how I think about implementations in regular work, such as aliasing and mutability.
Ar-Curunir 10y ago
> Memory safety is not a concern That is how we end up with the miserably insecure state of affairs of today :)
- keldaris 10y ago
  Except not everyone is writing software remotely relevant to security. If the goal is to market Rust as a niche language for the security-conscious, that's fine, but there seems to be a drive to show that it's a superior general programming language. The safety argument doesn't do that for most people.

zerofan 10y ago

Rust did a nice job with algebraic data types. Haxe has a very similar approach, and I've loved it since I first saw it. I think this is a very elegant way to define data structures. I listed plenty of complaints about Rust in my other comment, but this one stands out as a "single interesting thing" worthy of praise.

twblalock 10y ago

> I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very good reasons) and talk more about other aspects of their language. Seriously. However, I've seen a lot of comments to that effect from C and C++ programmers who don't want memory safety. I come at it from a different angle: I'm a Java developer, so I already have memory safety. Pointer arithmetic, dangling pointers, and buffer overflows are not allowed, there is a garbage collector, and so on. In fact, most of the currently popular languages other than C and C++ are memory safe in similar ways. So, in terms of memory safety, Rust does not give me anything critical that I don't already have. When choosing among the memory-safe languages for a real-world project, I'm going to need a pretty compelling reason to choose Rust instead of Java, Scala, Go, Ruby, Python, etc. -- especially when it is so much easier to hire developers for more popular languages.

Manishearth 10y ago

I see a lot of folks talking about this, but I live in a Rust bubble. From my POV a lot of the folks using Rust use it for primary reasons other than memory safety; many could afford to use python or something and get away with it. I suspect there are fewer blog posts about this, however. I'll take a shot at some of the advantages: Algebraic datatypes: Seriously. These are amazing. C++ has them with Boost's variant (and now std::variant), but they're awkward to use, making them somewhat a niche instead of the very central place they take in Rust programming. Till now ADTs were mostly the domain of functional languages, so I'm very happy that Swift and Rust giving them first class support and making them essential. ADTs in Rust work with the enum keyword: enum Shape { Rectangle(Point, Point), Circle(Point, u32) } let some_shape = Circle(Point::new(1, 2), 5); match some_shape { // like switch, but with pattern matching Rectangle(p1, p2) => println!("Rect from {} to {}", p1, p2), Circle(p, radius) => println!("Circle at {} with radius {}", p, r) } An enum is essentially an "or" type; i.e. "a Shape is a Rectangle (X)OR a Circle". You are forced to handle this fact when you access this data -- if you try to access the stuff inside some_shape, you must match (or use a method that does this for you), and the match must be exhaustive (cover all cases). This is how null works in Rust -- if you want to say something is nullable, you use `Option<T>` -- `Some(T)` for when it's there and `None` for when it's null. You're forced to check for the none case if you want to be able to get to the inner data. You can call `.unwrap()`, but internally that's a method that just does a match and panics in the error case. Traits: I mention this elsewhere in the thread, but Rust metaprogramming via generics cannot and will never beat C++ TMP's level of expressivity. Rust is going to get procedural macros which make it easier to fill in that gap of metaprogramming in a less hacky way, but if you just compare generics and templates then templates can do a lot more. However, that's not necessarily a good thing. The way templates are structured; they basically get "monomorphized" at something akin to parse time. This means that the error messages can be atrocious, and an API can never be self-documenting since you have to explain what kinds of types can be passed in. On the other hand, in Rust, if you get a function from a library you can pretend that it's a black box. The error messages will never mention the contents of the box. You can adequately figure out how to not make the compiler error out by looking at the type signature. The way Rust traits work is that you first define them: trait Frob { fn frob(&self, frobbee: &str); } Then you implement them: impl Frob for SomeType { fn from(&self, frobbee: &str) { println!("{} frobs {}", self, frobbee) } } Now, you can write functions (or types, or methods, or whatever) which accept these: fn frob_something_10x<T: Frob>(frobber: T, frobbee: &str) { for _ in 1..10 { frobber.frob(frobbee) } } If I did not have the `T: Frob` bound, I would not be allowed to write this method; the compiler would say that type `T` doesn't have a frob method, and I'd be forced to add a bound that gives it one. If a library user passed the wrong type to the function, the compiler will tell them that their type doesn't implement Frob, at which point they can add an implementation or use a different type or whatever. It's a very nice, clear API separation which leads to clear error messages and makes it easier to figure out what kinds of types to use. It also means that in the autogenerated docs I can just click on the trait to find out what types I can feed to the function -- in C++ many codebases have their own bespoke "trait" system using template specialization but it won't work with the docs and still lends itself to rabbit-hole-y error messages. Moving: I personally find the lack of copy/move constructors and default construction to be very nice. In Rust, uninitialized types aren't a thing; initialization is always explicit. Copies are just copies, moves are also just copies, and moving is the default (except for POD types). There's no unknown overhead to deal with when I push to a vector, for example. Move-by-default and affine types IMO make it very easy to think about the program.

kazagistar 10y ago

Compared to a lot of C++ and other compile time polymorphism, the error messages are consistently excellent, if sometimes long, and some of this is due to the simplicity of traits. I am also extremely fond of pattern matching and algebraic data types (first class tagged unions). It is a style of data modeling borrowed from ML/Haskell and is quite distinct from OOP. The key distinction is that by making a datatype with multiple variants closed to extension, you can clearly see and handle all possible cases for a particular purpose (with checking from the compiler) which is often more natural then having fragments of implementation across many child classes.

mmstick 10y ago

You're only going to anger people by referring to another group as 'evangelists' when you yourself have already made note that you don't know enough about Rust to see why they are promoting it. There's much more to Rust than safety. You should actually spend a few months with it, and then give your opinion.

shadowmint 10y ago
I've used rust extensively and my opinion mirrors the parent comment precisely. Safety is a cool feature, but Rust is more than just safety, and pitching it as 'rust is safe' when it's not (and, often, it's not...) and when people dont care about that, doesn't convince people. There are a lot of people who blog about rust, and almost invariably the 'killer feature' they come up with is safety. It's not the killer feature; it's the side effect of strong memory management without a GC on an excellent general purpose programming language. We could certainly do with more posts about how great and practical rust is, what the state of rust tooling is, and what great rust libraries there are with no mention at all of safety. (... because safety is a cool technical feature; but the others; tooling, libraries and productivity are active barriers to adoption)
tempodox 10y ago
> ...you don't know enough about Rust to see why they are promoting it. If you have to know a lot about Rust to find out why you're using it in the first place, you certainly do have a chicken-or-the-egg problem. And, if the promotion doesn't leave you with a clear idea of why you might want to use Rust, that promotion couldn't have been very successful.
- mmstick 10y ago
  The same is true of any technology. One cannot give an informed opinion without first being informed about the technology in the first place. Technology moves forward because there are many whom are willing to leave the comfort of their boxes into the unknown to try things without being required to be convinced.
keldaris 10y ago

neandrake 10y ago

I've not seen it mentioned here (unless included under generic "safety"), but prevention of data races in concurrent code seems like a big thing for Rust. Most examples of Rust being "safe" compared to C are usually about buffer overflows use-after-free, but elimination of data races to me seems like a huge win in its own right. I'm primarily a Java developer and a lot of the practices I'm learning from Rust apply to how I think about implementations in regular work, such as aliasing and mutability.

Ar-Curunir 10y ago

> Memory safety is not a concern That is how we end up with the miserably insecure state of affairs of today :)

keldaris 10y ago
Except not everyone is writing software remotely relevant to security. If the goal is to market Rust as a niche language for the security-conscious, that's fine, but there seems to be a drive to show that it's a superior general programming language. The safety argument doesn't do that for most people.