3 ms·
I've recently attended a conference where they gave a D talk, and almost immediately after a Rust talk. This let me compare these two interesting languages in
by knocte 12y ago
I've recently attended a conference where they gave a D talk, and almost immediately after a Rust talk.
This let me compare these two interesting languages in a quite detailed way.
While Rust seems to be more safe in terms of trying to prevent as much as it can that you shoot yourself in the foot, it can be understood that the way to achieve this is maybe too extreme. I've read that programmers new to this language invariable struggle with lifetime issues that the compiler keeps arising.
I'm sure this is a good thing. But I'm not sure the ways to fix those issues, at least in a number of examples I've seen, are pretty. Most of them involved abusing the "*" and "&" symbols, which put you in a territory in which you seem to be dealing with pointer arithmetic again like in low-level C, something which I thought Rust was trying to escape from.
One thing I really liked about D is the string mixins, which could allow for what has become common these days in F#: type generation at compile time (which at the end of the day allow you to, for example, parse XML or JSON with static APIs, hence allowing intellisense/codeCompletion/youNameIt).
I'm really excited about what these kind of high&low (hybrid) level languages will allow. I hope they get into mainstream soon, and surpass other less interesting (but trendy) ones like Go.
- pcwalton 12y ago> Most of them involved abusing the "∗" and "&" symbols, which put you in a territory in which you seem to be dealing with pointer arithmetic again like in low-level C, something which I thought Rust was trying to escape from. First off, Rust doesn't have pointer arithmetic. Moreover, though, Rust is not trying to "escape from" pointers in C and C++; it's a manually memory-managed language, not a garbage-collected one. For Rust's domain (systems programming without automated memory management), learning about pointers is a necessity. What Rust saves you from is making dangerous mistakes with memory management. > One thing I really liked about D is the string mixins, which could allow for what has become common these days in F#: type generation at compile time (which at the end of the day allow you to, for example, parse XML or JSON with static APIs, hence allowing intellisense/codeCompletion/youNameIt). Rust has macros and compiler plugins, which allow you to do the same thing.
- knocte 12y ago>First off, Rust doesn't have pointer arithmetic. It should have avoided the "*" and "&" symbols then, IMNSHO. C# does this partially by using the "ref" keyword.
- pcwalton 12y ago> It should have avoided the "∗" and "&" symbols then, IMNSHO. Those operators aren't for pointer arithmetic… > C# does this partially by using the "ref" keyword. But C#'s reference parameters have no corresponding dereference operator, because they aren't first class and are limited to function parameters. As a result, most programs cannot be written without using the garbage collector in C#. In Rust, however, references can appear as first-class values, which makes them much more flexible—enough to supplant a garbage collector when combined with smart pointers—but requires that you annotate where they are created. `&` and `*` are well-known operators for this.
- knocte 12y ago> Those operators aren't for pointer arithmetic… That's the point of my suggestion! One looking at them will think they are pointer arithmetic, which is not pretty for newcomers.
- pcwalton 12y agoThose operators aren't for pointer arithmetic in any language I know of, including Rust, C, C++, or Go. The operators for pointer arithmetic are plus and minus (technically square brackets too in C)--that's why it's called pointer arithmetic.
- knocte 12y agoOk sorry, I misused the term "pointer arithmetic" then. I think I was referring to memory indirection and the like. I find "ref" and "->" less cryptic than "&" and "*".