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

131–140 of 313 posts

Re: The reference D compiler is now open source

#131

Post by gmfawcett »

theprotocol wrote: post #109
gmfawcett wrote: post #73

Earlier quoted context omitted.

I've dabbled with Nim. It's also a great language with great metaprogramming features. Plus a fast compiler that generates very lean code. (The real reason I stick with D over Nim, above all else, is RAII -- once you have it, it's really hard to live without. Okay, that, and also ranges, and array/string slices... they are fantastic to work with. Nim's got a better GC story right now, IMO, but there's a lot of activi…

Thanks for the writeup. I've just been evaluating Rust, D, and Nim, and reading about your experience has been helpful. Can you elaborate on how D is planning to sort out the garbage collection? Nim's GC is extremely fast and thread local, and can be disabled without breaking libraries (according to the author, it does something with memory regions that I haven't 100% grasped yet). I've googled about D's garbage coll…

Like Nim, you can also disable GC in D, and you can avoid GC altogether by not allocating GC'd memory (GC is only ever triggered at allocation time), or at least by preallocating and then disabling the collector. Raw allocation is always possible, and you can "emplace" D structs and classes into unmanaged memory.

The collector itself isn't being improved as far as I know -- at least I haven't seen any initiatives mentioned recently with that goal. In fairness, I haven't been following the community activity very closely in the past few months, but I think that's accurate. Nim definitely has a technical advantage re: its GC implementation.

The bigger movement has been the "@nogc initiative", which started with adding a @nogc attribute to the language (the compiler can verify that a function tagged with @nogc, and all of its callees, do not allocate GC memory). There is an ongoing initiative to make more of the Phobos library @nogc-compliant, to take advantage of this feature. There has also been a lot of work on custom memory-allocators [1], and I think the plan is to incorporate into Phobos where it makes sense, so you can have functions which take custom allocators, have thread-local allocators, etc.

https://dlang.org/phobos/std_experimental_allocator.html

I don't speak for the community or the dev team, but I think the long-term goal is to make the GC a feature that is available when you want it, but that isn't a dependency for using the standard library. Either through custom allocators or through @nogc guarantees, you'll be able to ensure that your program's memory management is deterministic.

Re: The reference D compiler is now open source

#132

Post by iamNumber4 »

oconnor663 wrote: post #121
iamNumber4 wrote: post #110

Earlier quoted context omitted.

Not going to start a flame war. Everyone has their opinions, However there are languages that come and go, and then are swift to become popular, but then are left to rust, because people stopped having smalltalk about them.

> languageS that Come and go, And then are swift to become popuLar, but then Are > languageS Come And popuLar Are > S C A L A Did I do that right?

I think you hit that Node, with a ruby of a pun, and are on the right railroad tracks my friend.

Re: The reference D compiler is now open source

#133

Post by vram22 »

vram22 wrote: post #99
Ace17 wrote: post #50

Earlier quoted context omitted.

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

>- 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. Right. See: http://www.infognition.com/blog/2014/d_as_scripting_language... Also of interest: Why D?…

Both those pages are working for me now. Might have been a temporary CDN or similar issue.

Re: The reference D compiler is now open source

#135

Post by theprotocol »

gmfawcett wrote: post #131
theprotocol wrote: post #109

Earlier quoted context omitted.

Thanks for the writeup. I've just been evaluating Rust, D, and Nim, and reading about your experience has been helpful. Can you elaborate on how D is planning to sort out the garbage collection? Nim's GC is extremely fast and thread local, and can be disabled without breaking libraries (according to the author, it does something with memory regions that I haven't 100% grasped yet). I've googled about D's garbage coll…

Like Nim, you can also disable GC in D, and you can avoid GC altogether by not allocating GC'd memory (GC is only ever triggered at allocation time), or at least by preallocating and then disabling the collector. Raw allocation is always possible, and you can "emplace" D structs and classes into unmanaged memory. The collector itself isn't being improved as far as I know -- at least I haven't seen any initiatives men…

Thanks for the info. It's pretty hard to get clear, updated info on these languages as they have yet to gain that much traction (and they tend not to be backed by big entities that have a PR budget).

For anyone else who's evaluating D and looking into its GC situation, the most recent blog post on Dlang.org (https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/) seems to embrace the presence of the GC, but also ends by saying the next blog post will describe how to go without the GC. So there is indeed awareness/activity on that front!

Re: The reference D compiler is now open source

#136

Post by dbaupp »

WalterBright wrote: post #90
Rusky wrote: post #82

Earlier quoted context omitted.

D has been around longer, has powerful compile-time metaprogramming tools, and has a very fast compiler. However, it has a garbage collector, and is not entirely memory-safe by default (though is beginning to optionally incorporate some ideas from Rust [edit: or not], maybe making that easier once you put in the work). It seems to follow C or C++ in what sorts of things it makes language-level features. Rust is newer…

D's memory safe notions are very different from Rust's.

Could you be more specific? It doesn't seem like there's much room in the conventional definition of memory safety (e.g. https://en.wikipedia.org/wiki/Memory_safety ) for variation, other than, I suppose, putting conditions on when/which things are actually guaranteed.

Re: The reference D compiler is now open source

#137

Post by oblio »

iamNumber4 wrote: post #110
oblio wrote: post #108

Earlier quoted context omitted.

What do you consider as "fad languages"?

Not going to start a flame war. Everyone has their opinions, However there are languages that come and go, and then are swift to become popular, but then are left to rust, because people stopped having smalltalk about them.

Despite the puns, as long as people start building production systems with those languages, they're going to stick around.

And several of those languages are probably used by 10x or more people than D is.

Luckily, there are so many things to build and so many programmers out there that almost any languages gets a spot under the sun these days.

When was the last time a programming language died out? My guess the last one was a language tied to its hardware...

Re: The reference D compiler is now open source

#138

Post by CyberShadow »

floatboth wrote: post #92
Rusky wrote: post #82

Earlier quoted context omitted.

D has been around longer, has powerful compile-time metaprogramming tools, and has a very fast compiler. However, it has a garbage collector, and is not entirely memory-safe by default (though is beginning to optionally incorporate some ideas from Rust [edit: or not], maybe making that easier once you put in the work). It seems to follow C or C++ in what sorts of things it makes language-level features. Rust is newer…

> a relatively slow compiler Well… it's relatively slow in release mode, but C++ compilers can often be slower. GHC is always slower :D

For some reference: DMD (the reference D compiler this thread is about), which consists of about 160000 lines of D code and 100000 more lines of C++ code, compiles in a bit over 3 seconds on my machine.

Re: The reference D compiler is now open source

#139

Post by bluecat »

Something I always thought was cool about dlang was that you can talk to the creator of the programming language on the forums. I don't write much D code as of now, but I always visit the forums everyday for the focused technical discussions. Anyways, congrats on the big news!

Re: The reference D compiler is now open source

#140

Post by grok2 »

softinio wrote: post #22

Whats special about D? why should i learn it?

I think one of the very good features of D is that it provides a lot of infrastructure that helps with lots of little generic things -- things that are not really needed in the language, but help reduce the amount of code you write or simplify common actions you take. It seems like Walter (and all the other contributors) have distilled their experience writing programs into creating a language that helps a lot with some of these things.

Stuff that I particularly like.

Assert/Enforce: http://ddili.org/ders/d.en/assert.html , Unit testing: http://ddili.org/ders/d.en/unit_testing.html , Contract programming help: http://ddili.org/ders/d.en/contracts.html, and http://ddili.org/ders/d.en/invariant.html , Scope (love this): http://ddili.org/ders/d.en/scope.html

And the other usuals -- templates, mixins, etc....

BTW, I mostly use D as a better C than as a better C++...

Post reply on HN