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.
The reference D compiler is now open source
101–110 of 313 posts
Re: The reference D compiler is now open source
#102Please 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…
Re: The reference D compiler is now open source
#103Earlier 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?
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
#104Please 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.
...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
#105Switched 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
#106Earlier 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 :)
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
#107Anybody 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/...
Re: The reference D compiler is now open source
#108Good 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…
Re: The reference D compiler is now open source
#109Earlier 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…
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
#110Good 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"?