5 ms·

Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the begi

Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.

kbenson 11y ago
As someone who's been following the hype, but not really jumped on yet, the difference (whether real or imagined) seems to be that rust is trying to do something new, and D looks to be (and I've seen it aggressively marketed as) C++ with some better choices and cool features. Personally, I'm not really interested in C++, but I am interested in getting for familiar with a systems language, so rust interests me.
- sdegutis 11y ago
  From what I understand, the only new thing Rust is contributing is managed lifetimes. Everything else is, like in D, just borrowed from other languages and put together. That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet.
  - kbenson 11y ago
    I think of it like this: If I'm going to manually be managing memory, I might as well get some real gain for that effort. Provably correct memory management through an ownership system sounds like it might be worth the effort, especially if it might also help in situations with threading. I've had reason to use threads quite a bit in the past.
  - steveklabnik 11y ago
    > lifetimes are still too young While some stuff is new, the core of the idea goes back to Cyclone in 2001.
  - destructionator 11y ago
    D's new things have been more accidental than by design... and kinda subtle too. Like the compile time reflection. I'm sure someone else has done it somewhere before, but D makes it really easy.
  - pcwalton 11y ago
    > That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet. Not in my experience. I wrote tons of safe Rust every day and I really enjoy not having to worry about difficult-to-debug crashes, undefined behavior, and security problems.
  - Manishearth 11y ago
    > just borrowed from other languages and put together. Most of these things are new to the systems space, though. Things like algebraic data types, etc. Also usable affine types. > lifetimes are still too young to be worth the trouble. I've heard pretty much the opposite. Firstly, nobody who uses Rust calls the feature "lifetimes" (it's usually called borrowing or borrow checking). That's the name of the syntax, and while the syntax is new and somewhat confusing it doesn't pop up that much thanks to elision. Borrowing has a learning curve, yes. But really, it's an equivalent set of principles to what you would do in C++ to keep your pointers safe. The difference is that you can write small C++ codebases without worrying about "C++ borrowing", whereas you need to think about these things off the bat in Rust.
    - detrino 11y ago
      > it's an equivalent set of principles to what you would do in C++ to keep your pointers safe. The things you can prove statically with the borrow checker are a subset of the things that wont trigger UB in C++.
      - Manishearth 11y ago
        That doesn't contradict what I said. My point was: If you're working on a large C++ codebase you will have to reason roughly about who owns what and where your pointery data is coming from. IME it amounts to (roughly) the same thing as Rust's borrowck rules, just that Rust forces you to think about this a priori, in a clean framework with clear rules, instead of wibbly wobbly, pointy-wointy, ... stuff. The things you feel safe to do in Rust are often a superset of the things you feel safe to do in C++. Most large codebases often use lots of shared_ptr or equivalent, whereas in Rust Rc and RefCell are broken out only when necessary (when the compiler tells us there's no way to do it the borrow way). So while C++ might let you write a larger variety of non-UB patterns in principle, Rust will let you write more non-UB patterns in practice. You feel safe playing fast and loose with the references, and dancing near the line of safe behavior since the compiler ensures you never cross it. I have a post illustrating an example of this here: http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ http://manishearth.github.io/blog/2015/05/03/where-rust-real... And, of course, if you really want to express one of those "things C++ lets you do" wrt pointers, you can always break out `unsafe`.
epoch1970 11y ago
Rust inherited the enthusiasm of some very prominent and outspoken members of the Ruby community. These ex-Rubyists honed the craft of projecting excitement with Ruby and RoR, and brought these skills and talents with them when they moved to the Rust camp. The D camp hasn't really had anyone like that join them.
- jguegant 11y ago
  I have to agree on this. I was surprised to see that a majority of the Rust community actually comes from some web-development domains. Especially when comparing Ruby, a highly flexible dynamic language, to Rust a language full of constraints (for its own valid reasons). Note that the a hype train is a two-edged sword, it will both bring a strong community and might also induce a cliff with the other communities (praising a single god is never a good thing).
  - kbenson 11y ago
    An alternative interpretation might be that rust has particular appeal to those that primarily use dynamic languages. It's probably both, but I will say that as someone that's busy getting stuff done in Perl[1] every day, rust looks appealing, and a lot of that has to do with guarantees. If I'm going to give up the convenience of Perl for a lower level language[2], I need to be sold. Rust's promise of provably correct memory management sounds really good in that situation. 1: I've used lower level languages, but for nothing large, and I haven't started a project in C, C++ or even Java in over a decade, and was never very enamored.
  - steveklabnik 11y ago
    As someone who fits this mould, for me, it's not exactly that. Yes, in my professional life, people know me for my Rails work, but I learned C at a very young age, and while my systems-level stuff was a bit out of practice, for me, Rust is a _return_ to the kind of stuff I used to do earlier in life. Oh, and I'm not sure "majority" is really true. Yeah, maybe some of us have disproportionate impact, but a very large number of people in Rust-land really know their systems stuff. I am humbled to work alongside such talented people.
wyldfire 11y ago
I think I'm climbing aboard the hype train. The thing that made a difference for me was the lack of GC. I knew I could have an easier time selling that to my team than GC. As soon as they hear 'GC' they will probably start to think of unacceptable latencies and lump D in with Java, Python (et al). That said, D's compatibility with C++ is a big plus.

Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.

kbenson 11y ago

As someone who's been following the hype, but not really jumped on yet, the difference (whether real or imagined) seems to be that rust is trying to do something new, and D looks to be (and I've seen it aggressively marketed as) C++ with some better choices and cool features. Personally, I'm not really interested in C++, but I am interested in getting for familiar with a systems language, so rust interests me.

sdegutis 11y ago
From what I understand, the only new thing Rust is contributing is managed lifetimes. Everything else is, like in D, just borrowed from other languages and put together. That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet.
- kbenson 11y ago
  I think of it like this: If I'm going to manually be managing memory, I might as well get some real gain for that effort. Provably correct memory management through an ownership system sounds like it might be worth the effort, especially if it might also help in situations with threading. I've had reason to use threads quite a bit in the past.
- steveklabnik 11y ago
  > lifetimes are still too young While some stuff is new, the core of the idea goes back to Cyclone in 2001.
- destructionator 11y ago
  D's new things have been more accidental than by design... and kinda subtle too. Like the compile time reflection. I'm sure someone else has done it somewhere before, but D makes it really easy.
- pcwalton 11y ago
  > That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet. Not in my experience. I wrote tons of safe Rust every day and I really enjoy not having to worry about difficult-to-debug crashes, undefined behavior, and security problems.
- Manishearth 11y ago
  > just borrowed from other languages and put together. Most of these things are new to the systems space, though. Things like algebraic data types, etc. Also usable affine types. > lifetimes are still too young to be worth the trouble. I've heard pretty much the opposite. Firstly, nobody who uses Rust calls the feature "lifetimes" (it's usually called borrowing or borrow checking). That's the name of the syntax, and while the syntax is new and somewhat confusing it doesn't pop up that much thanks to elision. Borrowing has a learning curve, yes. But really, it's an equivalent set of principles to what you would do in C++ to keep your pointers safe. The difference is that you can write small C++ codebases without worrying about "C++ borrowing", whereas you need to think about these things off the bat in Rust.
  - detrino 11y ago
    > it's an equivalent set of principles to what you would do in C++ to keep your pointers safe. The things you can prove statically with the borrow checker are a subset of the things that wont trigger UB in C++.
    - Manishearth 11y ago
      That doesn't contradict what I said. My point was: If you're working on a large C++ codebase you will have to reason roughly about who owns what and where your pointery data is coming from. IME it amounts to (roughly) the same thing as Rust's borrowck rules, just that Rust forces you to think about this a priori, in a clean framework with clear rules, instead of wibbly wobbly, pointy-wointy, ... stuff. The things you feel safe to do in Rust are often a superset of the things you feel safe to do in C++. Most large codebases often use lots of shared_ptr or equivalent, whereas in Rust Rc and RefCell are broken out only when necessary (when the compiler tells us there's no way to do it the borrow way). So while C++ might let you write a larger variety of non-UB patterns in principle, Rust will let you write more non-UB patterns in practice. You feel safe playing fast and loose with the references, and dancing near the line of safe behavior since the compiler ensures you never cross it. I have a post illustrating an example of this here: http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ http://manishearth.github.io/blog/2015/05/03/where-rust-real... And, of course, if you really want to express one of those "things C++ lets you do" wrt pointers, you can always break out `unsafe`.

epoch1970 11y ago

Rust inherited the enthusiasm of some very prominent and outspoken members of the Ruby community. These ex-Rubyists honed the craft of projecting excitement with Ruby and RoR, and brought these skills and talents with them when they moved to the Rust camp. The D camp hasn't really had anyone like that join them.

jguegant 11y ago
I have to agree on this. I was surprised to see that a majority of the Rust community actually comes from some web-development domains. Especially when comparing Ruby, a highly flexible dynamic language, to Rust a language full of constraints (for its own valid reasons). Note that the a hype train is a two-edged sword, it will both bring a strong community and might also induce a cliff with the other communities (praising a single god is never a good thing).
- kbenson 11y ago
  An alternative interpretation might be that rust has particular appeal to those that primarily use dynamic languages. It's probably both, but I will say that as someone that's busy getting stuff done in Perl[1] every day, rust looks appealing, and a lot of that has to do with guarantees. If I'm going to give up the convenience of Perl for a lower level language[2], I need to be sold. Rust's promise of provably correct memory management sounds really good in that situation. 1: I've used lower level languages, but for nothing large, and I haven't started a project in C, C++ or even Java in over a decade, and was never very enamored.
- steveklabnik 11y ago
  As someone who fits this mould, for me, it's not exactly that. Yes, in my professional life, people know me for my Rails work, but I learned C at a very young age, and while my systems-level stuff was a bit out of practice, for me, Rust is a _return_ to the kind of stuff I used to do earlier in life. Oh, and I'm not sure "majority" is really true. Yeah, maybe some of us have disproportionate impact, but a very large number of people in Rust-land really know their systems stuff. I am humbled to work alongside such talented people.

wyldfire 11y ago

I think I'm climbing aboard the hype train. The thing that made a difference for me was the lack of GC. I knew I could have an easier time selling that to my team than GC. As soon as they hear 'GC' they will probably start to think of unacceptable latencies and lump D in with Java, Python (et al). That said, D's compatibility with C++ is a big plus.