Hacker News Reader

Comment by scardine | Hacker News Reader

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

Rust is more like the child of C and a functional language (OCaml).

Still think that *ML syntax would fit Rust better.

I disagree. D is an improved C that does a lot of the same things as C++, but in order for it to be a better C++, it would need to start with C++ as a foundation and build on it. D has more of a scripting language feel to me.

> D has more of a scripting language feel to me.

I'm curious about this, although I don't think this is the first time I've heard D described as having a script-y feel to it. It sounds along the same lines as people describing Go as almost a scripting language, or comparing it to them. Neither Go nor D seem especially dynamic, both have compilers for reference implementations, both look more like C than Python. (To my eyes at least; I've never tried either one. Thus this question.)

Is it primarily the speed of the compilers? Both DMD and g6/g7/g8 boast very fast compiles, and Go uses somewhat script-y tools... but #!/usr/local/bin/tcc -run hasn't changed C's reputation. Fast compiling and memory safety, maybe?

People often say this because D has many features that allow it to be almost as flexible as the various scripting languages while still being compiled and statically typed. I don't bother with bash/cmd nowadays as D can easily fill that role, with the bonus of my small little scripts having all the power and scalability that D offers.

Also check out https://github.com/Abscissa/scriptlike

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.

Hmm, I see your point, but I've found that even in template-heavy code the compiler can produce code that's pretty optimal. Are you saying that with Rust it is easier to fall into the pit of success, as it were -- requiring less reasoning about how a compiler might convert the [templated|generic] code optimally?

My point was not that Rust creates better template code, but that a lot of things one uses dynamic dispatch for in C++ use templates instead. There are plenty of times when one knows the full derived type of a class in C++, but one throws away that information virtual calls are used anyway.

I think this is because Rust makes it far easier to use generics; they're type-safe and don't need to be pushed to header files. Also, the coding culture around Rust pushes one to use enums for dynamic dispatch instead of "trait objects" (Rust's equivalent of VFTs).

> but one throws away the information ...

With the mythical smart enough compiler with god like devirtualizer it would be less of an issue but gratuitous use of virtuals annoys me no end. CRTP isn't that hard for the simple use cases but you are beholden to the god of compiler error messages when things go wrong. One great thing that clang has done (among others) is make g++ get their shit together. Contrary to the popular sentiment I personally find the current crop of g++ error messages more helpful.

Another big part of the barrier here is the nature of compiled binaries. When you define a public generic function in Rust, the compiler ensures that it keeps enough information in the resulting binary so that the generic can be instantiated. Unless you wanted to massively balloon your headers and compile times, achieving the same with C++ is simply impossible across executables and libraries, and very hard even across object files.

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.

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.

Really? Now I have to go learn Rust.

> errors returned rather than thrown

WHATT??? did they do the same mistake as Go?

No. There's a few things that combine to make it different, but what it really boils down to are enums. Rust functions that can fail return a type, Result: http://doc.rust-lang.org/std/result/enum.Result.html

There's a number of things that make using this ergonomic: you can use the try! macro to convert it to a success value, returning an error value up the stack. You can use any of the combination methods on that page to chain various possibly-failing functions together into something that looks nice. Some people even use the word "monadic." We don't have if checks everywhere.

For more than you probably want to know on error handling in Rust, this guide just hit stable: https://doc.rust-lang.org/book/error-handling.html

It depends on what mistake you mean.

Having errors on return has merits. Particularly it make error handling more deterministic. What it tends to do though, in languages like C and Go, is be very verbose.

Rust largely mitigates that through judicious usage of some of its higher levels features. Specifically its try! macro wrap up the common case of passing errors up the call stack quite neatly. With that and the pervasive RAII, Rust does a pretty good job of making error management quite unobtrusive.

It also has quite a nice way of converting errors types using traits that, in my opinion at least, handles typed error propagation better than most exception mechanisms I am familiar with.

From a personal pov, I like the determinism and I like the type conversion. I probably prefer D's scope mechanism to RAII in general as I like thinks to be as explicit as possibly but without being too verbose. But I think Rust seems to have hit quite a nice balance.

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.

You could use it as a starting point, but it was never intended to be a generic tool. For example, the C++ code was changed in some places to make the job for the translator easier.

D is what you get if C married Python and the resulting baby was adopted and raised by Lisp and C#.

Reply on news.ycombinator.com