5 ms·

I found the post slightly contradictory but overall strongly evoked the frustration that the author felt. My reading is that most of the problems come from a la

I found the post slightly contradictory but overall strongly evoked the frustration that the author felt. My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. I think that D is a language that I would like to use but I don't because few seem to have heard of it. This is the catch22 problem that D finds itself in. Popularity contests are fickle and not just restricted to the high school playground unfortunately. Look at swift, i read about problems with breaking changes and compiler crashes and it just doesn't seem to matter because Apple. Anyway, my question is, what are the weak points of D? I should state at the outset that I have no problem with there being a GC as I'm a python programmer not a C programmer but one who wants to learn a compiled language. I'm more interested in any other issues that might warn me away from D.

qznc 10y ago
The weak points of D? If you want the high-level view by the project leaders what needs to be done, look at the vision document: https://wiki.dlang.org/Vision/2016H2 https://wiki.dlang.org/Vision/2016H2 D certainly needs more libraries, but which language doesn't? The currently available stuff is: https://code.dlang.org/ https://code.dlang.org/ Further stuff depends on what you would use D for. You describe yourself as a "Python programmer". Web development? In this area D is still weak. There is only one solid framework http://vibed.org/ http://vibed.org/ which does not officially support any SQL database (it has Mongo and Redis though). Personally, I think vibe.d is fine for micro services, but it is still a long way until it could compete with Django. I built a prediction market web app with vibe.d. It has hand-written SQL queries (should probably have used https://code.dlang.org/packages/hibernated https://code.dlang.org/packages/hibernated). I had to write Github authentication from scratch. There are few conventions, which is irritating if you are used to follow Django tutorials. You feel lost. That is my experience with D. Personally, I have no issues with the standard library like the ranter, but I assume I'm in the minority with that.
- robochat 10y ago
  Thanks for the link to the vision document. Even the fact that such a document exists does show that steps are already being taken to give D more direction. I'm not really a web developer, more of a data analyst with some web services. So the lack of SQL libraries is a disappointment.
  - qznc 10y ago
    As a data analyst, you probably use Numpy? There is ndslice in D. https://dlang.org/phobos/std_experimental_ndslice.html https://dlang.org/phobos/std_experimental_ndslice.html This comes from the Mir package: http://mir.dlang.io http://mir.dlang.io And there is some scientific code stuff here: https://dlangscience.github.io/ https://dlangscience.github.io/
    - robochat 10y ago
      The Mir package looks pretty interesting but it's quite new isnt it? Thanks for the links.
      - qznc 10y ago
        Yes, it is new. (Ilya, the Mir guy, is a huge fan, who champions the "betterC" D style. This discussion triggered the rant here.)
        robochat 10y ago
        This guy Ilya, seems to want to throw everything away and start again. Is that really what D needs?
- lacampbell 10y ago
  People don't hand-write SQL queries anymore!?
marktangotango 10y ago
D has been around for a long time now. I never considered it to be a viable candidate because I'd use it for low level server side stuff, and garbage collection required by the standard library was a no go. GC is optional in user D code, but the standard library uses it, so it gets pulled in. Last I checked they were working this out, if/when they do I'll check it out again. Personally, for the server stuff I was doing, I just used C. Yes, it can be painful, but it's always there, always supported, and can be bent to your will.
- WalterBright 10y ago
  > I just used C. D has a C subset, in that there is a 1:1 correspondence. If you write code this way (I have) there are zero calls to the GC, and you will get the same code generated as a C compiler would (after all, all three D compilers use C compiler code generators). The reason I have written code this way is when I've converted C code to D. Once it is in D, then I start refactoring it to use D idioms, but that's not necessary. I.e. you can use D as a C compiler. (Likely the most tedious issue translating C to D is if the C code uses the preprocessor as a metaprogramming language. Fortunately, this is unusual.)
- robochat 10y ago
  Ok, but I was trying to avoid The GC hate. I understand that these are real issues but I wanted to hear about other things. It's so hard to avoid people bringing up the same issues again and again when discussing languages. Python - too slow Go - no generics C++ - too much history, too vast Rust - too hard Perl - unreadable Java - too verbose Fortran - too old I have learnt C but it seems like a lot of work to do simple things and I guess that I've been put off by all of the scare mongering until I can't imagine being able to write a program that isn't riddled with bugs.
p0nce 10y ago
> what are the weak points of D? The weak point is that it has a bad rep despite evidence of being useful, and loved in the field. Perhaps still paying the price of old split of community years ago? As a business I have no problem with D. It's a joyful language that is applicable to a wide variety of task except web front-end. There is a package manager, productivity is definately there, and you can work-around whatever problem is thrown at you. The leadership know what they are doing, the language is very stable, and the complexity manageable (yet staggering and some parts are definately to avoid). I mean, what's not to love? You can match C++ speed (LLVM backend) with heightened productivity and compile-times. If you have used a Wirth family language (or Delphi), you may feel right at home.
- pjmlp 10y ago
  > Perhaps still paying the price of old split of community years ago? Unfortunately a new split seems to be coming up around the whole BetterC discussion.
  - p0nce 10y ago
    Yes it's a serious concern. I was there in the tango split, it was ugly and mean, but the level of communication and understanding is higher this time.
phaylon 10y ago
> My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. Preface: I don't use D, but I've lurked on the forums for a while now since I've started looking for a low-level programming language. I would agree that this (manpower and delegation) is the main issue D is facing, and many others flow from it. Walter and Andrei are spread way too thin, while still being the main conduits and gatekeepers for all things D. For example, sometimes their responses can seem curt or dismissive, but I've come to the conclusion that they're just busy people, and for many back-and-forth communications short responses are fine if not better. My personal opinion is that what D really needs is more bureaucracy. Pre-defined processes where even casual contributors and other interested parties can follow along. I believe the "study" subforum was a good start, but is a bit too ad-hoc (and underused). The issue discussed in the original (stdlib coupling, integration of D built libraries into other systems) would be perfect for a study group. Start out with a Goals/Requirements document, come out with strategies, hindrances. Even when no solution is found or no consensus is reached, the archived discussion would be valuable in itself, for example as basis for a "Reasoning and Alternatives" document for the specific issue or mentioned use-cases. A more complex situation would be the optional GC. It is very much wanted, and lots of work is going into that (all the RC integration/experimentation, the scope annotation system, to just name the ones visible to a lurker like me). But I couldn't tell you the full plan, I'm unsure where D wants to end up (from a current standpoint) with regard to being usable without GC. From my point of view, there are still issues to be sorted out with closures, exceptions, arrays and slices, plus I'm unsure about how GC, RC and manual memory management are supposed to interact in the end. Now, from examples on the forums I can tell that using D without GC is doable and useful, so I would assume once you start doing it you find a way. But this is all harder to see from the outside. Which brings me to another point: Publicity. D could do with a lot more blog posts showcasing its more unique parts like great use-cases for the compile-time power D has: The memory management strategies, how to effectively use the safety system, how to do D concurrency and parellelism "right". I apologize this got a bit longer, I guess I waited for a cue to give some feedback on D, since I never felt like it was my place as a biased outsider to weigh in on their forums. In effect, I believe manpower is one of the biggest issues to get where they want to go. What I find interesting is that in my view it is non-development manpower that they actually need. Or rather, more efficient ways to attract it, or maybe even just more efficient ways to include the ones already there.

qznc 10y ago

The weak points of D? If you want the high-level view by the project leaders what needs to be done, look at the vision document: https://wiki.dlang.org/Vision/2016H2 https://wiki.dlang.org/Vision/2016H2 D certainly needs more libraries, but which language doesn't? The currently available stuff is: https://code.dlang.org/ https://code.dlang.org/ Further stuff depends on what you would use D for. You describe yourself as a "Python programmer". Web development? In this area D is still weak. There is only one solid framework http://vibed.org/ http://vibed.org/ which does not officially support any SQL database (it has Mongo and Redis though). Personally, I think vibe.d is fine for micro services, but it is still a long way until it could compete with Django. I built a prediction market web app with vibe.d. It has hand-written SQL queries (should probably have used https://code.dlang.org/packages/hibernated https://code.dlang.org/packages/hibernated). I had to write Github authentication from scratch. There are few conventions, which is irritating if you are used to follow Django tutorials. You feel lost. That is my experience with D. Personally, I have no issues with the standard library like the ranter, but I assume I'm in the minority with that.

robochat 10y ago
Thanks for the link to the vision document. Even the fact that such a document exists does show that steps are already being taken to give D more direction. I'm not really a web developer, more of a data analyst with some web services. So the lack of SQL libraries is a disappointment.
- qznc 10y ago
  As a data analyst, you probably use Numpy? There is ndslice in D. https://dlang.org/phobos/std_experimental_ndslice.html https://dlang.org/phobos/std_experimental_ndslice.html This comes from the Mir package: http://mir.dlang.io http://mir.dlang.io And there is some scientific code stuff here: https://dlangscience.github.io/ https://dlangscience.github.io/
  - robochat 10y ago
    The Mir package looks pretty interesting but it's quite new isnt it? Thanks for the links.
    - qznc 10y ago
      Yes, it is new. (Ilya, the Mir guy, is a huge fan, who champions the "betterC" D style. This discussion triggered the rant here.)
      - robochat 10y ago
        This guy Ilya, seems to want to throw everything away and start again. Is that really what D needs?
lacampbell 10y ago
People don't hand-write SQL queries anymore!?

marktangotango 10y ago

D has been around for a long time now. I never considered it to be a viable candidate because I'd use it for low level server side stuff, and garbage collection required by the standard library was a no go. GC is optional in user D code, but the standard library uses it, so it gets pulled in. Last I checked they were working this out, if/when they do I'll check it out again. Personally, for the server stuff I was doing, I just used C. Yes, it can be painful, but it's always there, always supported, and can be bent to your will.

WalterBright 10y ago
> I just used C. D has a C subset, in that there is a 1:1 correspondence. If you write code this way (I have) there are zero calls to the GC, and you will get the same code generated as a C compiler would (after all, all three D compilers use C compiler code generators). The reason I have written code this way is when I've converted C code to D. Once it is in D, then I start refactoring it to use D idioms, but that's not necessary. I.e. you can use D as a C compiler. (Likely the most tedious issue translating C to D is if the C code uses the preprocessor as a metaprogramming language. Fortunately, this is unusual.)
robochat 10y ago
Ok, but I was trying to avoid The GC hate. I understand that these are real issues but I wanted to hear about other things. It's so hard to avoid people bringing up the same issues again and again when discussing languages. Python - too slow Go - no generics C++ - too much history, too vast Rust - too hard Perl - unreadable Java - too verbose Fortran - too old I have learnt C but it seems like a lot of work to do simple things and I guess that I've been put off by all of the scare mongering until I can't imagine being able to write a program that isn't riddled with bugs.

p0nce 10y ago

> what are the weak points of D? The weak point is that it has a bad rep despite evidence of being useful, and loved in the field. Perhaps still paying the price of old split of community years ago? As a business I have no problem with D. It's a joyful language that is applicable to a wide variety of task except web front-end. There is a package manager, productivity is definately there, and you can work-around whatever problem is thrown at you. The leadership know what they are doing, the language is very stable, and the complexity manageable (yet staggering and some parts are definately to avoid). I mean, what's not to love? You can match C++ speed (LLVM backend) with heightened productivity and compile-times. If you have used a Wirth family language (or Delphi), you may feel right at home.

pjmlp 10y ago
> Perhaps still paying the price of old split of community years ago? Unfortunately a new split seems to be coming up around the whole BetterC discussion.
- p0nce 10y ago
  Yes it's a serious concern. I was there in the tango split, it was ugly and mean, but the level of communication and understanding is higher this time.

phaylon 10y ago

> My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. Preface: I don't use D, but I've lurked on the forums for a while now since I've started looking for a low-level programming language. I would agree that this (manpower and delegation) is the main issue D is facing, and many others flow from it. Walter and Andrei are spread way too thin, while still being the main conduits and gatekeepers for all things D. For example, sometimes their responses can seem curt or dismissive, but I've come to the conclusion that they're just busy people, and for many back-and-forth communications short responses are fine if not better. My personal opinion is that what D really needs is more bureaucracy. Pre-defined processes where even casual contributors and other interested parties can follow along. I believe the "study" subforum was a good start, but is a bit too ad-hoc (and underused). The issue discussed in the original (stdlib coupling, integration of D built libraries into other systems) would be perfect for a study group. Start out with a Goals/Requirements document, come out with strategies, hindrances. Even when no solution is found or no consensus is reached, the archived discussion would be valuable in itself, for example as basis for a "Reasoning and Alternatives" document for the specific issue or mentioned use-cases. A more complex situation would be the optional GC. It is very much wanted, and lots of work is going into that (all the RC integration/experimentation, the scope annotation system, to just name the ones visible to a lurker like me). But I couldn't tell you the full plan, I'm unsure where D wants to end up (from a current standpoint) with regard to being usable without GC. From my point of view, there are still issues to be sorted out with closures, exceptions, arrays and slices, plus I'm unsure about how GC, RC and manual memory management are supposed to interact in the end. Now, from examples on the forums I can tell that using D without GC is doable and useful, so I would assume once you start doing it you find a way. But this is all harder to see from the outside. Which brings me to another point: Publicity. D could do with a lot more blog posts showcasing its more unique parts like great use-cases for the compile-time power D has: The memory management strategies, how to effectively use the safety system, how to do D concurrency and parellelism "right". I apologize this got a bit longer, I guess I waited for a cue to give some feedback on D, since I never felt like it was my place as a biased outsider to weigh in on their forums. In effect, I believe manpower is one of the biggest issues to get where they want to go. What I find interesting is that in my view it is non-development manpower that they actually need. Or rather, more efficient ways to attract it, or maybe even just more efficient ways to include the ones already there.