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