19 ms·

Comparison between Rust and D

77 points by dumindunuwan 10y ago

jpgvm 10y ago
This is really neat. I have dabbled in Rust and have been meaning to go back and look at D. The other linked posts regarding meta-programming features of D are also great.
nachtigall 10y ago
Says not much about garbage collection: Rust does not need one, D (at least its stdlib) needs it. How about Nulls or concurrency? Seems to go very much into details about syntax bike shedding but not saying much about the more "global" design differences.
- qznc 10y ago
  There one big issues, where I think D might make progress: Combine GC and non-GC in a single application. This would be great for game programming for example. Handle audio and video in a soft-real-time non-GC thread. Handle other stuff like game logic in a GC thread, such that it is easier to write. The hard part is that GC usually requires stop-the-world. You can currently do this [0] in D, but it is error prone. Rust tackles this problem from the "other side": First make it safe, then possible. [0] https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread https://p0nce.github.io/d-idioms/#The-impossible-real-time-t...
  - Manishearth 10y ago
    > Combine GC and non-GC in a single application. Rust is actively working on this, in fact. The idea is to eventually have a Gc<T>-like type, like Rc<T>, which can be used on specific things. It will interact fine with the regular heap, so `Vec<Gc<Foo>>` where `Foo` contains a `Box<Gc<T>>` will still work. You can then selectively apply this Gc<T> to things which need it. For example if you have a large graphy-datastructure in your code and don't want to bother with weak pointers. Or if you are doing FFI with a language that does have GC. Rust itself would not have the Gc<T> type in the stdlib, it would only contain a couple of traits and compiler intrinsics that are useful for a GC. (The idea is to be able to turn on LLVM stack maps and use it for GC rooting). So you can write a gc for your specific use case (even if that use case is just safe bindings to a different GC from a runtime you are interacting with!) and it should work. In fact, in the design so far it seems like multiple GC implementations will be able to exist in the same application, and perhaps even safely interact (you can control whether you want this to be possible using the type system; I'm not sure if there is ever a case where this would be needed) This would of course, still be safe. It would not be possible to violate GC invariants using safe code, nor would it be possible for the GC to violate regular safety invariants.
    - bluejekyll 10y ago
      My biggest concern with the Gc ideas floating around Rust right now is that they may infect your program through dependencies. I guess I'm mostly worried about Gc being used by a large number of libraries, to the extent that it might not matter if stdlib implements it or not, because by using some very popular library you'd end up pulling in this runtime dependency. Part of me loves the flexibility this will bring to application design, but it could be a slippery slope.
      - kibwen 10y ago
        If such a popular GC-using dependency came into existence, then there would surely be demand for a drop-in replacement that didn't use GC. Remember, even the proposed Gc<T> type provides very little in the way of ergonomics (at least compared to garbage-collected types in pervasively-GC'd languages). Essentially it would just be a souped-up Rc<T> with no need for weak pointers to resolve cycles. Alternatively, it would only be used to interoperate with a foreign codebase that already uses GC, like SpiderMonkey or V8. Given that people tend to only be writing Rust in the first place if they put a large degree of value on performant solutions, I'm not too worried about the library ecosystem suddenly sneaking in GC everywhere, especially since the Rc type is already halfway to garbage collection, and I don't see it used unduly in the wild.
      - Manishearth 10y ago
        It's not going to be something considered idiomatic, especially in a library. Rust support quite a few things which you're not supposed to use other than in exceptional circumstances (e.g. catching/recovering panics -- there has been no slippery slope yet). Nor will the stdlib expose a GC API. I do intend on writing an example GC for this, but really each use case will probably need its own special GC implementation; since they are special use cases. That's not a decision to take lightly. I don't think GC will be something that can be silently pulled in, either, since you will need to change your codegen flags at the top level. This could be abstracted away by cargo, but it might be better if it wasn't; and you have to explicitly tell cargo in the toplevel toml file that you want GC to be on (and get a compile error if you try to compile without those flags). ================== Also, the Rust community seems to be very careful about unnecessary costs. Even Rc<T> isn't used much, and when it is, it seems to be used at the application (not library) level. When I have to box a closure or iterator in Rust because `-> impl Trait` doesn't exist (where you can return anonymous types by specifying the trait they implement), I feel so annoyed by the cost. As do many other Rustaceans. In reality, this is a pretty rare thing to do and the costs are negligible; but it feels annoying to not have the best performance. In such an environment, I doubt a library that frivolously uses GC will survive.
  - pcwalton 10y ago
    Servo is doing this today in Rust, so it's quite possible. (It would be better with native language integration, and this is an area of current work.)
  - Cyph0n 10y ago
    Nim does this already.
programLyrique 10y ago
I'd really like to have type-level numbers natively in Rust. Implementing a vector generic on its dimensions seems to be so much easier in D! Any prospect about that?
- bjz_ 10y ago
  There is definitely a prospect! The core team understands the need. It still needs an RFC though, and once that is accepted it will have to make its way from nightly, to beta, then finally to stable. So alas, not any time soon. :(
  - yberreby 10y ago
    There's an RFC that could address the lack of type-level integers: https://github.com/rust-lang/rfcs/pull/1657 https://github.com/rust-lang/rfcs/pull/1657
    - bjz_ 10y ago
      Oh duh, I forgot about that - even commented on a few days ago!
teamhappy 10y ago
I think the section about immutability should mention that this is possible in Rust: fn main() { let x = true; let x = false; } I was pretty disappointed when I found out about it.
- eudox 10y ago
  Those are two different bindings. That is, fn main() { let x = true; { let x = false; } } Since you don't use let for assignment, it's a non-problem. And it can be useful when you're doing some computation where you want to keep intermediate variables (for debugging or clarity), and rather than think of the proper name for each, you just successively bind the same name.
  - sixbrx 10y ago
    Very useful indeed when you want a canonical or corrected (or otherwise "improved") version of a value and want to make sure that the original can't accidentally be used in what follows (which can be a hard to detect bug).
    - eudox 10y ago
      Yes, a common refinement pattern in code is (pseudocode): def fn(object): let object = predicate(object) ? modify(object) : error(); // do something with the refined object Or something along those lines.
  - teamhappy 10y ago
    I know a lot of people really like shadowing. I obviously don't. GHC has an option to emit a warning and if Rusts compiler adds one for it as well (maybe it has one by know? I don't know) I guess I'm okay with it.
    - steveklabnik 10y ago
      Clippy has a lint, but it's not turned on by default, even in Clippy.
d33 10y ago
I'm getting the impression that D is a failure. Is there any bigger project written in it? If not, why would it fail?
- qznc 10y ago
  Companies using it: https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html Weka explicitly says "over 200K LoC"
- Manishearth 10y ago
  People use D, and it is a pretty decent language. I'm not an avid D user, but I have a guess as to why it is not so widely used. To me, D is somewhat of a "I like C++s features and ergonomics and want a similar languages with all the features built in from the ground up" (+awesome metaprogramming). One of C++s drawbacks is that features have been bolted on in hacky ways due to backwards compatibility issues. D is like C++, but without this. It is a good goal, and from my limited experience with D I think they have achieved it well. Thing is, such a language will largely be adopted by people who use C++. And the problem with these folks is that they already know C++. Once you are used to it it doesn't feel so bad. Despite its drawbacks, C++ has lots of tooling, a large ecosystem, and familiarity. Rust is less affected by this for two reasons. One is that it gets a lot of production users from non-C++ shops who want to use a systems language to speed up their Python/etc tight loops. They would rather not worry about segfaults and stuff. The other is that for C++ users, Rust scratches a large itch. The learning curve for Rust is a lot worse than D, but for many the benefits might overcome this. You can't get used to segfaults the way you get used to template metaprogramming. I would give D time. These issues just slow adoption, not stop it. That is fine.
scotty79 10y ago
Another language you might consider is Nim which is more like D because it doesn't have specific selling point like Rust. It's very flexible and reasonable though and Python programmers will feel there immediately at home. You have GC there but you might opt out of it and/or let it run at specific times and for specific amount of time to manage gc pauses.
Const-me 10y ago
This article only covers the code. For the projects I work on (mostly C++ and/or C#), about 50% of decisions I make while coding is about data, not code. IMO, Rust just not good enough for creating complex specialized data structures. Even a trivial tree is hard to implement in Rust, and the implementation will be severely limited: https://github.com/SimonSapin/rust-forest https://github.com/SimonSapin/rust-forest D surely has it’s problems as well (in short, I think the language itself is very good, but its runtime and libraries still need a lot of work), but at least it’s good for complex data structures.
- steveklabnik 10y ago
  Yes, internals of data structures often need unsafe. At least with Cargo, and generics, you can implement them once, and then share them amongst projects. It's also why we have a fair number of data structures in the standard library; they will be audited a bit more heavily this way.
  - bluejekyll 10y ago
    unsafe in Rust == telling the compiler I know what I'm doing here, so eff off. Other languages do this too, for instance in Java you can override final with reflection. I lost my mind, both good and bad, when I discovered this.
    - steveklabnik 10y ago
      But only in a controlled way. Unsafe doesn't change the semantics of existing code, it only adds the ability to do a few extra things. So you're still going to get a lot of safety checks, even within an unsafe block. You still have to be careful, but it's not no-holds-barred.
      - bluejekyll 10y ago
        Yeah. I've read your chapter on this repeatedly, and then the Rustinomicon, both hugely useful, but so far all I've done is use of for Rust -> C bindings and vice versa. It's taken me a year to feel good about my Rust code, I'm still getting a handle on unsafe though.
yarrel 10y ago
Rust: people use. D: people don't.

77 points by dumindunuwan 10y ago

jpgvm 10y ago

This is really neat. I have dabbled in Rust and have been meaning to go back and look at D. The other linked posts regarding meta-programming features of D are also great.

nachtigall 10y ago

Says not much about garbage collection: Rust does not need one, D (at least its stdlib) needs it. How about Nulls or concurrency? Seems to go very much into details about syntax bike shedding but not saying much about the more "global" design differences.

qznc 10y ago
There one big issues, where I think D might make progress: Combine GC and non-GC in a single application. This would be great for game programming for example. Handle audio and video in a soft-real-time non-GC thread. Handle other stuff like game logic in a GC thread, such that it is easier to write. The hard part is that GC usually requires stop-the-world. You can currently do this [0] in D, but it is error prone. Rust tackles this problem from the "other side": First make it safe, then possible. [0] https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread https://p0nce.github.io/d-idioms/#The-impossible-real-time-t...
- Manishearth 10y ago
  > Combine GC and non-GC in a single application. Rust is actively working on this, in fact. The idea is to eventually have a Gc<T>-like type, like Rc<T>, which can be used on specific things. It will interact fine with the regular heap, so `Vec<Gc<Foo>>` where `Foo` contains a `Box<Gc<T>>` will still work. You can then selectively apply this Gc<T> to things which need it. For example if you have a large graphy-datastructure in your code and don't want to bother with weak pointers. Or if you are doing FFI with a language that does have GC. Rust itself would not have the Gc<T> type in the stdlib, it would only contain a couple of traits and compiler intrinsics that are useful for a GC. (The idea is to be able to turn on LLVM stack maps and use it for GC rooting). So you can write a gc for your specific use case (even if that use case is just safe bindings to a different GC from a runtime you are interacting with!) and it should work. In fact, in the design so far it seems like multiple GC implementations will be able to exist in the same application, and perhaps even safely interact (you can control whether you want this to be possible using the type system; I'm not sure if there is ever a case where this would be needed) This would of course, still be safe. It would not be possible to violate GC invariants using safe code, nor would it be possible for the GC to violate regular safety invariants.
  - bluejekyll 10y ago
    My biggest concern with the Gc ideas floating around Rust right now is that they may infect your program through dependencies. I guess I'm mostly worried about Gc being used by a large number of libraries, to the extent that it might not matter if stdlib implements it or not, because by using some very popular library you'd end up pulling in this runtime dependency. Part of me loves the flexibility this will bring to application design, but it could be a slippery slope.
    - kibwen 10y ago
      If such a popular GC-using dependency came into existence, then there would surely be demand for a drop-in replacement that didn't use GC. Remember, even the proposed Gc<T> type provides very little in the way of ergonomics (at least compared to garbage-collected types in pervasively-GC'd languages). Essentially it would just be a souped-up Rc<T> with no need for weak pointers to resolve cycles. Alternatively, it would only be used to interoperate with a foreign codebase that already uses GC, like SpiderMonkey or V8. Given that people tend to only be writing Rust in the first place if they put a large degree of value on performant solutions, I'm not too worried about the library ecosystem suddenly sneaking in GC everywhere, especially since the Rc type is already halfway to garbage collection, and I don't see it used unduly in the wild.
    - Manishearth 10y ago
      It's not going to be something considered idiomatic, especially in a library. Rust support quite a few things which you're not supposed to use other than in exceptional circumstances (e.g. catching/recovering panics -- there has been no slippery slope yet). Nor will the stdlib expose a GC API. I do intend on writing an example GC for this, but really each use case will probably need its own special GC implementation; since they are special use cases. That's not a decision to take lightly. I don't think GC will be something that can be silently pulled in, either, since you will need to change your codegen flags at the top level. This could be abstracted away by cargo, but it might be better if it wasn't; and you have to explicitly tell cargo in the toplevel toml file that you want GC to be on (and get a compile error if you try to compile without those flags). ================== Also, the Rust community seems to be very careful about unnecessary costs. Even Rc<T> isn't used much, and when it is, it seems to be used at the application (not library) level. When I have to box a closure or iterator in Rust because `-> impl Trait` doesn't exist (where you can return anonymous types by specifying the trait they implement), I feel so annoyed by the cost. As do many other Rustaceans. In reality, this is a pretty rare thing to do and the costs are negligible; but it feels annoying to not have the best performance. In such an environment, I doubt a library that frivolously uses GC will survive.
- pcwalton 10y ago
  Servo is doing this today in Rust, so it's quite possible. (It would be better with native language integration, and this is an area of current work.)
- Cyph0n 10y ago
  Nim does this already.

programLyrique 10y ago

I'd really like to have type-level numbers natively in Rust. Implementing a vector generic on its dimensions seems to be so much easier in D! Any prospect about that?

bjz_ 10y ago
There is definitely a prospect! The core team understands the need. It still needs an RFC though, and once that is accepted it will have to make its way from nightly, to beta, then finally to stable. So alas, not any time soon. :(
- yberreby 10y ago
  There's an RFC that could address the lack of type-level integers: https://github.com/rust-lang/rfcs/pull/1657 https://github.com/rust-lang/rfcs/pull/1657
  - bjz_ 10y ago
    Oh duh, I forgot about that - even commented on a few days ago!

teamhappy 10y ago

I think the section about immutability should mention that this is possible in Rust: fn main() { let x = true; let x = false; } I was pretty disappointed when I found out about it.

eudox 10y ago
Those are two different bindings. That is, fn main() { let x = true; { let x = false; } } Since you don't use let for assignment, it's a non-problem. And it can be useful when you're doing some computation where you want to keep intermediate variables (for debugging or clarity), and rather than think of the proper name for each, you just successively bind the same name.
- sixbrx 10y ago
  Very useful indeed when you want a canonical or corrected (or otherwise "improved") version of a value and want to make sure that the original can't accidentally be used in what follows (which can be a hard to detect bug).
  - eudox 10y ago
    Yes, a common refinement pattern in code is (pseudocode): def fn(object): let object = predicate(object) ? modify(object) : error(); // do something with the refined object Or something along those lines.
- teamhappy 10y ago
  I know a lot of people really like shadowing. I obviously don't. GHC has an option to emit a warning and if Rusts compiler adds one for it as well (maybe it has one by know? I don't know) I guess I'm okay with it.
  - steveklabnik 10y ago
    Clippy has a lint, but it's not turned on by default, even in Clippy.

d33 10y ago

I'm getting the impression that D is a failure. Is there any bigger project written in it? If not, why would it fail?

qznc 10y ago
Companies using it: https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html Weka explicitly says "over 200K LoC"
Manishearth 10y ago
People use D, and it is a pretty decent language. I'm not an avid D user, but I have a guess as to why it is not so widely used. To me, D is somewhat of a "I like C++s features and ergonomics and want a similar languages with all the features built in from the ground up" (+awesome metaprogramming). One of C++s drawbacks is that features have been bolted on in hacky ways due to backwards compatibility issues. D is like C++, but without this. It is a good goal, and from my limited experience with D I think they have achieved it well. Thing is, such a language will largely be adopted by people who use C++. And the problem with these folks is that they already know C++. Once you are used to it it doesn't feel so bad. Despite its drawbacks, C++ has lots of tooling, a large ecosystem, and familiarity. Rust is less affected by this for two reasons. One is that it gets a lot of production users from non-C++ shops who want to use a systems language to speed up their Python/etc tight loops. They would rather not worry about segfaults and stuff. The other is that for C++ users, Rust scratches a large itch. The learning curve for Rust is a lot worse than D, but for many the benefits might overcome this. You can't get used to segfaults the way you get used to template metaprogramming. I would give D time. These issues just slow adoption, not stop it. That is fine.

scotty79 10y ago

Another language you might consider is Nim which is more like D because it doesn't have specific selling point like Rust. It's very flexible and reasonable though and Python programmers will feel there immediately at home. You have GC there but you might opt out of it and/or let it run at specific times and for specific amount of time to manage gc pauses.

Const-me 10y ago

This article only covers the code. For the projects I work on (mostly C++ and/or C#), about 50% of decisions I make while coding is about data, not code. IMO, Rust just not good enough for creating complex specialized data structures. Even a trivial tree is hard to implement in Rust, and the implementation will be severely limited: https://github.com/SimonSapin/rust-forest https://github.com/SimonSapin/rust-forest D surely has it’s problems as well (in short, I think the language itself is very good, but its runtime and libraries still need a lot of work), but at least it’s good for complex data structures.

steveklabnik 10y ago
Yes, internals of data structures often need unsafe. At least with Cargo, and generics, you can implement them once, and then share them amongst projects. It's also why we have a fair number of data structures in the standard library; they will be audited a bit more heavily this way.
- bluejekyll 10y ago
  unsafe in Rust == telling the compiler I know what I'm doing here, so eff off. Other languages do this too, for instance in Java you can override final with reflection. I lost my mind, both good and bad, when I discovered this.
  - steveklabnik 10y ago
    But only in a controlled way. Unsafe doesn't change the semantics of existing code, it only adds the ability to do a few extra things. So you're still going to get a lot of safety checks, even within an unsafe block. You still have to be careful, but it's not no-holds-barred.
    - bluejekyll 10y ago
      Yeah. I've read your chapter on this repeatedly, and then the Rustinomicon, both hugely useful, but so far all I've done is use of for Rust -> C bindings and vice versa. It's taken me a year to feel good about my Rust code, I'm still getting a handle on unsafe though.

yarrel 10y ago

Rust: people use. D: people don't.