Live data from Hacker News

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

dlang.org

111–120 of 131 posts

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

#111
post #66

Earlier quoted context omitted.

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.

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.

> 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.

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

#112
post #38

Earlier quoted context omitted.

Funny anecdote for compiler researchers. Niklaus Wirth did write many of his compilers in the original language (kind of). He would write down on paper the code, using the bootstrap version 0 code style, as it was supposed to be. Then he would manually translate that code into Assembly. So when the compiler for the basic language was working, he could use the same code again, without additional efforts and relying on…

Computer languages were a lot simpler in those days.

That's true. Yet, Wirth's model is worth considering today. In Lilith system, they co-designed a high-level assembler (P-code-like), the Modula-2 language, the compiler, and critical OS regions. Built whole system on that. Key choice, learned from P-code, was to make assembler, high-level language, and compiler all consistent and simple where possible. Allowed easy composition and conversion.

Work on LISP/Scheme, Julia, REBOL, and so on show that even complex constructs can be built with macros, etc on simple ones which can be done Wirth-style as in Lilith/Oberon, my style [1], or by hand like pjmlp said. Actually, the Scheme stuff went down to synthesizing hardware from interpreters written in Scheme and another person did that with a Oberon-based HDL. So, it can go much further. :)

[1] https://news.ycombinator.com/item?id=10182752

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

#113
post #75

Earlier quoted context omitted.

Computer languages were a lot simpler in those days.

Are you sure? I remember reading something about PL/I. :)

Maybe PL/S, IBM's "secret weapon," (haha) would be better if we're talking C++ replacements. I did like how the language let you describe how exactly the compiler should handle the individual function. I can see that have payoff in OS and security-critical software.

https://en.wikipedia.org/wiki/IBM_PL/S

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

#114
post #45

This is the first time I found out that DMD isn't self-hosting; I always assumed it was.

Me too. Figure something good enough to replace C++ immediately and better to develop with would make for a better compiler. Not to mention all the advantages of writing a compiler in the language in question.

Only exception I promote is writing compilers in ML (esp Ocaml) because it's so good at doing that correctly. A concentration of compiler writers on such a great tool can only lead to an ecosystem whose quality C or C++ compilers will have trouble matching. Rewriting and testing the LLVM system at the least would be a good thing.

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

#115
post #101

Earlier quoted context omitted.

kinds and typeclasses are rather different, are they not?

Yeah, I shouldn't have made it read like I was equating the two. What HKT means is that typeclasses, like Monad, can take parameters of higher kinds. But if you don't have typeclasses in the first place (like D doesn't), then you don't have HKT.

Well this is completely wrong. HKT's have nothing to do with type classes.

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

#116
post #75

Earlier quoted context omitted.

Are you sure? I remember reading something about PL/I. :)

Maybe PL/S, IBM's "secret weapon," (haha) would be better if we're talking C++ replacements. I did like how the language let you describe how exactly the compiler should handle the individual function. I can see that have payoff in OS and security-critical software. https://en.wikipedia.org/wiki/IBM_PL/S

Interesting, I wasn't aware of it.

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

#117

Earlier quoted context omitted.

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.

> 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…

> 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++.

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

#118

Earlier quoted context omitted.

> 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…

> 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++.

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-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`.

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

#119

Earlier quoted context omitted.

Yeah, I shouldn't have made it read like I was equating the two. What HKT means is that typeclasses, like Monad, can take parameters of higher kinds. But if you don't have typeclasses in the first place (like D doesn't), then you don't have HKT.

Well this is completely wrong. HKT's have nothing to do with type classes.

I'm referring to what people want when they say they want "higher-kinded types" in Rust. That is: the ability to have typeclasses with higher-kinded type parameters.

I'm well aware that the formal definition of an HKT is just a type with a higher kind, and that's irrelevant to this discussion.

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

#120

Earlier quoted context omitted.

Well this is completely wrong. HKT's have nothing to do with type classes.

I'm referring to what people want when they say they want "higher-kinded types" in Rust. That is: the ability to have typeclasses with higher-kinded type parameters. I'm well aware that the formal definition of an HKT is just a type with a higher kind, and that's irrelevant to this discussion.

What certain Rust users want to do with HKT can already be done with D (maybe they're LKT's, loosely-kinded types -- you heard it here first!) or, for example, quite explicitly, C++, without type classes, so it's quite relevant.
Post reply on HN