Live data from Hacker News

The reference D compiler is now open source

forum.dlang.org

101–110 of 313 posts

Re: The reference D compiler is now open source

#101
post #84

Earlier quoted context omitted.

I haven't used D much- how much of an impact does that have when using the standard library or other libraries? Is there a good way to use things that assume a GC even when it's disabled?

There are many parts of the std lib that assume GC usage. When you mark a function as @nogc, DMD does a compile-time check and will not compile your program if there's a GC call. Applying this to main means that your entire program will by necessity be GC free.

Right, I understand that it effectively eliminates GC usage, I'm just wondering how much of an impact that has on what tools you have. In the extreme, I can imagine it degenerating into basically writing C, for example.

Re: The reference D compiler is now open source

#102
post #59

Please don't get me wrong, as I don't want to start a flame here, but why do they call D a "systems programming language" when it uses a GC? Or is it optional? I'm just reading through the docs. They do have a command line option to disable the GC but anyway...this GC thing is, imho, a no-go when it comes to systems programming. It reminds me of Go that started as a "systems programming language" too but later switch…

The GC is only relevant if you allocate using the GC, because that is the only time the GC can run. If you use @nogc on your functions, you are guaranteed not to have GC allocations. You can use D as a better C with no GC but other good features. You can even avoid the D runtime compeletely if you want.

Re: The reference D compiler is now open source

#103
post #62

Earlier quoted context omitted.

Why does gc disqualify a language as a system's language? P.S. I think of a system's language as one that runs directly on the machine, e.g. Swift, C, go. They operate at the "system" level.

Could one write a driver in D?

There's a fairly recent growth in the D community of a "better C" movement, that is, people using D for lowest-level systems development, device drivers, etc. This seems to have lit a fire under initiatives to reduce D's GC dependency, and its runtime dependency in general. I don't follow this too closely, but it seems they are still at the "hacks and experiments" stage in terms of real-world use (e.g., people writing custom runtimes that stub out the GC, etc.).

DConf (http://dconf.org/2017/schedule/) is in three weeks, and there are a number of related talks. Once the videos are out, you might get a better sense of the current "D as a better C" landscape.

Re: The reference D compiler is now open source

#104
post #59

Please don't get me wrong, as I don't want to start a flame here, but why do they call D a "systems programming language" when it uses a GC? Or is it optional? I'm just reading through the docs. They do have a command line option to disable the GC but anyway...this GC thing is, imho, a no-go when it comes to systems programming. It reminds me of Go that started as a "systems programming language" too but later switch…

The GC is only relevant if you allocate using the GC, because that is the only time the GC can run. If you use @nogc on your functions, you are guaranteed not to have GC allocations. You can use D as a better C with no GC but other good features. You can even avoid the D runtime compeletely if you want.

Thanks for your helpful answer.

...and I don't understand why some people have downvoted my question. Anyway, I'll continue reading the docs :)

Re: The reference D compiler is now open source

#105
Good news indeed.

Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D.

D's only issue is that it does not have general adoption, which I'm willing to assert is only because it's not on the forefront of the cool kids language of the week. Which is a good thing. New does not always Mean, improved. D has a historical nod to languages of the past, and is trying to improve the on strengths of C/C++ and smooth out the rough edges, and adopt more modern programming concepts. Especially with trying to be ABI compatible, it's a passing of the torch from the old guard to the new.

Regardless of your thoughts on D; My opinion is I'm sold on D, It's here to stay. In 10 years D will still be in use, where as the fad languages will just be foot notes in Computer Science history as nice experiments that brought in new idea's but were just too out there in the fringes limiting themselves to the "thing/fad" of that language.

Re: The reference D compiler is now open source

#106

Earlier quoted context omitted.

The GC is only relevant if you allocate using the GC, because that is the only time the GC can run. If you use @nogc on your functions, you are guaranteed not to have GC allocations. You can use D as a better C with no GC but other good features. You can even avoid the D runtime compeletely if you want.

Thanks for your helpful answer. ...and I don't understand why some people have downvoted my question. Anyway, I'll continue reading the docs :)

I don't understand the downvotes either.

Anyway, the docs are not that great, so Mike Parker has started a blog post series about the GC.[1] If you have questions, drop them in the d.learn forum.[2] They're pretty friendly (most of the time).

[1] http://dlang.org/blog/2017/03/20/dont-fear-the-reaper/ [2] https://forum.dlang.org/group/learn

Re: The reference D compiler is now open source

#107
post #51

Anybody worked on performance critical stuff in D? How good is its GC?

I think it's common to avoid the GC in performance critical sections of your code. D's version of BLAS is faster[1] and avoids the GC completely. [1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

consistently beating OpenBLAS and having performance comparable with MKL is seriously impressive. I'm wondering how that is possible. I assume it's using the same algorithms as other implementations, so the credit goes to the compiler (and to the language to some extent). But the D compiler just uses LLVM for the back end, so is this because LDC produces really good LLVM IR, or is LLVM really good at generating assembly? Either way I'm really impressed they can beat hand-tuned assembly, I'd love to see a comparison between the resulting assembly for Mir GLAS and OpenBLAS.

Re: The reference D compiler is now open source

#108

Good news indeed. Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D. D's only issue is that it does not have general adoption, whic…

What do you consider as "fad languages"?

Re: The reference D compiler is now open source

#109
post #57

Earlier quoted context omitted.

Anybody out there that has experience with both Nim and D? I am curious how they both compare in terms of metaprogramming.

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 collector and it's apparently been discussed as the language's biggest flaw since 2013, but I can't find any information whatsoever on what's being done in that regard.

Re: The reference D compiler is now open source

#110
post #108

Good news indeed. Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D. D's only issue is that it does not have general adoption, whic…

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.
Post reply on HN