www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Hello, folks! Newbie to D, have some questions!

reply timmyjose <zoltan.jose gmail.com> writes:
Hello folks,

I am interested in learning D (just starting out, did a few of 
the exercises on the D tour), and had some questions before I 
decide to jump right in. My questions are genuinely motivated by 
my experiences and expectations, so please forgive me if some 
questions don't come across as well as my intentions!

1. I have some experience with both C and C++, and have been 
learning Rust for a while, but a few things put me off about the 
whole business -

a). The core language appears to be simple enough, but becomes 
increasingly complex as I begin writing larger programs.

b). The whole ownership system is easy to understand, but the 
APIs become very complicated and unwieldy, and more time appears 
to be spent on understanding and ensuring that memory is being 
used correctly than on the core program logic.

c). The whole community seems infused with both the Feminism/SJW 
(I don't care about those communities, but it feels weird having 
a programming community get sidetracked by all that bullshit), 
and too much of Ruby-on-Rails culture (probably started with 
Steve Klabnik) so that it doesn't feel like any real systems 
programmers are focusing on that language, and finally, d). The 
whole language feels like a bit of patchwork of random ideas, and 
also the whole "safety" and "no segfaults" guarantees seem to 
have lesser and lesser RoI as time goes by.

Sorry for the rant, I didn't realise I was quite that frustrated! 
That's just to give some background about me and my recent 
experiences! :D

In that regard, I suppose I'll get a better feel of the community 
here as I interact more, but I have high hopes that it'll be much 
more technical than purely social!

2. I am more interested in learning D as a pure systems 
programming language so that I can develop my own tools (not 
looking to develop an OS, just some grep-scale tools to start off 
with). In that regard, I have a few concerns about the GC. My 
rudimentary knowledge of the D ecosystem tells me that there is a 
GC in D, but that can be turned off. Is this correct? Also, some 
threads online mention that if we do turn off GC, some of the 
core std libraries may not fully work. Is this presumption also 
correct?

In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine? If you could 
share your experiences and domains of use, that would also be 
very helpful for me. Secondly, how stable is the language and how 
fast is the pace of development on D?

Again, sorry for my ignorance if I have been wrong-footed on some 
(or all) points.


2. I am also curious as to what would be the best path for a 
complete beginner to D to learn it effectively? I am a relatively 
fast learner (and I learn better by context, as in, some core 
unifying idea described and then elucidated through big examples 
instead of learning in bits and pieces). How did you folks learn 
D? I'm sure hearing your experiences would be helpful too. Are 
there any books/video tutorials that you would recommend (aside 
from this site itself).

3. Are there some small-scale Open Source projects that you would 
recommend to peruse to get a feel for and learn idiomatic D?

4. I have heard good reports of D's metaprogramming capabilities 
(ironically enough, primarily from a thread on the Rust user 
group), and coming from a Common Lisp (and some Racket) 
background, I am deeply interested in this aspect. Are D macros 
as powerful as Lisp macros? Are they semantically similar (for 
instance, I found Rust's macros are quite similar to Racket's)?

5. Supposing I devote the time and energy and get up to speed on 
D, would the core language team be welcoming if I feel like I can 
contribute?

That's all off the top of my head at the moment. Perhaps I'll 
have more questions as I read the responses. Thanks in advance!

Cheers.
Feb 18 2017
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 2. I am more interested in learning D as a pure systems 
 programming language so that I can develop my own tools (not 
 looking to develop an OS, just some grep-scale tools to start 
 off with). In that regard, I have a few concerns about the GC. 
 My rudimentary knowledge of the D ecosystem tells me that there 
 is a GC in D, but that can be turned off. Is this correct?


There is a GC, but you can avoid the features that use it. 
There's a function attribute for that:  nogc [1]. It forbids 
GC-manages allocations. The GC is still there, but it won't do 
anything because you're not triggering it.

You can also turn automatic collections off (GC.disable [2]). 
There's no need for that when all your code is  nogc, though, 
because collections are triggered by allocations.

As for getting rid of the GC entirely (for saving space, I 
guess), I think that's more involved. May require changes to 
druntime. Shouldn't be necessary most of the time.


 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?


Yes. Whenever a std function returns a new string or some such 
it's going to be GC-allocated. There's an experimental module for 
custom allocators [3], but the rest of the library doesn't make 
use of it, yet. When a std function uses the GC, the compiler 
won't let you call it from  nogc code.


 In this regard, I am curious to know if I would face any issues 
 (with my intent in mind), or will I do just fine?


I don't think you're going to run into much trouble when making 
"grep-scale tools".

[...]

 4. I have heard good reports of D's metaprogramming 
 capabilities (ironically enough, primarily from a thread on the 
 Rust user group), and coming from a Common Lisp (and some 
 Racket) background, I am deeply interested in this aspect. Are 
 D macros as powerful as Lisp macros?


D doesn't have macros. D has templates like C++, string mixins 
(insert a statically know/generated string as D code), and CTFE 
(Compile Time Function Evaluation, to programmatically generate 
static stuff).


 Are they semantically similar (for instance, I found Rust's 
 macros are quite similar to Racket's)?


Can't answer this, because I'm not familiar enough with those 
languages.


 5. Supposing I devote the time and energy and get up to speed 
 on D, would the core language team be welcoming if I feel like 
 I can contribute?


Absolutely. Anyone is welcome to contribute. D is very much a 
volunteer effort. Also don't hesitate to point out (or even fix) 
any stumbling blocks you may encounter when starting out.

[1] https://dlang.org/spec/attribute.html#nogc
[2] https://dlang.org/phobos/core_memory.html#.GC.disable
[3] https://dlang.org/phobos/std_experimental_allocator.html
[4] http://ddili.org/ders/d.en/index.html
[5] https://tour.dlang.org/
Feb 18 2017
next sibling parent reply timmyjose <zoltan.jose gmail.com> writes:
Thanks for the very comprehensive response! I think most of my 
doubts are cleared now. You're right though that I'm probably 
worrying too much about GC with my current use case. Also thanks 
for the links - they should also come in very handy indeed.

I managed to find some book recommendations as well on the site. 
I've decided to start out with what appears to be the most 
approachable of them - Programming in D by Ceherli.


D doesn't have macros. D has templates like C++, string mixins 
(insert a statically >know/generated string as D code), and CTFE 
(Compile Time Function Evaluation, to >programmatically generate 
static stuff).


Ah, I see! Thanks for clarifying that although CTFE as you 
mentioned it seems to match my specific interest.

I look forward to learning D and being able to contribute some 
day! :-)

On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 [...]


 There is a GC, but you can avoid the features that use it. 
 There's a function attribute for that:  nogc [1]. It forbids 
 GC-manages allocations. The GC is still there, but it won't do 
 anything because you're not triggering it.

 You can also turn automatic collections off (GC.disable [2]). 
 There's no need for that when all your code is  nogc, though, 
 because collections are triggered by allocations.

 As for getting rid of the GC entirely (for saving space, I 
 guess), I think that's more involved. May require changes to 
 druntime. Shouldn't be necessary most of the time.


 [...]


 Yes. Whenever a std function returns a new string or some such 
 it's going to be GC-allocated. There's an experimental module 
 for custom allocators [3], but the rest of the library doesn't 
 make use of it, yet. When a std function uses the GC, the 
 compiler won't let you call it from  nogc code.


 [...]


 I don't think you're going to run into much trouble when making 
 "grep-scale tools".

 [...]

 [...]


 D doesn't have macros. D has templates like C++, string mixins 
 (insert a statically know/generated string as D code), and CTFE 
 (Compile Time Function Evaluation, to programmatically generate 
 static stuff).


 [...]


 Can't answer this, because I'm not familiar enough with those 
 languages.


 [...]


 Absolutely. Anyone is welcome to contribute. D is very much a 
 volunteer effort. Also don't hesitate to point out (or even 
 fix) any stumbling blocks you may encounter when starting out.

 [1] https://dlang.org/spec/attribute.html#nogc
 [2] https://dlang.org/phobos/core_memory.html#.GC.disable
 [3] https://dlang.org/phobos/std_experimental_allocator.html
 [4] http://ddili.org/ders/d.en/index.html
 [5] https://tour.dlang.org/
Feb 18 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
timmyjose wrote:

 Thanks for the very comprehensive response! I think most of my doubts 
 are cleared now. You're right though that I'm probably worrying too 
 much about GC with my current use case.


i can tell you that i'm doing things like, for example, ZX Spectrum 
emulator and hobbyst videogames (everything in D, even low-level gfx), 
i never really cared about "avoiding GC", and i can maintain solid 
35/50/60 FPS (depending of my needs) with my code.

i.e. that "GC-phobia" (i'm not talking about you specifiallly, of 
course, sorry) is mostly based on nothing. as GC will never fire "on 
it's own", and you can control it, avoiding GC is not unnecessary 
(except some very special cases, of course ;-). the key tech here (as 
usual) is to not allocate in tight loops, plan your memory discipline 
and such. nothing new for people used to systems languages. ;-)

sure, you can stop worrying about that and use D as some kind of 
scripting language too, and still have all the features like type 
checking. for things like IRC or email client i absolutely don't care 
about allocations (i.e. doing it left and right) and just letting GC to 
do it's work. my usual IRC client uptime is several monthes (after that 
it runs out of memory, but this is 'cause it never does any cleanup on 
it's data, keeping all logs and db in memory. i am too lazy to finish 
it. note that is it not a GC fault, it is my code. ;-).
Feb 18 2017
parent reply timmyjose <zoltan.jose gmail.com> writes:
On Saturday, 18 February 2017 at 21:58:15 UTC, ketmar wrote:

 timmyjose wrote:

 Thanks for the very comprehensive response! I think most of my 
 doubts are cleared now. You're right though that I'm probably 
 worrying too much about GC with my current use case.


 i can tell you that i'm doing things like, for example, ZX 
 Spectrum emulator and hobbyst videogames (everything in D, even 
 low-level gfx), i never really cared about "avoiding GC", and i 
 can maintain solid 35/50/60 FPS (depending of my needs) with my 
 code.
 i.e. that "GC-phobia" (i'm not talking about you specifiallly, 
 of course, sorry) is mostly based on nothing. as GC will never 
 fire "on it's own", and you can control it, avoiding GC is not 
 unnecessary (except some very special cases, of course ;-). the 
 key tech here (as usual) is to not allocate in tight loops, 
 plan your memory discipline and such. nothing new for people 
 used to systems languages. ;-)


No, you're quite right indeed! First of all, those sound like 
very interesting project! :-), and you're right about the GC 
part. I have some experience in systems programming in C++ and 
also application development in Java. Java's GC never really 
bothered me so much, but it's quite intriguing that you (and one 
more person before) mention that the GC does not fire on its own. 
So a couple of questions here (might be a bit premature, but I'm 
interested!):

a). So the GC is part of the runtime even if we specify  nogc

b). Do we manually trigger the GC (like Java's System.gc(), even 
though that's not guaranteed), or does it get triggered 
automatically when we invoke some operations on heap allocated 
data and/or when the data go out of scope?

c). Does Rust have analogues of "new" and "delete", or does it 
use something like smart pointers by default?


 sure, you can stop worrying about that and use D as some kind 
 of scripting language too, and still have all the features like 
 type checking. for things like IRC or email client i absolutely 
 don't care about allocations (i.e. doing it left and right) and 
 just letting GC to do it's work. my usual IRC client uptime is 
 several monthes (after that it runs out of memory, but this is 
 'cause it never does any cleanup on it's data, keeping all logs 
 and db in memory. i am too lazy to finish it. note that is it 
 not a GC fault, it is my code. ;-).


I could not agree more about the type checking bit. It's bitten 
my backside more than I care to remember (even though LLVM and 
Clang do produce better warnings than gcc IMO), and so a stronger 
type checker is always welcome! :-)

Fascinating reading about the various use cases that you and 
others have put D to. It does give me a lot more contextual 
understanding now. Thank you!
Feb 19 2017
next sibling parent timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 11:51:02 UTC, timmyjose wrote:

 On Saturday, 18 February 2017 at 21:58:15 UTC, ketmar wrote:

 [...]


 No, you're quite right indeed! First of all, those sound like 
 very interesting project! :-), and you're right about the GC 
 part. I have some experience in systems programming in C++ and 
 also application development in Java. Java's GC never really 
 bothered me so much, but it's quite intriguing that you (and 
 one more person before) mention that the GC does not fire on 
 its own. So a couple of questions here (might be a bit 
 premature, but I'm interested!):

 [...]


Oops! I meant D, of course. Sorry, still recovering from that 
drug. Heh!


 [...]


 [...]
Feb 19 2017
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 02/19/2017 12:51 PM, timmyjose wrote:

 a). So the GC is part of the runtime even if we specify  nogc


Yup.  nogc is per function, not per program. Other functions are allowed 
to use the GC.


 b). Do we manually trigger the GC (like Java's System.gc(), even though
 that's not guaranteed), or does it get triggered automatically when we
 invoke some operations on heap allocated data and/or when the data go
 out of scope?


You can trigger a collection manually with GC.collect [1]. Otherwise, 
the GC can do a collection when you make a GC-managed allocation. If you 
don't make GC allocations, e.g. because you're in  nogc code and the 
compiler doesn't allow you to, then no GC collections will happen.


 c). Does Rust have analogues of "new" and "delete", or does it use
 something like smart pointers by default?


D, not Rust, right?

D uses `new` for GC allocations. `new` returns a raw pointer or a 
dynamic array (pointer bundled with length for bounds checking).

There is `delete`, but it's shunned/unfashionable. Maybe it's going to 
be deprecated, I don't know. You're supposed to let the GC manage 
deletion, or use `destroy` [2] and GC.free [3] if you have to do it 
manually.

Of course, you can also call C functions like `malloc` and `free` and do 
manual memory management.

Regarding smart pointers, I'm not up to speed. There's 
std.typecons.Unique [4], but I don't know how it compares to other 
languages.


[1] https://dlang.org/phobos/core_memory.html#.GC.collect
[2] https://dlang.org/phobos/object.html#.destroy
[3] https://dlang.org/phobos/core_memory.html#.GC.free
Feb 19 2017
parent reply timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 12:31:51 UTC, ag0aep6g wrote:

 On 02/19/2017 12:51 PM, timmyjose wrote:

 a). So the GC is part of the runtime even if we specify  nogc


 Yup.  nogc is per function, not per program. Other functions 
 are allowed to use the GC.


 b). Do we manually trigger the GC (like Java's System.gc(), 
 even though
 that's not guaranteed), or does it get triggered automatically 
 when we
 invoke some operations on heap allocated data and/or when the 
 data go
 out of scope?


 You can trigger a collection manually with GC.collect [1]. 
 Otherwise, the GC can do a collection when you make a 
 GC-managed allocation. If you don't make GC allocations, e.g. 
 because you're in  nogc code and the compiler doesn't allow you 
 to, then no GC collections will happen.


 c). Does Rust have analogues of "new" and "delete", or does it 
 use
 something like smart pointers by default?


 D, not Rust, right?


Yes, indeed!


 D uses `new` for GC allocations. `new` returns a raw pointer or 
 a dynamic array (pointer bundled with length for bounds 
 checking).

 There is `delete`, but it's shunned/unfashionable. Maybe it's 
 going to be deprecated, I don't know. You're supposed to let 
 the GC manage deletion, or use `destroy` [2] and GC.free [3] if 
 you have to do it manually.

 Of course, you can also call C functions like `malloc` and 
 `free` and do manual memory management.


I actually tried out some of the sample programs given on this in 
"Learning D", and it was quite smooth indeed. As ketmar mentioned 
in the other thread, maybe I could use this as a backup strategy 
till I get comfortable with idiomatic D.

A few things I already like so far about D (just on chapter 2 of 
the book!):

1). T* x, y applying the pointer type to both variables (this has 
been a bane for me with C in the past).

2). The cast(T) syntax.

3). The module system appears pretty logical to me so far.

4). The creation of dynamic arrays is quite smooth and intuitive 
for me, and much easier than in C or C++.

5). I love array slices!

6). Properties!

7). The array initialisation syntax (especially for rectangular 
arrays) - much more logical than in C++/Java.

8). The use of %s for string interpolation (just like Common 
Lisps' ~a). Very convenient.


Things I don't like so much:

1). The std.range: iota function(?) is pretty nice, but the 
naming seems a bit bizarre, but quite nice to use.

2). The automatic conversion rules are nice for avoiding verbose 
code, but it looks like it might bite one just like in C++.

3). Not so much a fan of "auto", but it does have its uses, of 
course.

4). I'm still a bit confused by order of dimensions in 
rectangular arrays:

Suppose I have a simple 2 x 3 array like so:

import std.stdio;
import std.range: iota;

void main() {
	// a 2 x 3 array
	int [3][2] arr;

	foreach (i; iota(0, 2)) {
		foreach(j; iota(0, 3)) {
			arr[i][j] = i+j;
		}
	}

	writefln("second element in first row = %s", arr[0][1]);
	writefln("third element in second row = %s", arr[1][2]);

	writeln(arr);
}

My confusion is this - the declaration of the array is arr 
[last-dimension]...[first-dimension], but the usage is 
arr[first-dimension]...[last-dimension]. Am I missing something 
here?



 Regarding smart pointers, I'm not up to speed. There's 
 std.typecons.Unique [4], but I don't know how it compares to 
 other languages.


 [1] https://dlang.org/phobos/core_memory.html#.GC.collect
 [2] https://dlang.org/phobos/object.html#.destroy
 [3] https://dlang.org/phobos/core_memory.html#.GC.free
Feb 20 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
timmyjose wrote:


 Suppose I have a simple 2 x 3 array like so:
 import std.stdio;
 import std.range: iota;
 void main() {
 	// a 2 x 3 array
 	int [3][2] arr;
 foreach (i; iota(0, 2)) {
 		foreach(j; iota(0, 3)) {
 			arr[i][j] = i+j;
 		}
 	}
 writefln("second element in first row = %s", arr[0][1]);
 	writefln("third element in second row = %s", arr[1][2]);
 writeln(arr);
 }
 My confusion is this - the declaration of the array is arr 
 [last-dimension]...[first-dimension], but the usage is 
 arr[first-dimension]...[last-dimension]. Am I missing something here?


yes. it is quite easy to remember if you'll just read the declaration 
from left to right:
  int[3][2] arr
becomes:
  (int[3])[2]
i.e. "array of two (int[3]) items". no complicated decoding rules.

and then accessing it is logical too: first we'll index array of two 
items, then `(int[3])` array.

declaration may look "reversed", but after some time i found it 
straightforward to read. ;-)
Feb 20 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Monday, 20 February 2017 at 14:52:43 UTC, ketmar wrote:

 timmyjose wrote:


 Suppose I have a simple 2 x 3 array like so:
 import std.stdio;
 import std.range: iota;
 void main() {
 	// a 2 x 3 array
 	int [3][2] arr;
 foreach (i; iota(0, 2)) {
 		foreach(j; iota(0, 3)) {
 			arr[i][j] = i+j;
 		}
 	}
 writefln("second element in first row = %s", arr[0][1]);
 	writefln("third element in second row = %s", arr[1][2]);
 writeln(arr);
 }
 My confusion is this - the declaration of the array is arr 
 [last-dimension]...[first-dimension], but the usage is 
 arr[first-dimension]...[last-dimension]. Am I missing 
 something here?


 yes. it is quite easy to remember if you'll just read the 
 declaration from left to right:
  int[3][2] arr
 becomes:
  (int[3])[2]
 i.e. "array of two (int[3]) items". no complicated decoding 
 rules.

 and then accessing it is logical too: first we'll index array 
 of two items, then `(int[3])` array.

 declaration may look "reversed", but after some time i found it 
 straightforward to read. ;-)


Hmmm... yes, that does help indeed. So we read that as "each cell 
in an array of 2 cells is an array with 3 cells"? I'll have to 
get used to this I suppose!
Feb 20 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 20 February 2017 at 14:44:41 UTC, timmyjose wrote:

 My confusion is this - the declaration of the array is arr 
 [last-dimension]...[first-dimension], but the usage is 
 arr[first-dimension]...[last-dimension]. Am I missing something 
 here?


I've never understood how anyone could actually like C's weird, 
backward way of doing arrays. It never made a lick of sense to me.

D is beautifully consistent: each index "peels off" a layer. If 
you had a function returning a function:

void function(string) foo() {
    return (string name) { writeln("hi, ", name); };
}

Is a zero-arg function that returns a function that takes a 
string parameter.

How would you call the returned function?

foo("adam")()

or

foo()("adam")

?


Of course, the answer is the second form: the first level of () 
calls the function `foo`, which returns the function that takes 
the string parameter.



Arrays are the same thing.

int[2][3] arr;

is a 3-element array of 2-element arrays of int. So, how do you 
get to the int[2]? You peel away a level of []:

int[2] row = arr[0] // that peels away the [3], leaving an int[2]

int a = row[0]; // peel away the last level, leaving just int



Beautifully consistent, even if you want pointers:

int[2]*[3] arrOfPointers;

arrOfPointers[0] // type int[2]*, aka "pointer to two-element 
array of int"



And once you realize that opIndex can be overloaded, it makes 
even more sense:


arr[1][0] gets rewritten to arr.opIndex(1).opIndex(0) - bringing 
us back to my first example, we almost literally have a function 
returning a function again. Of course it reads the other 
direction from declaration!
Feb 20 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Monday, 20 February 2017 at 14:54:58 UTC, Adam D. Ruppe wrote:

 On Monday, 20 February 2017 at 14:44:41 UTC, timmyjose wrote:

 My confusion is this - the declaration of the array is arr 
 [last-dimension]...[first-dimension], but the usage is 
 arr[first-dimension]...[last-dimension]. Am I missing 
 something here?


 I've never understood how anyone could actually like C's weird, 
 backward way of doing arrays. It never made a lick of sense to 
 me.


Hahaha! I suppose it's just a question of ingrained habit! :-)


 D is beautifully consistent: each index "peels off" a layer. If 
 you had a function returning a function:

 void function(string) foo() {
    return (string name) { writeln("hi, ", name); };
 }

 Is a zero-arg function that returns a function that takes a 
 string parameter.

 How would you call the returned function?

 foo("adam")()

 or

 foo()("adam")

 ?


 Of course, the answer is the second form: the first level of () 
 calls the function `foo`, which returns the function that takes 
 the string parameter.



 Arrays are the same thing.

 int[2][3] arr;

 is a 3-element array of 2-element arrays of int. So, how do you 
 get to the int[2]? You peel away a level of []:

 int[2] row = arr[0] // that peels away the [3], leaving an 
 int[2]

 int a = row[0]; // peel away the last level, leaving just int


Yes, this does make sense!



 Beautifully consistent, even if you want pointers:

 int[2]*[3] arrOfPointers;

 arrOfPointers[0] // type int[2]*, aka "pointer to two-element 
 array of int"



 And once you realize that opIndex can be overloaded, it makes 
 even more sense:


 arr[1][0] gets rewritten to arr.opIndex(1).opIndex(0) - 
 bringing us back to my first example, we almost literally have 
 a function returning a function again. Of course it reads the 
 other direction from declaration!


Okay, I don't understand all of it, but I can see your argument 
that it is more logically consistent this way.
Feb 20 2017
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 02/20/2017 03:44 PM, timmyjose wrote:

 Things I don't like so much:

 1). The std.range: iota function(?) is pretty nice, but the naming seems
 a bit bizarre, but quite nice to use.


Yeah, the name is weird. A little googling suggests it comes from C++ 
[1] which took it from APL.


 2). The automatic conversion rules are nice for avoiding verbose code,
 but it looks like it might bite one just like in C++.


D at least disallows narrowing conversions. But yeah, conversions 
between signed/unsigned, from integral to floating point, or from 
narrower to wider char variants can have surprising results.


 3). Not so much a fan of "auto", but it does have its uses, of course.


`auto` can obscure your code, but it can also make it more DRY. And with 
ranges and their combinations, types quickly get too complex to type out.


 4). I'm still a bit confused by order of dimensions in rectangular arrays:

 Suppose I have a simple 2 x 3 array like so:

 import std.stdio;
 import std.range: iota;

 void main() {
     // a 2 x 3 array
     int [3][2] arr;

     foreach (i; iota(0, 2)) {
         foreach(j; iota(0, 3)) {
             arr[i][j] = i+j;
         }
     }

     writefln("second element in first row = %s", arr[0][1]);
     writefln("third element in second row = %s", arr[1][2]);

     writeln(arr);
 }

 My confusion is this - the declaration of the array is arr
 [last-dimension]...[first-dimension], but the usage is
 arr[first-dimension]...[last-dimension]. Am I missing something here?


You've got it. Declarations have the form `Type name;`. Fixed-size array 
types have the form `E[n]`. E can itself be another fixed-size array 
type, say F[m]. Then the whole type becomes F[m][n]. Simple.

The syntax could have be designed to grow in the other direction: [n]E = 
[n][m]F, to match indexing order. But Walter didn't make it that way.


[1] http://en.cppreference.com/w/cpp/algorithm/iota
Feb 20 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Monday, 20 February 2017 at 15:27:16 UTC, ag0aep6g wrote:

 On 02/20/2017 03:44 PM, timmyjose wrote:

 Things I don't like so much:

 1). The std.range: iota function(?) is pretty nice, but the 
 naming seems
 a bit bizarre, but quite nice to use.


 Yeah, the name is weird. A little googling suggests it comes 
 from C++ [1] which took it from APL.


Damn! I'd just watched this interesting APL demo from 1975 a 
couple of days back
(https://www.youtube.com/watch?v=_DTpQ4Kk2wA) which does use 
iota, and I never did make the connection!


 2). The automatic conversion rules are nice for avoiding 
 verbose code,
 but it looks like it might bite one just like in C++.


 D at least disallows narrowing conversions. But yeah, 
 conversions between signed/unsigned, from integral to floating 
 point, or from narrower to wider char variants can have 
 surprising results.


 3). Not so much a fan of "auto", but it does have its uses, of 
 course.


 `auto` can obscure your code, but it can also make it more DRY. 
 And with ranges and their combinations, types quickly get too 
 complex to type out.


Absolutely agreed.


 4). I'm still a bit confused by order of dimensions in 
 rectangular arrays:

 Suppose I have a simple 2 x 3 array like so:

 import std.stdio;
 import std.range: iota;

 void main() {
     // a 2 x 3 array
     int [3][2] arr;

     foreach (i; iota(0, 2)) {
         foreach(j; iota(0, 3)) {
             arr[i][j] = i+j;
         }
     }

     writefln("second element in first row = %s", arr[0][1]);
     writefln("third element in second row = %s", arr[1][2]);

     writeln(arr);
 }

 My confusion is this - the declaration of the array is arr
 [last-dimension]...[first-dimension], but the usage is
 arr[first-dimension]...[last-dimension]. Am I missing 
 something here?


 You've got it. Declarations have the form `Type name;`. 
 Fixed-size array types have the form `E[n]`. E can itself be 
 another fixed-size array type, say F[m]. Then the whole type 
 becomes F[m][n]. Simple.


Brilliant! This explanation actually makes me get it now.


 The syntax could have be designed to grow in the other 
 direction: [n]E = [n][m]F, to match indexing order. But Walter 
 didn't make it that way.


 [1] http://en.cppreference.com/w/cpp/algorithm/iota
Feb 20 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 02/20/2017 06:44 AM, timmyjose wrote:


 3). Not so much a fan of "auto", but it does have its uses, of course.


For completeness, D's 'auto' does not have the same meaning as C++'s 
auto. Wait... it actually has! :) But with the meaning of the 'auto' 
keyword from the olden C days: automatic storage class. (I correct this 
at the end.)

- C has 'auto', meaning "automatic storage class"

- 'auto' is redundant because it's the default anyway

- C++11 re-purposes 'auto' to mean automatic type inference (Ali and 
others initially assume 'auto' is the same in D.)

- D has automatic type inference universally without special keyword:

     const i = 42;    // No auto

- D needs a place holder to satisfy its syntax rules in certain cases

     i = 42;    // Definition or a typo? Compilation error!

- D brings back the original meaning of 'auto':

     // Yes, automatic storage class but now everybody's happy
     auto i = 42;

Correction: It's actually the 'auto attribute' in D with the venerable 
responsibility of "The auto attribute is used when there are no other 
attributes and type inference is desired." Good job, auto! :o)

Ali
Feb 20 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Ali Çehreli wrote:


 Correction: It's actually the 'auto attribute' in D with the 
 venerable responsibility of "The auto attribute is used when there 
 are no other attributes and type inference is desired." Good job, auto! :o)


  foreach (auto n; arr)

oops. good job, auto!
Feb 20 2017
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Mon, Feb 20, 2017 at 05:39:30PM +0000, ketmar via Digitalmars-d-learn wrote:

 Ali ehreli wrote:
 

 Correction: It's actually the 'auto attribute' in D with the
 venerable responsibility of "The auto attribute is used when there
 are no other attributes and type inference is desired." Good job,
 auto! :o)


 
  foreach (auto n; arr)
 
 oops. good job, auto!


Haha... in this case you want to actually just drop `auto` completely.
:-D

But yeah, there are some funny inconsistencies in what exactly `auto` is
supposed to mean.  Hard to say whether this case should be considered a
bug, though.  In any case, it's only a trivial one.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you
already said that." -- User-Friendly
Feb 20 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
"H. S. Teoh via Digitalmars-d-learn" wrote:


 On Mon, Feb 20, 2017 at 05:39:30PM +0000, ketmar via 
 Digitalmars-d-learn wrote:

  foreach (auto n; arr)

 oops. good job, auto!


 Haha... in this case you want to actually just drop `auto` completely.
 :-D

 But yeah, there are some funny inconsistencies in what exactly `auto` is
 supposed to mean.  Hard to say whether this case should be considered a
 bug, though.  In any case, it's only a trivial one.


this issue (`auto` in `foreach`) is raising from time to time, so it is 
definitely a sign that something is wrong. but i won't go further, it 
was already beaten to death zillion times.
Feb 20 2017
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
timmyjose wrote:

 a). So the GC is part of the runtime even if we specify  nogc


yes. GC is basically just a set of functions and some supporting data 
structures, it is compiled in druntime.  nogc doesn't turn it off, if 
says that compiler must ensure that *your* *code* doesn't allocate, at 
compile time. i.e.  nogc code with GC allocations won't compile at all.



 b). Do we manually trigger the GC (like Java's System.gc(), even 
 though that's not guaranteed), or does it get triggered automatically 
 when we invoke some operations on heap allocated data and/or when the 
 data go out of scope?


GC can be invoked *only* on allocation. as long as you don't allocate 
GC data, GC will not be called. of course, things like array/string 
concatenation (and closure creation) allocates, so you'd better be 
careful with your code if you want to avoid GC in some critical part. 
or you can call `GC.disable()` to completely disable GC (and 
`GC.enable()` later, of course ;-).



 c). Does Rust have analogues of "new" and "delete", or does it use 
 something like smart pointers by default?


`new`. no `delete`, tho, as it is not necessary with GC. actually, 
there is `delete` thingy, but it is deprecated, and you'd better not 
use it unless you are *really* know what you're doing and why. i.e. 
don't prematurely optimize your code, especially without good 
understanding of D's GC.



 Fascinating reading about the various use cases that you and others 
 have put D to. It does give me a lot more contextual understanding 
 now. Thank you!


you're welcome.

as for me, i am using D exclusively for *all* my programming tasks 
(including writing simple shell scripts ;-) for years. and i don't want 
to go back to C/C++ or switch to some [new] hyped language. i have 20+ 
years of programming expirience, and i feel that D is the best language 
i ever used. don't get me wrong, tho: it doesn't mean that D is the 
best language on the planet. what i mean is that D has a best balance 
of features, warts, libs and so on *for* *me*. easy C interop allows me 
to use all the C libraries out there; C-like syntax allows me to port C 
code (i did alot of C ports, including NanoVG, NanoSVG, Tremor Vorbis 
decoder, Opus decoder, etc.); great metaprogramming (for C-like 
language) allows me to skip writing boilerplate code; and so on. ;-)

also, dmd compiler is easily hackable. trying to even compile gcc is a 
PITA, for example. and dmd+druntime+phobos takes ~1.5 minutes to build 
on my old i3.
Feb 19 2017
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-02-19 13:45, ketmar wrote:


 nogc doesn't turn it off, if
 says that compiler must ensure that *your* *code* doesn't allocate,


Just to clarify, allocate using the GC. It's perfectly fine to allocate 
using malloc in a  nogc function.

-- 
/Jacob Carlborg
Feb 19 2017
prev sibling parent reply timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 12:45:49 UTC, ketmar wrote:

 timmyjose wrote:

 a). So the GC is part of the runtime even if we specify  nogc


 yes. GC is basically just a set of functions and some 
 supporting data structures, it is compiled in druntime.  nogc 
 doesn't turn it off, if says that compiler must ensure that 
 *your* *code* doesn't allocate, at compile time. i.e.  nogc 
 code with GC allocations won't compile at all.



 b). Do we manually trigger the GC (like Java's System.gc(), 
 even though that's not guaranteed), or does it get triggered 
 automatically when we invoke some operations on heap allocated 
 data and/or when the data go out of scope?


 GC can be invoked *only* on allocation. as long as you don't 
 allocate GC data, GC will not be called. of course, things like 
 array/string concatenation (and closure creation) allocates, so 
 you'd better be careful with your code if you want to avoid GC 
 in some critical part. or you can call `GC.disable()` to 
 completely disable GC (and `GC.enable()` later, of course ;-).



 c). Does Rust have analogues of "new" and "delete", or does it 
 use something like smart pointers by default?


 `new`. no `delete`, tho, as it is not necessary with GC. 
 actually, there is `delete` thingy, but it is deprecated, and 
 you'd better not use it unless you are *really* know what 
 you're doing and why. i.e. don't prematurely optimize your 
 code, especially without good understanding of D's GC.



 Fascinating reading about the various use cases that you and 
 others have put D to. It does give me a lot more contextual 
 understanding now. Thank you!


 you're welcome.

 as for me, i am using D exclusively for *all* my programming 
 tasks (including writing simple shell scripts ;-) for years. 
 and i don't want to go back to C/C++ or switch to some [new] 
 hyped language. i have 20+ years of programming expirience, and 
 i feel that D is the best language i ever used. don't get me 
 wrong, tho: it doesn't mean that D is the best language on the 
 planet. what i mean is that D has a best balance of features, 
 warts, libs and so on *for* *me*. easy C interop allows me to 
 use all the C libraries out there; C-like syntax allows me to 
 port C code (i did alot of C ports, including NanoVG, NanoSVG, 
 Tremor Vorbis decoder, Opus decoder, etc.); great 
 metaprogramming (for C-like language) allows me to skip writing 
 boilerplate code; and so on. ;-)

 also, dmd compiler is easily hackable. trying to even compile 
 gcc is a PITA, for example. and dmd+druntime+phobos takes ~1.5 
 minutes to build on my old i3.


Very interesting reading about your experiences! I hope that I'll 
soon be in a position to start churning out my own pet projects 
as well! :-) ... one thing I've observed is that so far (very 
very early of course) D appears to be a lot more intuitive than 
C++, or at least the way I find things intuitive, especially with 
regard to arrays and slices. The only thing I have to kind of 
unlearn is the "default immutability" that I picked up from Rust 
- this confused me a bit at first when I saw how a slice can be 
spawned off into a brand new array upon assigning data to it (in 
the book "Learning D", which I find very nice so far).

Just one question about the compilers though - I read on the Wiki 
that there are three main compiler distros - dmd, ldc, and gdc. I 
code primarily on a mac, and I have installed both dmd and ldc. A 
lot of the flags appears to be similar, and for my small 
programs, compilation and execution speed appeared to be almost 
identical. However, the book suggested using dmd for dev and 
probably ldc/gdc for releases. Is this really followed that much 
in practice, or should I prefer dmd?

One more thing I noticed when I looked into the executable file 
(using "nm -gU" on my mac) is that I found two interesting 
symbols - _main and _Dmain. On Rust, for instance, the main 
function got turned into _main, so I couldn't use a main in the C 
code that I was trying to interop with from my Rust code. In this 
case, does the same restriction apply (I am still way too far 
from dabbling in interop in D as yet! :-)). I mean, suppose I 
write some sample code in C, and I have a local main function to 
test the code out locally, will I have to comment that out when 
invoking that library from D, or can I keep that as is?
Feb 20 2017
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
timmyjose wrote:


 Very interesting reading about your experiences!


tnx. ;-)


 one thing I've observed is that so far (very very early of course) D 
 appears to be a lot more intuitive than C++


yeah. i almost finished writing my own nntp/email client (actually, i'm 
writing this post with it). something i wanted to do for almost a 
decade, but never dared with C/C++. and did that in a week with D. ;-)



 Just one question about the compilers though - I read on the Wiki 
 that there are three main compiler distros - dmd, ldc, and gdc. I 
 code primarily on a mac, and I have installed both dmd and ldc. A lot 
 of the flags appears to be similar, and for my small programs, 
 compilation and execution speed appeared to be almost identical. 
 However, the book suggested using dmd for dev and probably ldc/gdc 
 for releases. Is this really followed that much in practice, or 
 should I prefer dmd?


i myself is using dmd for everything. usually i found that even without 
-O (it means "optimize code" for dmd) my apps are fast enough. even my 
Speccy emulator is perfectly fine without -O (mind you, it emulates the 
whole 8-bit machine: CPU, FDD, sound processor, etc., and has to keep 
constant 50FPS to make sound smooth). that is, if you are doing heavy 
number crunching, for example, you may want to use ldc. otherwise, 
stick with dmd: i found that my code spending most of it's time waiting 
for some i/o completion. ;-)



 One more thing I noticed when I looked into the executable file 
 (using "nm -gU" on my mac) is that I found two interesting symbols - 
 _main and _Dmain. On Rust, for instance, the main function got turned 
 into _main, so I couldn't use a main in the C code that I was trying 
 to interop with from my Rust code. In this case, does the same 
 restriction apply (I am still way too far from dabbling in interop in 
 D as yet! :-)). I mean, suppose I write some sample code in C, and I 
 have a local main function to test the code out locally, will I have 
 to comment that out when invoking that library from D, or can I keep 
 that as is?


as your library will prolly not have "main()" (and will be built as a 
lib), there should be no problems. i.e. i never had any troubles with 
symbols with my .so and .a libs (all two of them ;-). i also wrote .so 
injection code (injecting .so written in D into running process), and 
had no problems with that too.
Feb 20 2017
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 02/20/2017 07:00 AM, timmyjose wrote:


 slice can be spawned off into a brand new array upon assigning data to
 it (in the book "Learning D", which I find very nice so far).


It's not assigning data to a slice, but adding elements to it: It *may* 
spawn off a new array. You can use .capacity to see whether that will be 
the case:

   http://ddili.org/ders/d.en/slices.html#ix_slices..capacity

Related to your earlier question on multi-dimensional array syntax, 
which you seem to find "brilliant": :)

 
http://ddili.org/ders/d.en/slices.html#ix_slices.multi-dimensional%20array

Also, there is the following article which explains the inner workings 
of slices:

   https://dlang.org/d-array-article.html

Ali
Feb 20 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Monday, 20 February 2017 at 17:43:22 UTC, Ali Çehreli wrote:

 On 02/20/2017 07:00 AM, timmyjose wrote:


 slice can be spawned off into a brand new array upon


 assigning data to

 it (in the book "Learning D", which I find very nice so far).


 It's not assigning data to a slice, but adding elements to it: 
 It *may* spawn off a new array. You can use .capacity to see 
 whether that will be the case:

   http://ddili.org/ders/d.en/slices.html#ix_slices..capacity

 Related to your earlier question on multi-dimensional array 
 syntax, which you seem to find "brilliant": :)


 http://ddili.org/ders/d.en/slices.html#ix_slices.multi-dimensional%20array

 Also, there is the following article which explains the inner 
 workings of slices:

   https://dlang.org/d-array-article.html

 Ali


You're absolutely right! It was badly worded on my part.  And 
thanks for the links, they really do help! :-)
Feb 21 2017
prev sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Mon, Feb 20, 2017 at 03:00:05PM +0000, timmyjose via Digitalmars-d-learn
wrote:
[...]

 Just one question about the compilers though - I read on the Wiki that
 there are three main compiler distros - dmd, ldc, and gdc. I code
 primarily on a mac, and I have installed both dmd and ldc. A lot of
 the flags appears to be similar, and for my small programs,
 compilation and execution speed appeared to be almost identical.
 However, the book suggested using dmd for dev and probably ldc/gdc for
 releases. Is this really followed that much in practice, or should I
 prefer dmd?


Personally, I use dmd git HEAD for 90% of my D projects, because (1) I'm
such a sucker for the latest and greatest features, bugfixes, language
changes, etc., and (2) I occasionally contribute to the compiler
toolchain (mainly Phobos, sometimes druntime or dmd itself) and it's
much easier to debug something I use on a regular basis and not have to
switch to a different version or waste time chasing down a compiler bug
that's already been fixed in git HEAD.

However, when I need performant code, I pull up my trusty, rusty old gdc
(which, unfortunately, tends to be about a version or two behind the
main dmd release -- I believe Iain is working on improving this,
though). In spite of Walter being a renowned compiler genius, he simply
has too many things on his plate and working on the optimizer hasn't
been a high priority, so gdc's optimizer easily beats dmd (sometimes by
a long stretch).  Don't get me wrong; for your average desktop
application, dmd output is more than good enough. It only really matters
when you're dealing with CPU-intensive performance-critical things like
maintaining framerate in a complex game engine, or real-time software
where somebody dies if the program fails to respond within a 10ms
margin, or when you're trying to solve a PSPACE-complete exponential
problem where a 20ms difference in inner loop performance could mean the
difference between getting a result next week vs. next year (or next
millenium).

But if you're a stickler for high-performance code, gdc's optimizer far
outstrips dmd's in just about every way that I can think of -- more
aggressive inlining, better loop optimization, better codegen in
general.  And reputedly ldc has comparable performance gains over dmd as
well, so that's another option.  The only downside is that gdc releases
are tied to the gcc release cycle, so it tends to be about a version or
two behind mainline dmd, and ldc is about a version behind AFAIK.  But
as far as the basics of D are concerned, that shouldn't make a big
difference, unless you're unlucky enough to be bitten by a compiler bug
that has no workaround and that's only fixed in the latest dmd release.
Thankfully, though, compiler bugs of that sort have been quite rare (and
getting rarer with recent releases).



 One more thing I noticed when I looked into the executable file (using
 "nm -gU" on my mac) is that I found two interesting symbols - _main
 and _Dmain.  On Rust, for instance, the main function got turned into
 _main, so I couldn't use a main in the C code that I was trying to
 interop with from my Rust code. In this case, does the same
 restriction apply (I am still way too far from dabbling in interop in
 D as yet! :-)). I mean, suppose I write some sample code in C, and I
 have a local main function to test the code out locally, will I have
 to comment that out when invoking that library from D, or can I keep
 that as is?


_Dmain is the entry point of your D program, and is only emitted if you
have a main() function in your D code.  In that case, you'll want the
druntime version of _main (which does a bunch of setup necessary before
_Dmain is called).  But if you're calling D from C code, i.e., the C
code defines main(), then you wouldn't also write a main() in D code
(obviously -- I hope), though you *would* need to call a druntime hook
to initialize some D runtime things needed before you call any D code.
(Sorry, can't remember the exact calls off the top of my head, but it's
a simple matter of calling an init routine or two at startup, before
invoking any D code, then calling the cleanup routine at the end before
the program exits. Pretty standard stuff.)


T

-- 
Береги платье снову, а здоровье смолоду.
Feb 20 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Monday, 20 February 2017 at 17:36:32 UTC, H. S. Teoh wrote:

 On Mon, Feb 20, 2017 at 03:00:05PM +0000, timmyjose via 
 Digitalmars-d-learn wrote: [...]

 Just one question about the compilers though - I read on the 
 Wiki that there are three main compiler distros - dmd, ldc, 
 and gdc. I code primarily on a mac, and I have installed both 
 dmd and ldc. A lot of the flags appears to be similar, and for 
 my small programs, compilation and execution speed appeared to 
 be almost identical. However, the book suggested using dmd for 
 dev and probably ldc/gdc for releases. Is this really followed 
 that much in practice, or should I prefer dmd?


 Personally, I use dmd git HEAD for 90% of my D projects, 
 because (1) I'm such a sucker for the latest and greatest 
 features, bugfixes, language changes, etc., and (2) I 
 occasionally contribute to the compiler toolchain (mainly 
 Phobos, sometimes druntime or dmd itself) and it's much easier 
 to debug something I use on a regular basis and not have to 
 switch to a different version or waste time chasing down a 
 compiler bug that's already been fixed in git HEAD.


Thank you, that's great to hear! I have installed both dmd and 
ldc on my mac box and am experimenting with both as well :-)


 However, when I need performant code, I pull up my trusty, 
 rusty old gdc (which, unfortunately, tends to be about a 
 version or two behind the main dmd release -- I believe Iain is 
 working on improving this, though). In spite of Walter being a 
 renowned compiler genius, he simply has too many things on his 
 plate and working on the optimizer hasn't been a high priority, 
 so gdc's optimizer easily beats dmd (sometimes by a long 
 stretch).  Don't get me wrong; for your average desktop 
 application, dmd output is more than good enough. It only 
 really matters when you're dealing with CPU-intensive 
 performance-critical things like maintaining framerate in a 
 complex game engine, or real-time software where somebody dies 
 if the program fails to respond within a 10ms margin, or when 
 you're trying to solve a PSPACE-complete exponential problem 
 where a 20ms difference in inner loop performance could mean 
 the difference between getting a result next week vs. next year 
 (or next millenium).


That makes a whole lot of sense.


 But if you're a stickler for high-performance code, gdc's 
 optimizer far outstrips dmd's in just about every way that I 
 can think of -- more aggressive inlining, better loop 
 optimization, better codegen in general.  And reputedly ldc has 
 comparable performance gains over dmd as well, so that's 
 another option.  The only downside is that gdc releases are 
 tied to the gcc release cycle, so it tends to be about a 
 version or two behind mainline dmd, and ldc is about a version 
 behind AFAIK.  But as far as the basics of D are concerned, 
 that shouldn't make a big difference, unless you're unlucky 
 enough to be bitten by a compiler bug that has no workaround 
 and that's only fixed in the latest dmd release. Thankfully, 
 though, compiler bugs of that sort have been quite rare (and 
 getting rarer with recent releases).



 One more thing I noticed when I looked into the executable 
 file (using "nm -gU" on my mac) is that I found two 
 interesting symbols - _main and _Dmain.  On Rust, for 
 instance, the main function got turned into _main, so I 
 couldn't use a main in the C code that I was trying to interop 
 with from my Rust code. In this case, does the same 
 restriction apply (I am still way too far from dabbling in 
 interop in D as yet! :-)). I mean, suppose I write some sample 
 code in C, and I have a local main function to test the code 
 out locally, will I have to comment that out when invoking 
 that library from D, or can I keep that as is?





 _Dmain is the entry point of your D program, and is only 
 emitted if you have a main() function in your D code.  In that 
 case, you'll want the druntime version of _main (which does a 
 bunch of setup necessary before _Dmain is called).


Ah, I see. Now I understand why those two symbols are there!


But if you're calling D from C code, i.e., the C code defines 
main(),
 then you wouldn't also write a main() in D code (obviously -- I 
 hope), though you *would* need to call a druntime hook to 
 initialize some D runtime things needed before you call any D 
 code. (Sorry, can't remember the exact calls off the top of my 
 head, but it's a simple matter of calling an init routine or 
 two at startup, before invoking any D code, then calling the 
 cleanup routine at the end before the program exits. Pretty 
 standard stuff.)


 T


Got it! So you're saying that in case I want to call D code from 
C, then I do need to take care of some initialisation for the D 
runtime so that I can call the D library's code. That makes sense 
indeed.
Feb 21 2017
prev sibling next sibling parent sarn <sarn theartofmachinery.com> writes:
On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:

 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?


 Yes. Whenever a std function returns a new string or some such 
 it's going to be GC-allocated.


This particular problem isn't so bad as it might sound because D 
string functions are based on ranges.
Feb 18 2017
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:

 5. Supposing I devote the time and energy and get up to speed 
 on D, would the core language team be welcoming if I feel like 
 I can contribute?


 Absolutely. Anyone is welcome to contribute. D is very much a 
 volunteer effort. Also don't hesitate to point out (or even 
 fix) any stumbling blocks you may encounter when starting out.


I can't add more to this than two pointers:

https://wiki.dlang.org/Starting_as_a_Contributor
https://wiki.dlang.org/Get_involved
Feb 18 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 03:17:08 UTC, Seb wrote:

 On Saturday, 18 February 2017 at 21:09:20 UTC, ag0aep6g wrote:

 5. Supposing I devote the time and energy and get up to speed 
 on D, would the core language team be welcoming if I feel 
 like I can contribute?


 Absolutely. Anyone is welcome to contribute. D is very much a 
 volunteer effort. Also don't hesitate to point out (or even 
 fix) any stumbling blocks you may encounter when starting out.


 I can't add more to this than two pointers:

 https://wiki.dlang.org/Starting_as_a_Contributor
 https://wiki.dlang.org/Get_involved


Thanks, bookmarked! Hopefully I will be able to contribute some 
day.
Feb 20 2017
prev sibling next sibling parent reply sarn <sarn theartofmachinery.com> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 Hello folks,


Hi :)


 2. I am more interested in learning D as a pure systems 
 programming language so that I can develop my own tools (not 
 looking to develop an OS, just some grep-scale tools to start 
 off with). In that regard, I have a few concerns about the GC. 
 My rudimentary knowledge of the D ecosystem tells me that there 
 is a GC in D, but that can be turned off. Is this correct? 
 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?


Okay, yes, it's easy to turn off or control the GC.  It's also 
easy to control memory allocation in general (unlike, say, Java, 
where it's practically impossible to do anything without writing 
"new").

Also, yes, a lot of the standard library doesn't work if you do 
that.  A lot does work, but a lot doesn't.  The biggest blocker 
is the use of exceptions, which currently rely on GC (though 
there's interest in changing that).

But I think the real answer to your question is in this thread:
https://forum.dlang.org/thread/o6c9tj$2bdp$1 digitalmars.com
(Silicon Valley D Meetup - January 26, 2017 - "High Performance 
Tools in D" by Jon Degenhardt)


 In this regard, I am curious to know if I would face any issues 
 (with my intent in mind), or will I do just fine? If you could 
 share your experiences and domains of use, that would also be 
 very helpful for me. Secondly, how stable is the language and 
 how fast is the pace of development on D?


When I first started using D about four years ago, it was easy to 
hit compiler bugs and basic things that didn't work.  It don't 
find that happens much nowadays when I'm doing everyday 
programming.

There's plenty of new stuff happening, like escape analysis, but 
the foundation is getting pretty good.  I think the biggest gap 
is the number of libraries compared to, say, Python, but 
personally I'm happy binding to C libraries, and there are plenty 
of them.


 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively? I am a 
 relatively fast learner (and I learn better by context, as in, 
 some core unifying idea described and then elucidated through 
 big examples instead of learning in bits and pieces). How did 
 you folks learn D? I'm sure hearing your experiences would be 
 helpful too. Are there any books/video tutorials that you would 
 recommend (aside from this site itself).


Some people have written tutorials.  It sounds like you're 
already experienced with programming, so the fastest way is 
probably to just dive in.  Get the basics from a small tutorial, 
then pick a small project (or some practice programming problems) 
and start coding with the standard library docs on hand :)


 4. I have heard good reports of D's metaprogramming 
 capabilities (ironically enough, primarily from a thread on the 
 Rust user group), and coming from a Common Lisp (and some 
 Racket) background, I am deeply interested in this aspect. Are 
 D macros as powerful as Lisp macros? Are they semantically 
 similar (for instance, I found Rust's macros are quite similar 
 to Racket's)?


Lisp macros let you rewrite features at the interpreter level.  
Walter Bright has explicitly said he doesn't like that kind of 
macro (I don't think he even likes the C preprocessor's macros).

D's metaprogramming is more constrained in that sense, but it's 
powerful at code generation (see templates and the "mixin" 
keyword), compile-time code execution, and compile-time 
introspection.  Compile-time introspection is one of my favourite 
features.  If, for example, you need an array of all the names of 
single argument methods (or whatever) from a class, you can get 
it.

Take a look at ctRegex in the standard library for a great 
example of what can be done.


 5. Supposing I devote the time and energy and get up to speed 
 on D, would the core language team be welcoming if I feel like 
 I can contribute?


I'm not the core team, but I'm confident the answer is yes :)
Feb 18 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Saturday, 18 February 2017 at 21:27:55 UTC, sarn wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 [...]


 Hi :)


 [...]


 Okay, yes, it's easy to turn off or control the GC.  It's also 
 easy to control memory allocation in general (unlike, say, 
 Java, where it's practically impossible to do anything without 
 writing "new").

 Also, yes, a lot of the standard library doesn't work if you do 
 that.  A lot does work, but a lot doesn't.  The biggest blocker 
 is the use of exceptions, which currently rely on GC (though 
 there's interest in changing that).

 But I think the real answer to your question is in this thread:
 https://forum.dlang.org/thread/o6c9tj$2bdp$1 digitalmars.com
 (Silicon Valley D Meetup - January 26, 2017 - "High Performance 
 Tools in D" by Jon Degenhardt)


 [...]


 When I first started using D about four years ago, it was easy 
 to hit compiler bugs and basic things that didn't work.  It 
 don't find that happens much nowadays when I'm doing everyday 
 programming.

 There's plenty of new stuff happening, like escape analysis, 
 but the foundation is getting pretty good.  I think the biggest 
 gap is the number of libraries compared to, say, Python, but 
 personally I'm happy binding to C libraries, and there are 
 plenty of them.


 [...]


 Some people have written tutorials.  It sounds like you're 
 already experienced with programming, so the fastest way is 
 probably to just dive in.  Get the basics from a small 
 tutorial, then pick a small project (or some practice 
 programming problems) and start coding with the standard 
 library docs on hand :)


 [...]


 Lisp macros let you rewrite features at the interpreter level.  
 Walter Bright has explicitly said he doesn't like that kind of 
 macro (I don't think he even likes the C preprocessor's macros).

 D's metaprogramming is more constrained in that sense, but it's 
 powerful at code generation (see templates and the "mixin" 
 keyword), compile-time code execution, and compile-time 
 introspection.  Compile-time introspection is one of my 
 favourite features.  If, for example, you need an array of all 
 the names of single argument methods (or whatever) from a 
 class, you can get it.

 Take a look at ctRegex in the standard library for a great 
 example of what can be done.


 [...]


 I'm not the core team, but I'm confident the answer is yes :)


Wow! That was an excellent response. Thank you!

I'll be sure to check out the thread that you linked in detail (a 
lot of it went over my head, but I'm sure it'll all make more 
sense soon). I also managed to dig out the YouTube link from 
there. :-)

Also, thanks for sharing your experience. It really does help. I 
was a bit apprehensive because these days rather than the effort, 
I'm more concerned with the time invested (who isn't, right?), 
and reading that your experience with D helps put me at ease.

About metaprogramming, yes, that is one part that I'm really 
interested in, and I would love to explore that area 
thoroughly!The introspection example is pretty cool! I'm pretty 
sure I'll have tons of questions once I get going with D, and the 
community has been very welcoming so far! :-)
Feb 18 2017
prev sibling next sibling parent reply Daniel Kozak via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
Dne 18.2.2017 v 21:15 timmyjose via Digitalmars-d-learn napsal(a):


 Hello folks,

 I am interested in learning D (just starting out, did a few of the 
 exercises on the D tour), and had some questions before I decide to 
 jump right in. My questions are genuinely motivated by my experiences 
 and expectations, so please forgive me if some questions don't come 
 across as well as my intentions!

 1. I have some experience with both C and C++, and have been learning 
 Rust for a while, but a few things put me off about the whole business -

 a). The core language appears to be simple enough, but becomes 
 increasingly complex as I begin writing larger programs.

 b). The whole ownership system is easy to understand, but the APIs 
 become very complicated and unwieldy, and more time appears to be 
 spent on understanding and ensuring that memory is being used 
 correctly than on the core program logic.

 c). The whole community seems infused with both the Feminism/SJW (I 
 don't care about those communities, but it feels weird having a 
 programming community get sidetracked by all that bullshit), and too 
 much of Ruby-on-Rails culture (probably started with Steve Klabnik) so 
 that it doesn't feel like any real systems programmers are focusing on 
 that language, and finally, d). The whole language feels like a bit of 
 patchwork of random ideas, and also the whole "safety" and "no 
 segfaults" guarantees seem to have lesser and lesser RoI as time goes by.

 Sorry for the rant, I didn't realise I was quite that frustrated! 
 That's just to give some background about me and my recent 
 experiences! :D

 In that regard, I suppose I'll get a better feel of the community here 
 as I interact more, but I have high hopes that it'll be much more 
 technical than purely social!


Hi, welcome in D community

 2. I am more interested in learning D as a pure systems programming 
 language so that I can develop my own tools (not looking to develop an 
 OS, just some grep-scale tools to start off with). In that regard, I 
 have a few concerns about the GC. My rudimentary knowledge of the D 
 ecosystem tells me that there is a GC in D, but that can be turned 
 off. Is this correct? Also, some threads online mention that if we do 
 turn off GC, some of the core std libraries may not fully work. Is 
 this presumption also correct? In this regard, I am curious to know if 
 I would face any issues (with my intent in mind), or will I do just 
 fine? If you could share your experiences and domains of use, that 
 would also be very helpful for me


Yes, by default D use GC. And yes there is a some part of D standard 
library which uses GC. But it is something you can avoid if you want. I 
am using D for many years and for almost anything and never have issue 
with GC.


 Secondly, how stable is the language and how fast is the pace of 
 development on D?

 Again, sorry for my ignorance if I have been wrong-footed on some (or 
 all) points.


D stability is good, really good, for many of us too good :P. I have 
been using D for many years (five or six). And right now there is a big 
effort to never break anything until it makes really sense.

OTOH D development is quite fast. So there are many improvements with 
every release


 2. I am also curious as to what would be the best path for a complete 
 beginner to D to learn it effectively? I am a relatively fast learner 
 (and I learn better by context, as in, some core unifying idea 
 described and then elucidated through big examples instead of learning 
 in bits and pieces). How did you folks learn D? I'm sure hearing your 
 experiences would be helpful too. Are there any books/video tutorials 
 that you would recommend (aside from this site itself).


I can't help here because I am using D for a long time, so I do not 
remember how I have learned it.

 3. Are there some small-scale Open Source projects that you would 
 recommend to peruse to get a feel for and learn idiomatic D?


It is maybe not small-scale but idiomatic D code is in phobos itself.


 4. I have heard good reports of D's metaprogramming capabilities 
 (ironically enough, primarily from a thread on the Rust user group), 
 and coming from a Common Lisp (and some Racket) background, I am 
 deeply interested in this aspect. Are D macros as powerful as Lisp 
 macros? Are they semantically similar (for instance, I found Rust's 
 macros are quite similar to Racket's)?


I do not know Lisp macros, but AFAIK there are not semantically similar. 
OTOH D metaprogramming is really powerful and there has been some 
proposals to improve that https://wiki.dlang.org/DIP50

 5. Supposing I devote the time and energy and get up to speed on D, 
 would the core language team be welcoming if I feel like I can 
 contribute?

 That's all off the top of my head at the moment. Perhaps I'll have 
 more questions as I read the responses. Thanks in advance!

 Cheers.
Feb 18 2017
parent reply timmyjose <zoltan.jose gmail.com> writes:
On Saturday, 18 February 2017 at 21:51:34 UTC, Daniel Kozak wrote:

 Dne 18.2.2017 v 21:15 timmyjose via Digitalmars-d-learn 
 napsal(a):


 [...]


 Hi, welcome in D community


Thank you! I'm glad to be part of this excellent community!


[...]


 Yes, by default D use GC. And yes there is a some part of D 
 standard library which uses GC. But it is something you can 
 avoid if you want. I am using D for many years and for almost 
 anything and never have issue with GC.


 [...]


 D stability is good, really good, for many of us too good :P. I 
 have been using D for many years (five or six). And right now 
 there is a big effort to never break anything until it makes 
 really sense.


That makes sense.


 OTOH D development is quite fast. So there are many 
 improvements with every release


That sounds very good indeed!


 [...]


 I can't help here because I am using D for a long time, so I do 
 not remember how I have learned it.


Hahaha! Yes, thanks for the honesty. It does make sense because 
once you've been working in some field for some time, it does 
make it harder to explain how exactly you reached that level. In 
that regard, comments from fellow newbies (such as berni) have 
been quite helpful since they're at the same stage as me.


 [...]


 It is maybe not small-scale but idiomatic D code is in phobos 
 itself.


Interesting! I checked out the link that ag0aep6g had shared, and 
I realised that Phobos is the name of the standard library 
itself. It should make for some interesting reading once I get 
the basics down.


 [...]


 I do not know Lisp macros, but AFAIK there are not semantically 
 similar. OTOH D metaprogramming is really powerful and there 
 has been some proposals to improve that 
 https://wiki.dlang.org/DIP50


Indeed. I'm very much looking forward to learning this powerful 
template system very well!


 [...]
Feb 19 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
timmyjose wrote:

 I can't help here because I am using D for a long time, so I do not 
 remember how I have learned it.


 Hahaha! Yes, thanks for the honesty. It does make sense because once 
 you've been working in some field for some time, it does make it 
 harder to explain how exactly you reached that level. In that regard, 
 comments from fellow newbies (such as berni) have been quite helpful 
 since they're at the same stage as me.


as for me, i basically just jumped into D and started to code. sure, i 
read a little about modules, GC, slices, and such basic things, but 
then i just started to writing my code in D. one can use libc from D 
(with some care), so it allowed me to write in D as in "C dialect", and 
then gradually make my code more "D-like", as i learned more and more 
things.
Feb 19 2017
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 My rudimentary knowledge of the D ecosystem tells me that there 
 is a GC in D, but that can be turned off. Is this correct?


Technically yes; you will lose core functionality, though, if you 
do.
I don't have the complete list at hand, but e.g. dynamic and 
associative arrays are one of the things you won't be able to use 
without the GC IIRC. If you use the reference compiler (dmd), you 
can use the flag `-vgc` to be shown all the GC allocations in a D 
program.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?


Yes. Everything in Phobos that uses features depending on the GC 
won't work anymore.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 In this regard, I am curious to know if I would face any issues 
 (with my intent in mind), or will I do just fine?


If you don't turn the GC off you should be fine. The GC will - 
AFAIK - only perform a collection cycle as a result of an 
allocation call to it, so you can avoid slow collection cycles 
without turning it off.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 If you could share your experiences and domains of use, that 
 would also be very helpful for me.


I mostly use D for writing tools for my own use that have to 
interact with C APIs.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 Secondly, how stable is the language and how fast is the pace 
 of development on D?


The parts of the language I need are pretty stable, but I don't 
think I use even half of what the language offers (D is very 
complex).
Regarding speed, you can see the numbers (git tags) for yourself 
here[0].

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively?


That's usually not something someone can tell you, since every 
person learns differently.
Personally, when I started with D (back in D1 days) I read the 
articles about it and then just tried writing tools in it, so I 
suggest reading these[1]

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 I am a relatively fast learner (and I learn better by context, 
 as in, some core unifying idea described and then elucidated 
 through big examples instead of learning in bits and pieces).


I'd describe D's unifying idea as "allow people to write complex, 
native software without all the C/C++ insanity". Though D comes 
with it's own share of insanity, of course.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 Are there any books/video tutorials that you would recommend 
 (aside from this site itself).


I personally would not recommend books at the very start of 
learning a language (if one is already proficient with native 
programming in general), but only after one has already gotten 
comfortable with it and is looking for a comprehensive overview.
Regardless, I've heard good things about two books[2][3].
Since I loathe video tutorials I can't add anything on that point.

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 3. Are there some small-scale Open Source projects that you 
 would recommend to peruse to get a feel for and learn idiomatic 
 D?


Technically there's no such thing as idiomatic D as D is 
multi-paradigm. You can see some sensible idioms here[4], but no, 
I would not recommend reading anyone's D code just to get a 
feeling for "idiomatic D".

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 4. I have heard good reports of D's metaprogramming 
 capabilities (ironically enough, primarily from a thread on the 
 Rust user group),


This doesn't surprise me, honestly, since Rust's (compile time) 
metaprogramming capabilities are below D's and from my experience 
people in both communities are well aware of that. There are 
threads on Reddit about this topic if you have the time to dig 
them up. D's advanced compile time features are one of the main 
reasons I'm unlikely to switch to anything else for my tools (in 
my experience there is no other native programming language that 
let's me get things done as fast - in terms of development time - 
as D).

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 and coming from a Common Lisp (and some  Racket) background, I 
 am deeply interested in this aspect. Are  D macros as powerful 
 as Lisp macros? Are they semantically similar (for instance, I 
 found Rust's macros are quite similar to Racket's)?


D does not have macros, it has compile time function 
execution[5], templates[6],
  mixins[7], and template mixins[8].

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 5. Supposing I devote the time and energy and get up to speed 
 on D, would the core language team be welcoming if I feel like 
 I can contribute?


I have never tried adding something to druntime or phobos myself, 
so I'm not in a position to comment on this.

[0] https://github.com/dlang/phobos/releases
[1] http://dlang.org/articles.html
[2] The D Programming Language, Andrei Alexandrescu
[3] Programming in D: Tutorial and Reference, Ali Cehreli
[4] https://p0nce.github.io/d-idioms/
[5] 
https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe
[6] http://dlang.org/templates-revisited.html
[7] http://dlang.org/mixin.html
[8] http://dlang.org/spec/template-mixin.html
Feb 18 2017
prev sibling next sibling parent reply berni <berni example.com> writes:
I'm new here too (never heard of D before 2017).


 c). The whole community seems infused with both the Feminism/SJW


I didn't tried out Rust, but that would draw me away too. 
(Incidentally it was a comment on alternatives for Rust, that 
pointed me to D.)


 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively?


I started with the online version of the book of Ali Çehreli but 
after a while I decided to buy it and was impressed on its size 
(more than 700 pages!). Meanwhile I'm halfway through.

At the same time I'm working on a project of mine, which I just 
started writing in C++ last december, because I couldn't find a 
better language and thought I had to bite the bullet. Meanwhile 
it's completely rewritten in D (but two lines of C code that I 
need to use a C-libraray). Whenever I came across a new concept 
in the book I tried to refactor that project using this concept.

This approach worked very well for me. (And I appreciate this 
Learn-forum, because else I'd not dare to ask my seemingly silly 
questions.)

You wrote:

 ... area thoroughly!The introspection ...


I just realised, how much I'm thinking in D allready when I saw 
this: At first glance I wondered, what this thoroughly-template 
is about... ;-)
Feb 18 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Saturday, 18 February 2017 at 22:17:30 UTC, berni wrote:

 I'm new here too (never heard of D before 2017).


Glad to meet someone else new here! :-)


 c). The whole community seems infused with both the 
 Feminism/SJW


 I didn't tried out Rust, but that would draw me away too. 
 (Incidentally it was a comment on alternatives for Rust, that 
 pointed me to D.)


Absolutely! At first it didn't bother me so much, but when I 
started hanging out of the Rust user groups, I saw the evil side 
of this. People who raised this issues were being castigated and 
publicly ridiculed. That was too much even for me (I'm usually 
the "live and let live" kind of person) because it showed that 
the community over there appeared more interested in such side 
issues than focusing on building up a community based on 
technical sharing and solving technical problems. Very offputting.


 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively?


 I started with the online version of the book of Ali Çehreli 
 but after a while I decided to buy it and was impressed on its 
 size (more than 700 pages!). Meanwhile I'm halfway through.


Hehe. I'm also doing the same... a few chapters in and it's 
smooth sailing so far!


 At the same time I'm working on a project of mine, which I just 
 started writing in C++ last december, because I couldn't find a 
 better language and thought I had to bite the bullet. Meanwhile 
 it's completely rewritten in D (but two lines of C code that I 
 need to use a C-libraray). Whenever I came across a new concept 
 in the book I tried to refactor that project using this concept.


Very nice! :-)


 This approach worked very well for me. (And I appreciate this 
 Learn-forum, because else I'd not dare to ask my seemingly 
 silly questions.)

 You wrote:

 ... area thoroughly!The introspection ...


 I just realised, how much I'm thinking in D allready when I saw 
 this: At first glance I wondered, what this thoroughly-template 
 is about... ;-)


Hahaha!
Feb 19 2017
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 My rudimentary knowledge of the D ecosystem tells me that there 
 is a GC in D, but that can be turned off. Is this correct? 
 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?


The topic is complex, there are a lot of mitigation techniques.

A - for most real-time programs, you may want to keep the GC heap 
under 200kb. A combination of GC profiling, using values types, 
and manual memory management can get you there.  nogc also helps.

B - some real-time threads don't like to be paused (audio). You 
can unregister them from the runtime which means the GC won't 
stop them on collection. On the other hand this thread won't be 
able to "own" collectable things.

C - finally you can either disable the runtime/GC altogether, or 
not link with it. This create the most effort but with a 
guarantee of not having a GC over the whole application. In most 
cases it's _not worth it_.

The hard part about GC is understanding reachability, but unless 
you are doing very systemy, this can be safely ignored.

You will be just fine.


 Secondly, how stable is the language and how fast is the pace 
 of development on D?


Language doesn't break nowadays, very stable apart from dreaded 
regressions with the DMD backends.

http://erdani.com/d/downloads.daily.png


 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively?


"Learning D" book seems fitting.


 3. Are there some small-scale Open Source projects that you 
 would recommend to peruse to get a feel for and learn idiomatic 
 D?


I run https://p0nce.github.io/d-idioms/ to get up to speed with 
the weird idiosyncrasies fast. But the above book is way better.
Feb 19 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 12:40:10 UTC, Guillaume Piolat 
wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 My rudimentary knowledge of the D ecosystem tells me that 
 there is a GC in D, but that can be turned off. Is this 
 correct? Also, some threads online mention that if we do turn 
 off GC, some of the core std libraries may not fully work. Is 
 this presumption also correct?


 The topic is complex, there are a lot of mitigation techniques.

 A - for most real-time programs, you may want to keep the GC 
 heap under 200kb. A combination of GC profiling, using values 
 types, and manual memory management can get you there.  nogc 
 also helps.

 B - some real-time threads don't like to be paused (audio). You 
 can unregister them from the runtime which means the GC won't 
 stop them on collection. On the other hand this thread won't be 
 able to "own" collectable things.

 C - finally you can either disable the runtime/GC altogether, 
 or not link with it. This create the most effort but with a 
 guarantee of not having a GC over the whole application. In 
 most cases it's _not worth it_.

 The hard part about GC is understanding reachability, but 
 unless you are doing very systemy, this can be safely ignored.

 You will be just fine.


 Secondly, how stable is the language and how fast is the pace 
 of development on D?


 Language doesn't break nowadays, very stable apart from dreaded 
 regressions with the DMD backends.

 http://erdani.com/d/downloads.daily.png


 2. I am also curious as to what would be the best path for a 
 complete beginner to D to learn it effectively?


 "Learning D" book seems fitting.


 3. Are there some small-scale Open Source projects that you 
 would recommend to peruse to get a feel for and learn 
 idiomatic D?


 I run https://p0nce.github.io/d-idioms/ to get up to speed with 
 the weird idiosyncrasies fast. But the above book is way better.


Thanks for your response! I actually started out with 
"Programming in D", but found it more oriented towards people new 
to programming. I am currently working through "Learning D", and 
it's been a real pleasure so far! Thanks for the recommendation.
Feb 20 2017
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 4. I have heard good reports of D's metaprogramming 
 capabilities (ironically enough, primarily from a thread on the 
 Rust user group), and coming from a Common Lisp (and some 
 Racket) background, I am deeply interested in this aspect. Are 
 D macros as powerful as Lisp macros? Are they semantically 
 similar (for instance, I found Rust's macros are quite similar 
 to Racket's)?


I was a Scheme/Common Lisp user for quite a while before moving 
to D. Lisp macros are more powerful (there's not much you can't 
do with them), but on the other hand, unless you stick with 
simple use cases, it can be hard to get Lisp macros right. You've 
got the whole defmacro vs hygienic debate. Also, the rule of 
thumb is to avoid macros unless you can't do it with a function.

I was never into heavy metaprogramming with Scheme or Common 
Lisp. The simplicity of D's compile time capabilities mean I do 
more metaprogramming in D, and I actually push a lot of stuff 
from runtime to compile time, which I wouldn't have done with 
Common Lisp.
Feb 19 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Sunday, 19 February 2017 at 15:22:50 UTC, bachmeier wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 4. I have heard good reports of D's metaprogramming 
 capabilities (ironically enough, primarily from a thread on 
 the Rust user group), and coming from a Common Lisp (and some 
 Racket) background, I am deeply interested in this aspect. Are 
 D macros as powerful as Lisp macros? Are they semantically 
 similar (for instance, I found Rust's macros are quite similar 
 to Racket's)?


 I was a Scheme/Common Lisp user for quite a while before moving 
 to D. Lisp macros are more powerful (there's not much you can't 
 do with them), but on the other hand, unless you stick with 
 simple use cases, it can be hard to get Lisp macros right. 
 You've got the whole defmacro vs hygienic debate. Also, the 
 rule of thumb is to avoid macros unless you can't do it with a 
 function.


Agreed.


 I was never into heavy metaprogramming with Scheme or Common 
 Lisp. The simplicity of D's compile time capabilities mean I do 
 more metaprogramming in D, and I actually push a lot of stuff 
 from runtime to compile time, which I wouldn't have done with 
 Common Lisp.


That's very encouraging to hear! :-)
Feb 20 2017
prev sibling parent reply Steve Biedermann <steve.biedermann.privat gmail.com> writes:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 2. I am more interested in learning D as a pure systems 
 programming language so that I can develop my own tools (not 
 looking to develop an OS, just some grep-scale tools to start 
 off with). In that regard, I have a few concerns about the GC. 
 My rudimentary knowledge of the D ecosystem tells me that there 
 is a GC in D, but that can be turned off. Is this correct? 
 Also, some threads online mention that if we do turn off GC, 
 some of the core std libraries may not fully work. Is this 
 presumption also correct?

 In this regard, I am curious to know if I would face any issues 
 (with my intent in mind), or will I do just fine? If you could 
 share your experiences and domains of use, that would also be 
 very helpful for me. Secondly, how stable is the language and 
 how fast is the pace of development on D?

 Again, sorry for my ignorance if I have been wrong-footed on 
 some (or all) points.


I'm using D for small tools for about a year now and I never had 
to mess with GC. Most of the tools don't need to work on GBs of 
data and performance has always been good enough.

My "biggest" D tool is a custom scriptable code generator based 
on lua and sdl (sdlang.org) and even though it's implemented 
really badly, it performs good enough to be used in development 
(Currently we generate JSON serialization code for delphi with 
it).

I also wrote a simple parser for parsing delphi memory leak 
reports to show some statistics. Depending on how many leaks you 
have, these can get a bit larger, but I always got good enough 
performance with D.

Last tool I want to mention is a binary log file parser, which 
reads an proprietary log file and converts it into json. And even 
this is extremely fast.

So I don't think GC will be a big problem for smaller tools.
Feb 21 2017
parent reply timmyjose <zoltan.jose gmail.com> writes:
On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann 
wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 [...]


 I'm using D for small tools for about a year now and I never 
 had to mess with GC. Most of the tools don't need to work on 
 GBs of data and performance has always been good enough.

 [...]


I would upvote you if I could! :-) ... that's not only an 
interesting read, but also fodder for mini-projects of my own!
Feb 21 2017
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 02/21/2017 09:13 AM, timmyjose wrote:

 On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

 [...]


 I'm using D for small tools for about a year now and I never had to
 mess with GC. Most of the tools don't need to work on GBs of data and
 performance has always been good enough.

 [...]


 I would upvote you if I could! :-) ... that's not only an interesting
 read, but also fodder for mini-projects of my own!


Making sure that you've seen the link that sarn had posted earlier in 
this thread:


 https://forum.dlang.org/thread/o6c9tj$2bdp$1 digitalmars.com
 (Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools 


in D" by Jon Degenhardt)

Jon Degenhardt has been writing multiple times faster running tools just 
by (almost) casual D coding. (Hopefully he will write a blog post about 
his experiences soon.)

Ali
Feb 21 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Tuesday, 21 February 2017 at 19:55:37 UTC, Ali Çehreli wrote:

 On 02/21/2017 09:13 AM, timmyjose wrote:

 On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann 
 wrote:

 On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose 
 wrote:

 [...]


 I'm using D for small tools for about a year now and I never 
 had to
 mess with GC. Most of the tools don't need to work on GBs of 
 data and
 performance has always been good enough.

 [...]


 I would upvote you if I could! :-) ... that's not only an 
 interesting
 read, but also fodder for mini-projects of my own!


 Making sure that you've seen the link that sarn had posted 
 earlier in this thread:


 https://forum.dlang.org/thread/o6c9tj$2bdp$1 digitalmars.com
 (Silicon Valley D Meetup - January 26, 2017 - "High


 Performance Tools in D" by Jon Degenhardt)

 Jon Degenhardt has been writing multiple times faster running 
 tools just by (almost) casual D coding. (Hopefully he will 
 write a blog post about his experiences soon.)

 Ali


I had a chance to get around to watching the video at last. Very 
interesting, and grand job on the interview. Things like these 
will definitely help increase the community. More and more people 
should start creating content (no matter how small or big), and 
that will pique people's curiosity! :-)
Feb 21 2017
prev sibling parent reply Steve Biedermann <steve.biedermann.privat gmail.com> writes:
On Tuesday, 21 February 2017 at 17:13:30 UTC, timmyjose wrote:

 I would upvote you if I could! :-) ... that's not only an 
 interesting read, but also fodder for mini-projects of my own!


If you need more details about a specific topic, just post it in 
the forum and we will try to help :)

If you want some sourcecode to look at you can write me a mail 
and I can give you access to some of my tools. The ones which are 
stored on bitbucket are pretty simple to understand, but not 
quite ready for public release (no polishing etc.).
Feb 21 2017
parent timmyjose <zoltan.jose gmail.com> writes:
On Wednesday, 22 February 2017 at 07:48:42 UTC, Steve Biedermann 
wrote:

 On Tuesday, 21 February 2017 at 17:13:30 UTC, timmyjose wrote:

 I would upvote you if I could! :-) ... that's not only an 
 interesting read, but also fodder for mini-projects of my own!


 If you need more details about a specific topic, just post it 
 in the forum and we will try to help :)

 If you want some sourcecode to look at you can write me a mail 
 and I can give you access to some of my tools. The ones which 
 are stored on bitbucket are pretty simple to understand, but 
 not quite ready for public release (no polishing etc.).


Thanks, Steve. That'd be great! I will surely take you up on that 
offer. Right now I'm working through "Learning D", and loving 
every bit of it! From there I plan to get right down to coding on 
some small but interesting projects, and any help I can get would 
be most welcome! :-)
Feb 22 2017