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

The reference D compiler is now open source

forum.dlang.org

Post reply on HN
Print view View original

41–50 of 313 posts

Re: The reference D compiler is now open source

#41

Post by dbcurtis »

jordigh wrote: post #33
gmfawcett wrote: post #26

Earlier quoted context omitted.

Except for perhaps Lisp languages, almost no language makes compile-time computing and code-generation so easy. This allows for some really powerful language features that can be designed as libraries, and puts this power in the hands of "regular developers" rather than only in the hands of template wizards.

Yeah, I really love that at compile time you can meta-program in almost the same language that you use for normal run-time things. I think the comparison to lisp is apt. It almost feels like lisp macros. Think C++ template metaprogramming but much, much easier and thus, seemingly more powerful. It's not that you couldn't do the same in C++, but D's metaprogramming is so much more accessible that it makes you want to…

For someone who knows zero about D, but is a total Pythonista, how would you compare the meta-programming facilities?

Re: The reference D compiler is now open source

#42

Post by smitherfield »

saosebastiao wrote: post #30
qznc wrote: post #28

Earlier quoted context omitted.

There is no quantitative metric for safety and easyness. If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism, algebraic data types, hygienic macros, first class functions, and race-free concurrency. I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.

> race-free concurrency

Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.

Re: The reference D compiler is now open source

#43

Post by bachmeier »

MichaelGG wrote: post #35
WalterBright wrote: post #20

Earlier quoted context omitted.

We investigated public domain, but that has international legal problems with it. Boost was the best solution.

Do you have any comment son international legal issues with public domain? Is that not recognized in some places?

SQLite ran into trouble by using public domain, due to it not being recognized and for other reasons, and as a result will sell you a copy under a different license that guarantees your rights.

https://www.sqlite.org/copyright.html

Re: The reference D compiler is now open source

#45

Post by jordigh »

dbcurtis wrote: post #41
jordigh wrote: post #33

Earlier quoted context omitted.

Yeah, I really love that at compile time you can meta-program in almost the same language that you use for normal run-time things. I think the comparison to lisp is apt. It almost feels like lisp macros. Think C++ template metaprogramming but much, much easier and thus, seemingly more powerful. It's not that you couldn't do the same in C++, but D's metaprogramming is so much more accessible that it makes you want to…

For someone who knows zero about D, but is a total Pythonista, how would you compare the meta-programming facilities?

I guess the best comparison to Python would be the dunder methods. You know how in Python a class really is just a dict, right? Like, foo.bar is pretty much syntactic sugar for foo.__get_attribute__(foo.__dict__['bar']) in most cases. Or how a + b is sugar for a.__plus__(b).

Well, imagine that all of the things you can do in Python by messing with dunder methods, function decorators, or metaclasses could be precomputed by a compiler and would not even execute at all during runtime. It makes everything really fast at runtime and easy to precompute at compile time.

Re: The reference D compiler is now open source

#46

Post by AsyncAwait »

nialv7 wrote: post #39
tombert wrote: post #8

Honestly, since I'm slightly psychotic about these things, this is a kind of huge to me. Part of the reason I never learned D was because the compiler was partly proprietary. Now I have no excuse to avoid learning the language, and that should be fun.

There have been fully open source compiler for D for a long time: LDC and GDC.

Yup, but to be fair, they sometimes lack quite a bit behind dmd.

Re: The reference D compiler is now open source

#47

Post by bachmeier »

softinio wrote: post #22

Whats special about D? why should i learn it?

If you want to work with C code, it is an excellent choice. I use it for numerical computing. It's an easy language to learn, no need to worry about memory management if you don't want/need to, generally good syntax, nice compile time features. Overall the best "better C" in my opinion.

Re: The reference D compiler is now open source

#48

Post by jordigh »

jacques_chirac wrote: post #38
jordigh wrote: post #33

Earlier quoted context omitted.

Yeah, I really love that at compile time you can meta-program in almost the same language that you use for normal run-time things. I think the comparison to lisp is apt. It almost feels like lisp macros. Think C++ template metaprogramming but much, much easier and thus, seemingly more powerful. It's not that you couldn't do the same in C++, but D's metaprogramming is so much more accessible that it makes you want to…

There's plenty you can do with D but not C++, see regex, bitfields, swap member-by-member with checks for mutual pointers, the pegged library for grammars, etc etc.

I don't know, Boost has me convinced that even things like regexes in C++ templates could be possible, if your compiler has a big enough stack to handle very deep template recursions. It's theoretically possible to build a regex parser in C++ templates, right? It would be horrible, but possible.

Re: The reference D compiler is now open source

#49

Post by AsyncAwait »

tombert wrote: post #8

Honestly, since I'm slightly psychotic about these things, this is a kind of huge to me. Part of the reason I never learned D was because the compiler was partly proprietary. Now I have no excuse to avoid learning the language, and that should be fun.

I refused to touch Swift until Apple open-sourced it for the same reason :-)

Re: The reference D compiler is now open source

#50

Post by Ace17 »

JoshTriplett wrote: post #7
WalterBright wrote: post #5

Earlier quoted context omitted.

Each of dmd/gdc/ldc has their individual strengths and styles. It's an embarrassment of riches.

> Each of dmd/gdc/ldc has their individual strengths and styles. I'd be really interested to hear a comparison of those from someone experienced with D and its community.

Professional D coder here.

- DMD is by far the D compiler with the shortest compile time. It's actually so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D program. Say goodbye to shell/perl/python scripts, now you can have compile-time checks without an explicit/slow compilation step. We use it for automation tasks.

- GDC is the compiler of choice when it comes to supporting multiple targets and cross-compilation. It closely follows GCC and G++ command line conventions, meaning that using a single properly written Makefile it's easy to target x86/x86_64/arm, GNU/Linux (or Windows, but the mingw support has been in statis for years). Debian comes with pre-compiled arm-targetting GDC compiler. gdb, gcov, and operf work well. The generated code is fast (more than LDC), we use it for heavy computation tasks.

Post reply on HN