www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Random points from a D n00b CTO

reply "Vic" <vic.cvc gmx.com> writes:
Hi all,
I'm a CTO at a start up and interested in porting our Java 
project to D. Some points, I have been lurking on D for years, 
went to my first D conf recently. Also I was one of top 20 people 
to join Java Struts, and that grew to 3million plus end users so 
I have some 'cred'. Hope this helps:

- Confusing forum. First listed forum on 'D' is not for D users, 
but it's called D! It is in fact for D commiters. This causes 
frustration for both users and commiters. (yes there is 'learn D' 
but it's 4th down. Commiters forum should be slightly hidden and 
user questions should not be answered in commuters but politely 
asked to post in the proper forum.).

- I was *very* disappointed that using base library locks you 
into GC vs ref. counting.
Separate, I like how Objective C has NSObject for GC purpose(I'd 
love a framework that is just ref counting), but there should be 
dual libs and base should not be GC.

- D is/has become complex. metaprograming, generics, macros, etc. 
This is a culture issue, very hard to fix cultural issues w/o 
losing most commiters. Just a fast system lang w/o headers, 
'boost' and such. All this other stuff can be 3rd party eco 
system and should be pushed out from D proper into 
implementations and add ons.

- Dub rocks.

- Very little 'user' outreach. Meetups such as 'learn D'  (set up 
editor w/ DUB, and write some vibe.d DNS client/server in 4 
lessons). Or how to use a c .so lib.

So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not 
commuters) to rewrite the Java project in Dallas and/or San Jose 
(CA) over the next few months (Feel free to ping me 
 puppetMaster3, ideal candidate is 'prolific' and career 
programmer)

Cheers, Vic
Jul 13 2014
next sibling parent "Vic" <vic.cvc gmx.com> writes:
commuters = commiters.

On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
<snip>
Jul 13 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/07/2014 3:55 p.m., Vic wrote:
 Hi all,
 I'm a CTO at a start up and interested in porting our Java project to D.
 Some points, I have been lurking on D for years, went to my first D conf
 recently. Also I was one of top 20 people to join Java Struts, and that
 grew to 3million plus end users so I have some 'cred'. Hope this helps:

 - Confusing forum. First listed forum on 'D' is not for D users, but
 it's called D! It is in fact for D commiters. This causes frustration
 for both users and commiters. (yes there is 'learn D' but it's 4th down.
 Commiters forum should be slightly hidden and user questions should not
 be answered in commuters but politely asked to post in the proper forum.).
Maybe we can make it more prominent. Or at least add it to the front page more obviously.
 - I was *very* disappointed that using base library locks you into GC vs
 ref. counting.
 Separate, I like how Objective C has NSObject for GC purpose(I'd love a
 framework that is just ref counting), but there should be dual libs and
 base should not be GC.
Lets wait for allocators and the like.
 - D is/has become complex. metaprograming, generics, macros, etc. This
 is a culture issue, very hard to fix cultural issues w/o losing most
 commiters. Just a fast system lang w/o headers, 'boost' and such. All
 this other stuff can be 3rd party eco system and should be pushed out
 from D proper into implementations and add ons.
Ehh meta programming, CTFE ext. is one of the most fundamental aspects of D. I'm sure a lot of people would hate not having it. In fact its one of the things that makes it actually desirable.
 - Dub rocks.

 - Very little 'user' outreach. Meetups such as 'learn D'  (set up editor
 w/ DUB, and write some vibe.d DNS client/server in 4 lessons). Or how to
 use a c .so lib.
I was considering something like this for ApplyYourDlang youtube channel[0]. But more Lets learn how to use Cmsed to create a wiki! And then I had to actually make the damn framework do the things they would need. Maybe in a few months time I can get back to it. But if anybody wants to make more videos other than me and Simen Endsjø, let me know. I can add you to the channel.
 So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not
 commuters) to rewrite the Java project in Dallas and/or San Jose (CA)
 over the next few months (Feel free to ping me  puppetMaster3, ideal
 candidate is 'prolific' and career programmer)
Definitely would be interested, if you wanted somebody who's currently finishing a degree from New Zealand (perfect time next semester is Industry project where I work with them). Assuming my current plan falls through.
 Cheers, Vic
[0] https://www.youtube.com/channel/UCz3NlrGpjV9NlJAhKJLu_-w
Jul 13 2014
prev sibling next sibling parent reply "uri" <email ether.com> writes:
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
 Hi all,
 I'm a CTO at a start up and interested in porting our Java 
 project to D. Some points, I have been lurking on D for years, 
 went to my first D conf recently. Also I was one of top 20 
 people to join Java Struts, and that grew to 3million plus end 
 users so I have some 'cred'. Hope this helps:

 - Confusing forum. First listed forum on 'D' is not for D 
 users, but it's called D! It is in fact for D commiters. This 
 causes frustration for both users and commiters. (yes there is 
 'learn D' but it's 4th down. Commiters forum should be slightly 
 hidden and user questions should not be answered in commuters 
 but politely asked to post in the proper forum.).
I agree. It doesn't bother me personally, but I think the discussions about lang design etc. should be under "D Programming Language - Development". A new user might be put off by all the heated discussion about the language design and get the impression D is still in flux.
 - I was *very* disappointed that using base library locks you 
 into GC vs ref. counting.
 Separate, I like how Objective C has NSObject for GC 
 purpose(I'd love a framework that is just ref counting), but 
 there should be dual libs and base should not be GC.
This topic was bashed to death. There were compelling arguments from both sides, but in the end no one pushing for ARC could produce evidence that it was better than GC. Currently there's a big push to remove hidden GC allocs from Phobos, starting with nogc. std.allocators is just around the corner as well, which will provide a solid framework to build better allocation strategies.
 - D is/has become complex. metaprograming, generics, macros, 
 etc. This is a culture issue, very hard to fix cultural issues 
 w/o losing most commiters. Just a fast system lang w/o headers, 
 'boost' and such. All this other stuff can be 3rd party eco 
 system and should be pushed out from D proper into 
 implementations and add ons.
This is why I use D. After many years in C++ I am not fond of templates but in D they are almost transparent and so simple to use. They provide amazing code reuse and CTFE for almost zero additional complexity over run-time code.
 - Dub rocks.
That is does, although I still use CMake :)
 - Very little 'user' outreach. Meetups such as 'learn D'  (set 
 up editor w/ DUB, and write some vibe.d DNS client/server in 4 
 lessons). Or how to use a c .so lib.

 So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not 
 commuters) to rewrite the Java project in Dallas and/or San 
 Jose (CA) over the next few months (Feel free to ping me 
  puppetMaster3, ideal candidate is 'prolific' and career 
 programmer)

 Cheers, Vic
Good luck! Thankfully I can use D at work now, if I couldn't you would have my CV within the hour :-) Cheers, uri
Jul 13 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 July 2014 14:47, uri via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:

 - I was *very* disappointed that using base library locks you into GC vs
 ref. counting.
 Separate, I like how Objective C has NSObject for GC purpose(I'd love a
 framework that is just ref counting), but there should be dual libs and
 base should not be GC.
This topic was bashed to death. There were compelling arguments from both sides, but in the end no one pushing for ARC could produce evidence that it was better than GC.
Andrei himself pushed such evidence in an interesting case study that explored a high-end ARC implementation. It compared impressively with 'the fastest GC's' (or some description very close to that). D's GC is certainly not among those in comparison, which suggested the paper's tech would probably be a win for D no matter how you look at it. And the counter evidence is overwhelming. As many times as I've asked the experts for comment, I've still *NEVER* heard anybody disagree that D's GC will probably remain really bad for the indefinite future. Even the ones that are strongly in favour of GC; nobody seems to know how to do it, and many have said it's probably impossible. Even if it was theoretically possible, that only solves one of numerous problems... Nobody has ever addressed the low-available-memory argument I've put forward a number of times, which is the standard operating environment of most embedded computers. So, I don't feel like there was any such conclusion as you suggest. Personally, I just became horribly apathetic and gave up. My general participation and motivation in this community has declined significantly as a result. I'm among the minority that REALLY care about this, and it's clear (and it's been made clear) that if I'm not prepared to work on it myself, then it won't move forward. That's fine, and it's perfectly reasonable. But I'm not in the least bit interested in working on GC technology myself - I'm not an expert, and it's not a field that interests me, thus I decided to desist participating in discussions. Currently there's a big push to remove hidden GC allocs from
 Phobos, starting with  nogc.

 std.allocators is just around the corner as well, which will
 provide a solid framework to build better allocation strategies.
We're yet to see how to use the allocators API to specify a replacement default allocator used by the languages intrinsic allocations, which makes it rather less exciting. Anyone can invent an allocator interface, but designing it such that it can be used to configure the languages implicit allocations is much more complex. I'm concerned that Andrei's allocator interface doesn't actually address this... At least, I haven't seen any discussion about how it will. That said, I'm not trying to down-play the importance of a standard allocator API, and Andrei's development is very important and appreciated, but I am yet to find out how it actually addresses any of my real concerns relating to allocation. As I see it, I have zero concern about allocations I control. I am entirely concerned with intrinsic/implicit allocations that I don't, and may potentially (likely) originate from within 3rd party libraries.
Jul 13 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d 
wrote:
 explored a high-end ARC implementation. It compared 
 impressively with 'the fastest GC's' (or some description
 very close to that). D's GC  is certainly
 not among those in comparison, which suggested the paper's tech 
 would probably be a win for D no matter how you look at it.
I think both ARC and fast GC in a C-like language requires a dedicated pointer type, adjustments to semantics and whole program analysis. The general unwillingness to clean up the language and tighten the language semantics is going to keep D frozen at the current performance level for managed allocations…
 problems... Nobody has ever addressed the low-available-memory 
 argument
 I've put forward a number of times, which is the standard 
 operating
 environment of most embedded computers.
It's true that neither GC or region based allocators are good for tight memory allocation, but that extends to NSAutoReleasePool in iOS also.
Jul 14 2014
prev sibling next sibling parent "uri" <email ether.com> writes:
On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d 
wrote:
 On 14 July 2014 14:47, uri via Digitalmars-d 
 <digitalmars-d puremagic.com>
 wrote:

 On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:

 - I was *very* disappointed that using base library locks you 
 into GC vs
 ref. counting.
 Separate, I like how Objective C has NSObject for GC 
 purpose(I'd love a
 framework that is just ref counting), but there should be 
 dual libs and
 base should not be GC.
This topic was bashed to death. There were compelling arguments from both sides, but in the end no one pushing for ARC could produce evidence that it was better than GC.
Andrei himself pushed such evidence in an interesting case study that explored a high-end ARC implementation. It compared impressively with 'the fastest GC's' (or some description very close to that). D's GC is certainly not among those in comparison, which suggested the paper's tech would probably be a win for D no matter how you look at it. And the counter evidence is overwhelming. As many times as I've asked the experts for comment, I've still *NEVER* heard anybody disagree that D's GC will probably remain really bad for the indefinite future. Even the ones that are strongly in favour of GC; nobody seems to know how to do it, and many have said it's probably impossible. Even if it was theoretically possible, that only solves one of numerous problems... Nobody has ever addressed the low-available-memory argument I've put forward a number of times, which is the standard operating environment of most embedded computers. So, I don't feel like there was any such conclusion as you suggest. Personally, I just became horribly apathetic and gave up. My general participation and motivation in this community has declined significantly as a result. I'm among the minority that REALLY care about this, and it's clear (and it's been made clear) that if I'm not prepared to work on it myself, then it won't move forward. That's fine, and it's perfectly reasonable. But I'm not in the least bit interested in working on GC technology myself - I'm not an expert, and it's not a field that interests me, thus I decided to desist participating in discussions. Currently there's a big push to remove hidden GC allocs from
 Phobos, starting with  nogc.

 std.allocators is just around the corner as well, which will
 provide a solid framework to build better allocation 
 strategies.
We're yet to see how to use the allocators API to specify a replacement default allocator used by the languages intrinsic allocations, which makes it rather less exciting. Anyone can invent an allocator interface, but designing it such that it can be used to configure the languages implicit allocations is much more complex. I'm concerned that Andrei's allocator interface doesn't actually address this... At least, I haven't seen any discussion about how it will. That said, I'm not trying to down-play the importance of a standard allocator API, and Andrei's development is very important and appreciated, but I am yet to find out how it actually addresses any of my real concerns relating to allocation. As I see it, I have zero concern about allocations I control. I am entirely concerned with intrinsic/implicit allocations that I don't, and may potentially (likely) originate from within 3rd party libraries.
All good points. Thanks and my bad for the misinformation, sorry. uri
Jul 14 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d 
wrote:
 We're yet to see how to use the allocators API to specify a 
 replacement
 default allocator used by the languages intrinsic allocations, 
 which makes
 it rather less exciting.
It's more a GC API issue. Did you try to replace druntime GC with your own? Then you could have the swapping API similar to gcstub.
Jul 14 2014
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
I don't think ARC would work in D. You'd need support for 
controlling the reference count in certain situations. You'd need 
type signatures for different reference types. You'd have to 
remove the GC.malloc function, as it would actually be manually 
memory managed with ARC, or otherwise return a fatter pointer, 
which would make it pretty useless. I hold more hope for someone 
improving the garbage collector implementation. This will happen 
sooner when someone who needs it takes the time to write it.

The key issue with GC is the pause time leading to dropped 
frames. Google has recently shown that you can use a garbage 
collector pretty excessively without losing any frames at 60FPS, 
by minimising the collection time so it fits within a frame.

https://www.youtube.com/watch?v=EBlTzQsUoOw#t=23m

If you wrote most of your game code with allocations you 
controlled and only had some minor GC activity with a 
sufficiently well written garbage collector, you wouldn't notice 
the GC getting in your way.

Whichever automatic memory management scheme you choose, if you 
are writing real time applications, you will ultimately have to 
optimise by taking more control of memory at some point. There's 
no automatic solution for this.
Jul 14 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 July 2014 22:39, w0rp via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 I don't think ARC would work in D. You'd need support for controlling the
 reference count in certain situations. You'd need type signatures for
 different reference types. You'd have to remove the GC.malloc function, a=
s
 it would actually be manually memory managed with ARC, or otherwise retur=
n
 a fatter pointer, which would make it pretty useless. I hold more hope fo=
r
 someone improving the garbage collector implementation. This will happen
 sooner when someone who needs it takes the time to write it.
If it were that simple, I reckon someone would have done it by now. Nobody seems to know how to do it. The key issue with GC is the pause time leading to dropped frames. Google
 has recently shown that you can use a garbage collector pretty excessivel=
y
 without losing any frames at 60FPS, by minimising the collection time so =
it
 fits within a frame.
It needs to fit within a *fraction* of a frame, I would be happy with 500=C2=B5s. I would consider 1-2ms extremely generous; 10% or more of the C= PU time! That's a lot less game, and it's the sort of difference that becomes clearly visible when comparing against competition. Frame time budgets are very carefully allocated and managed. https://www.youtube.com/watch?v=3DEBlTzQsUoOw#t=3D23m Google aren't really in the high-end gamedev business. I'm sure I could make Angry Birds run without dropping frames with a GC that took no more than 6ms... a real game, not so simple. If you wrote most of your game code with allocations you controlled and
 only had some minor GC activity with a sufficiently well written garbage
 collector, you wouldn't notice the GC getting in your way.
I won't notice the GC getting in the way when collection takes no more than 500=C2=B5s. Tell me how that can be achieved and you'll never hear me speak= of it again. My first impression was an incremental GC, I was talking about that for years. The experts agree it's impossible. The thing about GC is it's performance scales inversely with the total size of the heap, not the number of allocations. Heaps grow with time, this problem will only get worse! And it's execution frequency scales exponentially as free memory decreases. Embedded devices, and in particular video games consoles (with relatively lots of memory), manifest the very worst of this operating environment as standard operation. Whichever automatic memory management scheme you choose, if you are writing
 real time applications, you will ultimately have to optimise by taking mo=
re
 control of memory at some point. There's no automatic solution for this.
I'm particularly worried about libraries. I can do whatever I have to with memory that I control. You can't approach a modern ambitious project without depending on probably 10s of libraries. I've made my displeasure of spending years of my life re-inventing wheels for no reason other than developers memory allocation patterns quite plan on many occasions. I'm not making this up, I have literally wasted years of my life to date on this, and D makes the situation much, much worse by making an incompatible memory model the standard. I have nightmares about this stuff.
Jul 14 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/14/2014 10:09 AM, Manu via Digitalmars-d wrote:
 Google aren't really in the high-end gamedev business. I'm sure I could
 make Angry Birds run without dropping frames with a GC that took no more
 than 6ms... a real game, not so simple.
Just nitpicking on terminology here, but a lot of the high-end-performance ones aren't "real games" so much as movies sprinkled with some semi-interactive stuff. Basically spiritual extensions of Dragon's Lair. Angry Birds is far more of a "real" videogame than, say, Assassin's Creed or The Last of Us, as the focus is on gameplay rather than story telling and cinematography. But I understand your point. It would have been much harder for "The Last Of Us" to be as graphically competitive with a GC.
 I'm particularly worried about libraries. I can do whatever I have to with
 memory that I control.
 You can't approach a modern ambitious project without depending on probably
 10s of libraries.
I would have thought that for the currently-C/C++ high-end projects you're talking about, that most of those libraries are ones specifically designed for high-performance games in the first place (ex: Havok, anything from "RAD Game Tools", etc). Or at least with high-performance real-time in mind (ex: fmod). Is that not entirely so?
Jul 15 2014
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 July 2014 00:45, Nick Sabalausky via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 7/14/2014 10:09 AM, Manu via Digitalmars-d wrote:

 I'm particularly worried about libraries. I can do whatever I have to with
 memory that I control.
 You can't approach a modern ambitious project without depending on
 probably
 10s of libraries.
I would have thought that for the currently-C/C++ high-end projects you're talking about, that most of those libraries are ones specifically designed for high-performance games in the first place (ex: Havok, anything from "RAD Game Tools", etc). Or at least with high-performance real-time in mind (ex: fmod). Is that not entirely so?
Not at all. Sure, there's a couple of those, but most libraries are tools. xml/json/data formats, image/audio/video decoding, net/comms, graph analysis, os/runtime, etc.
Jul 15 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 14 July 2014 at 14:09:22 UTC, Manu via Digitalmars-d 
wrote:
 I don't think ARC would work in D. You'd need support for 
 controlling the
 reference count in certain situations. You'd need type 
 signatures for
 different reference types. You'd have to remove the GC.malloc 
 function, as
 it would actually be manually memory managed with ARC, or 
 otherwise return
 a fatter pointer, which would make it pretty useless. I hold 
 more hope for
 someone improving the garbage collector implementation. This 
 will happen
 sooner when someone who needs it takes the time to write it.
If it were that simple, I reckon someone would have done it by now. Nobody seems to know how to do it.
It's not hard to do it the conservative way, it's hard to do it the better way (the conservative way is rather slow or so people believe, I didn't see numbers), and there's a feeling D type system allows the better implementation.
Jul 15 2014
prev sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14/07/14 08:13, Manu via Digitalmars-d wrote:
 I'm among the minority that REALLY care about this, and it's clear (and it's
 been made clear) that if I'm not prepared to work on it myself, then it won't
 move forward.
I was one of the people who (gently, I hope) made that suggestion to you. I hope it's understood that (i) I'm speaking for me, not "the D community", and (ii) I was hoping to motivate rather than demotivate you. I'm sorry if that wasn't the case, because I do value your take on this issue, and however much pushback you receive, I've always been very glad to have you forcefully arguing this corner.
Jul 18 2014
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 7/14/2014 12:55 PM, Vic wrote:

 - Confusing forum. First listed forum on 'D' is not for D users, but
 it's called D! It is in fact for D commiters. This causes frustration
 for both users and commiters. (yes there is 'learn D' but it's 4th down.
 Commiters forum should be slightly hidden and user questions should not
 be answered in commuters but politely asked to post in the proper forum.).
I don't think that's an accurate description. The d.D newsgroup (for which the "forum" is a web interface) has *always* been where D users discuss D. The design and implementation of the language has very much been an effort with a great deal of community input, which is why so many such discussions take place here. It's not, however, in any way just a "committer's" forum. The d.D.learn newsgroup was born some time back due to an increase in the number of questions from new D users. Over time, I suppose it has become the place to ask all questions about how to use language features, whether from a noob or not. Although I've been around D 10 years, when I have such questions that's where I post them. I'm not disagreeing that the "learn forum" should be the first one visible on the page, but just wanted to say that d.D is very much for D users. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Jul 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 08:45:12 UTC, Mike Parker wrote:
 On 7/14/2014 12:55 PM, Vic wrote:

 - Confusing forum. First listed forum on 'D' is not for D 
 users, but
 it's called D! It is in fact for D commiters. This causes 
 frustration
 for both users and commiters. (yes there is 'learn D' but it's 
 4th down.
 Commiters forum should be slightly hidden and user questions 
 should not
 be answered in commuters but politely asked to post in the 
 proper forum.).
I don't think that's an accurate description. The d.D newsgroup (for which the "forum" is a web interface) has *always* been where D users discuss D. The design and implementation of the language has very much been an effort with a great deal of community input, which is why so many such discussions take place here. It's not, however, in any way just a "committer's" forum. The d.D.learn newsgroup was born some time back due to an increase in the number of questions from new D users. Over time, I suppose it has become the place to ask all questions about how to use language features, whether from a noob or not. Although I've been around D 10 years, when I have such questions that's where I post them. I'm not disagreeing that the "learn forum" should be the first one visible on the page, but just wanted to say that d.D is very much for D users.
This is kind of funny because as far as I understand, digitalmars.D is intended to be "user" forum ("commiters" have separate mail list) - it just happens that most of its regular visitors are so eager to discuss language design that it never stops :)
Jul 14 2014
prev sibling next sibling parent "ponce" <contact g3mesfrommars.fr> writes:
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
 - D is/has become complex. metaprograming, generics, macros, 
 etc. This is a culture issue, very hard to fix cultural issues 
 w/o losing most commiters. Just a fast system lang w/o headers, 
 'boost' and such. All this other stuff can be 3rd party eco 
 system and should be pushed out from D proper into 
 implementations and add ons.
I agree with you D is quite a learning. Consider buying the "D Cookbook" to go much faster, it is a valuable glue to make sense of all the available tools.
Jul 14 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Vic:

 - Confusing forum. First listed forum on 'D' is not for D 
 users, but it's called D! It is in fact for D commiters. This 
 causes frustration for both users and commiters. (yes there is 
 'learn D' but it's 4th down. Commiters forum should be slightly 
 hidden and user questions should not be answered in commuters 
 but politely asked to post in the proper forum.).
This looks sufficiently easy to fix. It just means restyling and reshuffling this page: http://forum.dlang.org/ Are you able to sketch what kind of look you like for this page and show an image?
 - I was *very* disappointed that using base library locks you 
 into GC vs ref. counting.
 Separate, I like how Objective C has NSObject for GC 
 purpose(I'd love a framework that is just ref counting), but 
 there should be dual libs and base should not be GC.
Allocators will probably come, but still there are no plans for language hooks, so there's still some way to go. I think this can be partially solved.
 - D is/has become complex. metaprograming, generics, macros, 
 etc. This is a culture issue, very hard to fix cultural issues
At this point I don't think this will be fixed. Removing complexity is hard.
 - Very little 'user' outreach. Meetups such as 'learn D'  (set 
 up editor w/ DUB, and write some vibe.d DNS client/server in 4 
 lessons). Or how to use a c .so lib.
This could be improved, but beside the need for D community to grow, I think it's also a cultural problem.
 So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not 
 commuters) to rewrite the Java project in Dallas and/or San 
 Jose (CA) over the next few months (Feel free to ping me 
  puppetMaster3, ideal candidate is 'prolific' and career 
 programmer)
What's the purpose of the rewrite? What do you hope to improve over the Java code? Bye, bearophile
Jul 14 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
bearophile, Inline

On Monday, 14 July 2014 at 09:33:27 UTC, bearophile wrote:
<snip>
 Are you able to sketch what kind of look you like for this page 
 and show an image?
Simple would be to put 'Learn D' first. Better would be that 'D' becomes 'Learn D' and new forum for D commuters is created with a new name and 'enforced'.
<snip>

 What's the purpose of the rewrite? What do you hope to improve 
 over the Java code?
Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has become cheap to do that. I need a system programing lang to do that better. Also I need to bypass OS sometimes, for example talking to NIC libs. Third, by using system programing lag, I get to hire better programers, not the CLR and JRE types that don't know how assembly or how to call AVX2 instructions, etc. (and minor, just a bit harder to de-compile). cheers.
Jul 14 2014
next sibling parent "Vic" <vic.cvc gmx.com> writes:
On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:

gig = gig of RAM
Jul 14 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Vic:

 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become cheap to do that. I need a system programing lang to do 
 that better.
Perhaps the D GC was never tested with such amounts of RAM (and generally in D what is not accurately tested doesn't work). Bye, bearophile
Jul 14 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 14 July 2014 at 14:09:02 UTC, bearophile wrote:
 Vic:

 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become cheap to do that. I need a system programing lang to do 
 that better.
Perhaps the D GC was never tested with such amounts of RAM (and generally in D what is not accurately tested doesn't work). Bye, bearophile
FYI the problem I had with very large allocations were user-error. I have since successfully used very large amounts of memory (128GB +) with the GC. However, I would say that it is not recommended. Very large heaps aren't conducive to good GC performance (especially with D's current GC). I now use a hybrid approach where the body of my data is on the C heap - managed manually - and all the scraps and difficult-to-track transient data are managed by the GC for convenience and correctness. I find it is a good compromise that introduces very little extra cognitive load over GC-only, but produces some good speedups.
Jul 14 2014
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 14 July 2014 at 14:19:49 UTC, John Colvin wrote:
 However, I would say that it is not recommended. Very large 
 heaps aren't conducive to good GC performance (especially with 
 D's current GC). I now use a hybrid approach where the body of 
 my data is on the C heap - managed manually - and all the 
 scraps and difficult-to-track transient data are managed by the 
 GC for convenience and correctness.
Even if the big blocks are allocated with NO_SCAN flag?
Jul 15 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 15 July 2014 at 17:13:46 UTC, Kagamin wrote:
 On Monday, 14 July 2014 at 14:19:49 UTC, John Colvin wrote:
 However, I would say that it is not recommended. Very large 
 heaps aren't conducive to good GC performance (especially with 
 D's current GC). I now use a hybrid approach where the body of 
 my data is on the C heap - managed manually - and all the 
 scraps and difficult-to-track transient data are managed by 
 the GC for convenience and correctness.
Even if the big blocks are allocated with NO_SCAN flag?
I'm not sure, haven't tried it. To be honest my problems were that the allocation itself was slow (even if it was just one big chunk), not that the GC was running slow collections. core.stdc.malloc was much faster. FYI: Beware doing any timing of malloc on linux, you're likely not measuring the allocation time at all. It's the first write to each page that triggers the allocation of that page, independent of when you called malloc.
Jul 15 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:
 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become cheap to do that.
Java can't hog gigs? Unbelievable.
Jul 15 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 15.07.2014 19:15, schrieb Kagamin:
 On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:
 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has become
 cheap to do that.
Java can't hog gigs? Unbelievable.
Sure it can. http://www.azulsystems.com/
Jul 15 2014
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 15 July 2014 at 18:02:41 UTC, Paulo Pinto wrote:
 Am 15.07.2014 19:15, schrieb Kagamin:
 On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:
 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become
 cheap to do that.
Java can't hog gigs? Unbelievable.
Sure it can. http://www.azulsystems.com/
They report Zing is ok, but Hotspot had a crash on 200gb heap. Though, not sure what Vic wants, large chunks or lots of small objects.
Jul 15 2014
prev sibling next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Tuesday, 15 July 2014 at 17:15:08 UTC, Kagamin wrote:
 On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:
 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become cheap to do that.
Java can't hog gigs? Unbelievable.
It can but standard JVMs can get large pauses when your heap exceeds maybe ~4GB? In Java it's pretty hard to avoid creating loads of garbage but I suppose if you were very careful you could avoid the pauses. It would probably be more cost effective to try out the Zing JVM from Azul Systems before doing a total rewrite. I've been wondering if a C4-esque GC would be feasable in D for a while. It sounds a lot like a magic bullet though, I suspect there are downsides beyond the price tag somewhere. I would love a response from anyone who is knowledgeable in this area.
Jul 15 2014
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 15 July 2014 at 23:37:06 UTC, currysoup wrote:
 I've been wondering if a C4-esque GC would be feasable in D for 
 a while. It sounds a lot like a magic bullet though, I suspect 
 there are downsides beyond the price tag somewhere. I would 
 love a response from anyone who is knowledgeable in this area.
Managed environments have nice data layouts and code generation tailored for GC. D has not so nice unmanaged data layouts.
Jul 15 2014
prev sibling parent reply "Vic" <vic.cvc gmx.com> writes:
On Tuesday, 15 July 2014 at 17:15:08 UTC, Kagamin wrote:
 On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote:
 Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has 
 become cheap to do that.
Java can't hog gigs? Unbelievable.
Java is the devil I know. But if D is not my first choice to port(from Java), than my second choice is Qt. It seems simpler to manage memory and Hash Associative Array. Any comments on Qt as choice?
Jul 16 2014
next sibling parent reply "Bastiaan Veelo" <Bastiaan Veelo.net> writes:
On Wednesday, 16 July 2014 at 09:56:06 UTC, Vic wrote:
 But if D is not my first choice to port(from Java), than my 
 second choice is Qt.
 It seems simpler to manage memory and Hash Associative Array.

 Any comments on Qt as choice?
I my experience, Qt makes programming in C++ a pleasure. Containers (with implicit sharing, foreach), strings, UTF8, i18n, signals and slots, dynamic type information, qmake, the state machine framework, of course the GUI framework, undo/redo framework, help reader and inline documentation generation, its IDE, and cross-platform portability are some of the aspects of Qt that I value the most. I am not sure why you think Qt makes memory management easier. QObjects are generally given a parent that destructs its children when it terminates, but that is merely a convenience in GUI programming I think. Bastiaan.
Jul 16 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
On Wednesday, 16 July 2014 at 12:35:29 UTC, Bastiaan Veelo wrote:
<snip>
 I am not sure why you think Qt makes memory management easier. 
 QObjects are generally given a parent that destructs its 
 children when it terminates, but that is merely a convenience 
 in GUI programming I think.
Yeah, I don't know if Qt or D makes manual memory easier, but at some point I want to find out. So if any more input, great. I'd hate to have to hire like so: Ideal candidate knows some Qt AND D Lang. I'm not doing GUI, it's a socket server w/ large RAM. Also 'large', if the CPU has 30meg L3, I don't think 128Gig RAM is large anymore. Cheers, Vic
Jul 16 2014
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Wednesday, 16 July 2014 at 15:25:22 UTC, Vic wrote:
 On Wednesday, 16 July 2014 at 12:35:29 UTC, Bastiaan Veelo 
 wrote:
 <snip>
 I am not sure why you think Qt makes memory management easier. 
 QObjects are generally given a parent that destructs its 
 children when it terminates, but that is merely a convenience 
 in GUI programming I think.
Yeah, I don't know if Qt or D makes manual memory easier, but at some point I want to find out. So if any more input, great. I'd hate to have to hire like so: Ideal candidate knows some Qt AND D Lang. I'm not doing GUI, it's a socket server w/ large RAM. Also 'large', if the CPU has 30meg L3, I don't think 128Gig RAM is large anymore. Cheers, Vic
Qt is an excellent framework, but pretty much completely irrelevant to memory management. Its object trees and refcounted containers are convenient for conventional programs, but if you are doing want to extract decent performaare with 100's of gigs, you'll need custom memory management, whether with D or Qt/C++ (and just like *some* parts of Phobos, Qt locks you into is types and whatever memory management they use. STL would make more sense but afaik it's allocator interface is quite a PITA)
Jul 16 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Wednesday, 16 July 2014 at 16:10:30 UTC, Kiith-Sa wrote:
<snip>
 Qt is an excellent framework, but pretty much completely 
 irrelevant to memory management. Its object trees and 
 refcounted containers are convenient for conventional programs, 
 but if you are doing want to extract decent performaare with 
 100's of gigs, you'll need custom memory management, whether 
 with D or Qt/C++ (and just like *some* parts of Phobos, Qt 
 locks you into is types and whatever memory management they 
 use. STL would make more sense but afaik it's allocator 
 interface is quite a PITA)
Thx Kiith.
Jul 16 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 16 July 2014 at 09:56:06 UTC, Vic wrote:
 Any comments on Qt as choice?
Pros: mature and widely used framework Cons: it is still C++ :)
Jul 16 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 16/07/14 11:56, Vic wrote:

 Java is the devil I know.

 But if D is not my first choice to port(from Java), than my second
 choice is Qt.
There is DWT [1], which is a port of the Java library SWT. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Jul 17 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
 Hi all,
 I'm a CTO at a start up and interested in porting our Java 
 project to D. Some points, I have been lurking on D for years, 
 went to my first D conf recently. Also I was one of top 20 
 people to join Java Struts, and that grew to 3million plus end 
 users so I have some 'cred'. Hope this helps:
Thanks for the feedback, hope it works out for you.
 - Confusing forum. First listed forum on 'D' is not for D 
 users, but it's called D! It is in fact for D commiters. This 
 causes frustration for both users and commiters. (yes there is 
 'learn D' but it's 4th down. Commiters forum should be slightly 
 hidden and user questions should not be answered in commuters 
 but politely asked to post in the proper forum.).
Good point, the main forum is both for "general discussion" and where a lot of talk about language development takes place. That list of forums should be reorganized.
 - I was *very* disappointed that using base library locks you 
 into GC vs ref. counting.
 Separate, I like how Objective C has NSObject for GC 
 purpose(I'd love a framework that is just ref counting), but 
 there should be dual libs and base should not be GC.
Coming from Java, this seems overly aggressive, not like you could avoid the GC in Java.
 - D is/has become complex. metaprograming, generics, macros, 
 etc. This is a culture issue, very hard to fix cultural issues 
 w/o losing most commiters. Just a fast system lang w/o headers, 
 'boost' and such. All this other stuff can be 3rd party eco 
 system and should be pushed out from D proper into 
 implementations and add ons.
It has become much more complex since D1, no doubt, but the goals have evolved.
 - Dub rocks.

 - Very little 'user' outreach. Meetups such as 'learn D'  (set 
 up editor w/ DUB, and write some vibe.d DNS client/server in 4 
 lessons). Or how to use a c .so lib.
Yeah, D definitely needs better marketing. One of the reasons rails took off a decade ago is a conference video Hansson put out showing how easy it was to setup and build a small webapp with rails (probably this one or an earlier version? http://www.youtube.com/watch?v=Gzj723LkRJY). Nothing too technical, just showing off ease of use as a feature. D needs such stuff, whether written or videos. Take, for example, the article Walter wrote about component programming using UFCS, maybe the best article related to D: http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321 If Hansson or some other marketer were writing about the same topic, it'd be all whiz-bang chained one-liners with little technical motivation of the underlying language features. I prefer what Walter wrote, but many would prefer the latter, at least when first hearing about D. D needs both. One line of thought that's been evolving for me lately is that D needs a blog, where we can highlight good stuff about the language. Go has one: http://blog.golang.org/ This post should go on D's: http://forum.dlang.org/post/mailman.3738.1405098936.2907.digitalmars-d puremagic.com I could see H.S. Teoh writing a series of such posts, expanding on each of the bullet points. Right now, he'll throw something off on the forum and it'll get buried by all the posts on here, missed by most users. A blog is where such material could be highlighted. We even have a D blog engine built on vibe.d that we could put to use: https://github.com/rejectedsoftware/vibelog I'd be happy to administer such a blog, if it's a matter of someone volunteering.
Jul 14 2014
parent David Gileadi <gileadis NSPMgmail.com> writes:
On 7/14/14, 4:56 AM, Joakim wrote:
 One line of thought that's been evolving for me lately is that D needs a
 blog, where we can highlight good stuff about the language.  Go has one:

 http://blog.golang.org/

 This post should go on D's:

 http://forum.dlang.org/post/mailman.3738.1405098936.2907.digitalmars-d puremagic.com


 I could see H.S. Teoh writing a series of such posts, expanding on each
 of the bullet points.  Right now, he'll throw something off on the forum
 and it'll get buried by all the posts on here, missed by most users.  A
 blog is where such material could be highlighted.

 We even have a D blog engine built on vibe.d that we could put to use:

 https://github.com/rejectedsoftware/vibelog

 I'd be happy to administer such a blog, if it's a matter of someone
 volunteering.
I think some of Walter's Dr. Dobb's posts would also fit very well in a D blog format. It would be cool if he could get permission to post a copy on this hypothetical blog. The current Articles section on the website may have some overlap with the purposes of a blog, too. Perhaps they could be merged somehow, or perhaps provide a "promotion" process from one to the other. This blog idea (and offer to volunteer) probably deserves its own thread.
Jul 14 2014
prev sibling parent reply "Vic" <vic.cvc gmx.com> writes:
To illustrate point on D complexity:
https://d262ilb51hltx0.cloudfront.net/max/800/1*_gRpHqzB-1zbG17jdxGPaQ.png

It appears that it mission is to be Java, vs a system lang.
hth

On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
<snip>
Jul 15 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 15 July 2014 at 09:24:14 UTC, Vic wrote:
 To illustrate point on D complexity:
 https://d262ilb51hltx0.cloudfront.net/max/800/1*_gRpHqzB-1zbG17jdxGPaQ.png

 It appears that it mission is to be Java, vs a system lang.
 hth

 On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
 <snip>
History is full of languages that started as a cry against complexity, only to became as complex when they aged. The world is complex and needs powerful languages for abstraction modelling. Any language aspiring to success will eventually become complex, even if version 1.0 is not. -- Paulo
Jul 15 2014
prev sibling next sibling parent "JR" <zorael gmail.com> writes:
On Tuesday, 15 July 2014 at 09:24:14 UTC, Vic wrote:
 To illustrate point on D complexity:
 https://d262ilb51hltx0.cloudfront.net/max/800/1*_gRpHqzB-1zbG17jdxGPaQ.png

 It appears that it mission is to be Java, vs a system lang.
 hth
Maybe I misunderstand the term, but it seems to me that a systems language inherently has to be complex? I'd do a car analogy but I'd cringe. :3 The more abstractions you hide low-level code behind, the less direct control the developer has over the hardware. Providing both *allows* it to be complex but doesn't necessitate it, making the black magic opt-in. I concede that it makes the language bigger. I mean, I have a bunch of shell scripts written over the years that do everything from updating /etc/hosts with additions from MVPS[1] to determining the OpenNIC DNS server[2] with the best ping. And I could probably do *quick-and-dirty* rewrites of these in D with little effort, and they'd probably even be less complex as shell interpreters' limitations makes writing non-trivial stuff a pain in the derriere[3]. No std.socket.ping though, would have to think about that. A new user would get more hidden allocations, but the abstractions allow for that. He would see a simple language with most of everything he wants *in phobos*. An experienced one could probably make them very effective and nigh-allocation-free, and the complex low-level parts allow for that too. [1]: http://winhelp2002.mvps.org/hosts.htm [2]: http://wiki.opennicproject.org/Tier2 [3]: http://pastebin.com/Uj5rw7TL
Jul 15 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/15/2014 5:24 AM, Vic wrote:
 To illustrate point on D complexity:
 https://d262ilb51hltx0.cloudfront.net/max/800/1*_gRpHqzB-1zbG17jdxGPaQ.png

 It appears that it mission is to be Java, vs a system lang.
 hth
I'll take that remote over a highly-modal one, or worse, a highly-modal one that I can't feel the buttons on. ;) But I like features and I'm not afraid of buttons, so that kinda makes me a bit of an oddity these days.
Jul 15 2014