Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D 2.069.0 released, compiler automatically ported from C++ to D

dlang.org

Post reply on HN
Print view View original

11–20 of 131 posts

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#11

Post by logicchains »

steveklabnik wrote: post #7
logicchains wrote: post #6

Earlier quoted context omitted.

Some things D has that Rust doesn't: compiler-checked function purity annotations, higher-kinded types, variadic functions/generics, types parameterised by numbers, compile-time function evaluation, mixins, a fast compiler (the reference DMD compiler), powerful and convenient compile-time reflection (I think technically Rust can do anything D can at compile time, but it requires writing a syntax extension to do so).…

I would say this is fairly accurate, yeah. We got rid of purity in Rust, we didn't find it useful. HKT, variadic generics, and type-level integers are all things we want to do in the future.

The ship's probably sailed on this, but is there any chance of Rust getting a module system like OCaml's (or Haskell's upcoming Backpack) in future? Or is there a way to provide module signatures with the current module system?

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#12

Post by steveklabnik »

logicchains wrote: post #11
steveklabnik wrote: post #7

Earlier quoted context omitted.

I would say this is fairly accurate, yeah. We got rid of purity in Rust, we didn't find it useful. HKT, variadic generics, and type-level integers are all things we want to do in the future.

The ship's probably sailed on this, but is there any chance of Rust getting a module system like OCaml's (or Haskell's upcoming Backpack) in future? Or is there a way to provide module signatures with the current module system?

Never say never, but I'm not aware of anyone who's even working on thinking about suggesting it. That'd be step one, creating an RFC which thinks through the design.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#13

Post by fithisux »

scardine wrote: post #5
amelius wrote: post #3

I'm wondering, is there an advantage of using D over Rust?

I guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.

I wish the ObjC was supported for Windows x86 (>= 7) for linking with Gnustep.

In any case, congratulations.

I wonder if the C++ to D translator could be used in other codebases, like Fltk for example.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#14

Post by logicchains »

steveklabnik wrote: post #12
logicchains wrote: post #11

Earlier quoted context omitted.

The ship's probably sailed on this, but is there any chance of Rust getting a module system like OCaml's (or Haskell's upcoming Backpack) in future? Or is there a way to provide module signatures with the current module system?

Never say never, but I'm not aware of anyone who's even working on thinking about suggesting it. That'd be step one, creating an RFC which thinks through the design.

There's this: https://internals.rust-lang.org/t/traits-ml-modules/272, but it didn't seem to get anywhere.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#15

Post by steveklabnik »

logicchains wrote: post #14
steveklabnik wrote: post #12

Earlier quoted context omitted.

Never say never, but I'm not aware of anyone who's even working on thinking about suggesting it. That'd be step one, creating an RFC which thinks through the design.

There's this: https://internals.rust-lang.org/t/traits-ml-modules/272 , but it didn't seem to get anywhere.

Right, that was just a few posts, a long time ago, and never really came close to being a serious proposal.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#17

Post by johncolanduoni »

royjacobs wrote: post #9
scardine wrote: post #5

Earlier quoted context omitted.

I guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.

How would you consider Rust's generics as being part of a better C rather than a better C++?

I think it's more about Rust's approach to OO. In Rust, traits are usually used as interfaces for generics instead of dynamic dispatch. The generated code/performance is more like what you would get if you implemented them explicitly for each appropriate type in C, built around structs. You could do this with C++ templates, but it would be a huge pain in that language due to lack of template type safety.

This is a quite important part of Rust (IMHO) because it gives the language a performance profile closer to C than C++ in many instances.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#18

Post by scardine »

royjacobs wrote: post #9
scardine wrote: post #5

Earlier quoted context omitted.

I guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.

How would you consider Rust's generics as being part of a better C rather than a better C++?

While OOP is perfectly possible in Rust, IMHO it is a lot more like doing OOP in C than in C++ (despite nice features like traits and generics).

Rust is marketed as a "general-purpose, multi-paradigm, compiled programming language" and D "originated as a re-engineering of C++", so may be I'm biased by my interpretation of the goals from both language designers.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#19

Post by pornel »

royjacobs wrote: post #9
scardine wrote: post #5

Earlier quoted context omitted.

I guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.

How would you consider Rust's generics as being part of a better C rather than a better C++?

C translates almost 1:1 to Rust, but when converting C++ to Rust you'll run into impedance mismatch between OO hierarchies and traits, and generics being narrower in functionality than templates.

In Rust you still can do "clever" things with generics to make them feel like C++, but the rest of the language is still closer to C: errors returned rather than thrown, no inheritance (but the "flat" OO and enums map well to what OO-like C programs do with "handles"), no constructors, etc.

Post reply on HN