Dlang's future is bright. It is the one true C++. In a related article, someone proposes C++ for physicists instead of Fortran. I propose to use Dlang or evolve Fortran to be more D-like. But take a look at the vast research C++ code. It is there unmaintained and unmaintainable. Dlang would make a huge difference here. The best are yet to come. C++ suffers from a serious personality disorder. It is C / it is SML / it is Python and finally it is perplexing and dangerous like JavaScript. If I had to use C++, I would stick to C. If I could change C++, I could throw away OO and Exceptions and see how to integrate templates and closures to C and make the language less forgiving.
In my career I worked on three C++ projects with about 100 developers, and OOP proven to be useful. If the codebase is so large that not a single person knows it as a whole, OOP allows to express the structure of the code. I surely wouldn't want to do it in C. The only drawback I noticed is that you need to learn more to understand and be proficient in C++.
One of the great things about C++ is that it weeds out the shitty developers. Not that there isn't plenty of shitty C++ code out there. There's just not a lot of C++ code out there that's both shitty and kind of works. If you don't do C++ right it will fail spectacularly. Poorly written software in languages like Java, Go, Python, etc. can hobble along miserably for decades because when it's broke it probably still kind of works event if it's slow and constantly spits stack traces. A C++ program has to be beautiful or it probably wont last long.
I don't think that this argument proves the initial assertion that C++ "weeds out the shitty developers". Shitty code doesn't just appear out of thin air, and god knows I've both read and written some shitty code (including shitty C++ code) in my day. Shitty C++ code survives exactly the same way that shitty code survives in all languages: by piling ill-considered hack upon ill-considered hack until your boss stops complaining.
> There's just not a lot of C++ code out there that's both shitty and kind of works.
I promise you, there is. That you've managed to avoid it earns you my envy, although not my agreement.
Raymond Chen sometimes blogs about all the weird historical niggles and backwards compatibility hacks that lace the Win32 API because of, ultimately, shitty C++ code. I've seen similar, or even worse. And yet, I've got absolutely nothing to complain about compared to some of the horror stories I've heard from other devs and the codebases they work on.
I am a shitty developer, but as a researcher, I have common sense and my BS radar shows a very big signal at C++ direction. When I see problematic C++ I do not start blaming the developers. Part of the problem is the developer and the other part ~ 50% is the language. Since I am a shitty developer and a coward, I would never do C++ buddy jumping again. Last time I pissed my underwear. The others, who didn't back-off, destroyed a 200.000 EU research program fixing bugs, refactoring and seeking the holy Grail of low-level performance instead of doing meaningful research and improving algorithmic complexity.
Thank you for admitting it and knowing your limitations. The world could be saved a lot of time and money if more people followed your example.
However, as with any challenging skill in life, you have to be shitty at C++ before you can hope to be good at it. We need some brave souls to attempt to become good programmers otherwise we won't have any. The biggest problem with software today is all the shitty programmers out there who are employed as if they were good at it. C++ helps weed those programmers out because it's very difficult to be at all productive in that language of you're shitty.
> A C++ program has to be beautiful or it probably wont last long.
You can't be serious. A C++ program has difficulty being beautiful because changing anything takes lots of time to compile. C++ subtly trains your brain not to ever change anything.
Beautiful C++ code does exist though, and is often the output of a single developer.
Producing non-shitty C++ code with multiple developers is exceptionally hard since all your developers have to be good. Of course that's true for any language.
Stroustrup explicitly mentioned in his keynote at this year's CPPCON that 2016 that C++ has the ability to be low level and also provide higher abstractions so you get away from thinking specifically about implementation details and more about ideas.
I think that's the power of C++ (the fact you can do both), and without OOP would be useless.
Same goes for "Go saps all the fun out of the coding". As an ex-Ruby programmer, with Go I've never had so much fun programming since tinkering with C in college. Go just doesn't get in the way of implementing ideas, which is the core of the fun.
Maybe its the well-thought standard library, maybe its the way the compiler helps you. Maybe its because we can actually catch bugs at compile time instead of those runtime errors and silent drops of javascript
I think we are experiencing a fatigue in general when it comes to IT and technologies.
Sure technology evolves but you can learn only so much at the same time. People prioritize. If the technology is not appealing to me I won't use it but at the same time if the technology is massively used and pushed by corps and startup hype I have to at least take a look.
D did not attract enough people nor it has a backing of multi billion dollar corporation.
It has powerful meta-programming. It is effectively the opposite of Go, which does not even have generics. This certainly provides foot shooting as well, so other languages (e.g. Rust) are more conservative with that. D examples: https://qznc.github.io/d-tut/meta.html
Those are the two reasons, which D has ahead of all other languages (ok, not Lisp wrt meta-programming). If you compare it to another specific language, there are more things to talk about.
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.
D certainly needs more libraries, but which language doesn't? The currently available stuff is: 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/ 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). 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.
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.
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.
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.)
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.
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.
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.
> 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.
Rust: Promotes itself to be better C but its simply a more complex language design.
huh? Rust tries to solve the real problem of shooting yourself in the foot in C without compromising on being as close as possible to bare metal.
D is C++ but improved/simplified. Its not to hard to get into, its more easy for anybody from a C background.
The main virtue of C++ is its vast legacy base that needs to be maintained. Replacing C++ with D can't possibly be for the reason of being "improved/simplified".
Take it from a guy that spend a large part of his life in PHP.
This explains a lot of the statements in the publication.
> This explains a lot of the statements in the publication.
I hope we can avoid offhand judgments like this. As for the OP, and leaving aside the parts discussing other languages, this is a useful document for those outside the D community for summarizing some issues that may be apparent mostly to insiders. However, I think the author underestimates the amount of effort that it takes to develop and polish a complete and modern-feeling language/library/tooling ecosystem, especially for projects dependent on volunteer contributions (rare are the volunteers who sign up for grunt work, however essential that grunt work may be).
> this is a useful document for those outside the D community for summarizing some issues that may be apparent mostly to insiders
That is my fear. Some of the issues raised are non-issues, but as an outsider you cannot distinguish them. I envy Rust. Grunt work and PR seems go much smoother over there.
> Replacing C++ with D can't possibly be for the reason of being "improved/simplified".
Author says exactly the same, don't try to replace C++, offer an alternative to C-like scripting languages.
> This explains a lot of the statements in the publication.
Is it really that easy for you to generalize about thousands of people all round the world? I know quite a few excellent engineers in my home town with background in various other languages (me included) who also happen to work mainly in php because when you live outside US it's much easier to find a well paid remote jobs in php then for instance in C++. Are we all ignorant fools not entitled to have an opinion on other languages because of it?
What I meant by the PHP remark is that the publication is from the point of view of D as (making it the best?) scripting language. In this case, why C/C++/Rust are there at all? These are system-level languages that have very different priorities than scripting-level languages.
That's true, I guess he was making a comparison why D should focus more on a scripting lang community. Which btw I don't really agree with, in my opinion D is pretty nice all-around language, don't see why limit it on a single niche.
D is a great language, I don't see why other languages are attacked in nearly every post about D. Spend time talking about D as though it existed in a vacuum, spend some time planning in that fashion too. D started off as C+++, but it is its own beast now.
> [Post] Editor support
My first Go PR happened after the fantastic Go VSCode support dropped - even some of the Google gophers are using it now. Prior to VSCode support, I found Go unapproachable. Vim and Emacs support is all good and well, but not everyone uses that and "you should be" is a non-sequitur.
An official document that's just a wiki page that can fit almost entirely on a single page. That is nothing more than a very brief outline of what to accomplish with no real documentation of a plan to achieve listed goals.
No surprise this list is so long:
Other topics from H1 underwent only little development and will be copied as ongoing topics for H2: safety, memory management, tooling, improve language stability and specification, C++ and Objective C integration, library additions, smartphone support.
> Rust: [...] A over active amount of fans, that do not understand its complex.
No. We understand it is complex. We also understand why: memory management is complex in and of itself, but RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language.
> RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language
D agrees with the "everything" part. D wants to give you options, so you can use GC/RC/manual where appropriate.
Sadly, I have not found the time to wrestle with the Rust borrow checker myself. I still have doubts if it is worth it. For example, assume you write a graph data structure. To pass the lifetime analysis, you have to store the nodes in some background store vector. If you want to free/reuse memory of nodes, Rust essentially requires you to write a garbage collector for the nodes yourself.
Afaik there are plans to add an optional GC to the standard library? So ultimately, D and Rust converge to the same point from different angles. Both want all the options. Rust started from safe manual and gains options. D started with safe automatic and gains safety for manual.
> D wants to give you options, so you can use GC/RC/manual where appropriate.
Again, those options are what I listed as the wrong approaches. Manual = ad-hoc memory management.
There's an additional option only present in Rust: automatic memory management via static analysis. Rust does not allow manual memory management at all unless writing unsafe code. Unlike Rust, D code with memory allocations is either GC'd or unsafe.
Just to make it clear: the borrow and lifetime checkers are not manual memory management. Lifetimes are just hints for the compiler to do its automatic memory management at compile time.
> ultimately, D and Rust converge to the same point
> the borrow checker is not manual memory management
Ok, we disagree on the terminology here. I would consider that manual, because it looks the same in C++. Rust only has the static analysis to weed out all the unsafe/broken code.
> I would consider that manual, because it looks the same
> in C++
Many also consider RAII in C++ to be "automatic memory management". Other than agreeing that C is manual and Java is automatic, terms are failing us here. :)
In the Rust community, instead of trying to argue whether or not Rust is manual or automatic (or "safe manual memory management", or "static automatic memory management", or etc.), we tend to just say "in Rust, you do need to think about memory management, but you don't need to worry about memory management". :P
> Afaik there are plans to add an optional GC to the
> standard library?
This is incorrect. There are some far-future plans to add GC hooks to the language to allow it to interoperate with external GCs (mostly motivated for Servo to use with Spidermonkey, Firefox's Javascript engine), but there will never be a GC implementation shipped with the stdlib itself.
Yes, Manish there is a Servo dev who spends some of his time thinking about how Rust could support external GCs. I believe his goal there is to write a library that's more-or-less analogous to the basic Boehm collector for C, as a proof-of-concept.
>Go: Its is a "simple" language. But its forced restrictions at times are so annoying its saps all the fun out of the coding. Its not really C. Its more Basic on steroids. Unfortunately while Go has huge amount of traction and packages ( 70k from my count ), the quality is also... It has a few real gems those gems are a result of the mass amount of packages. It has its own market. A scripting replacement market mostly.
Not that difficult, you just have to understand english isn't everyone's first language. If you've ever taken the time to learn another language, you would have realized it is very difficult to do. Especially later in life. If a child as young as 11 was never exposed to language, they might never be capable of understanding it.
I don't understand why it's such a big deal with the GC.
Ok if you want to build drivers or OSes related stuff.
For AAA games, I can understand, but they will not switch to a new language as long as there is no engine like Unreal or Unity3D (GCed) that worth the switch. And the rest are indie and a GC will not affect performance.
For web services, GUI application, the GC would be desirable because it will enable the developper to work on the business model and not the computer model and it will removed stupid memory management kind of bugs. Plus, 1200 fps vs 1120 fps is not faster since we can't see the difference.
Is it that the D's GC is really slow or really memory inefficient?
66 comments
[ 2.7 ms ] story [ 93.9 ms ] threadI promise you, there is. That you've managed to avoid it earns you my envy, although not my agreement.
Raymond Chen sometimes blogs about all the weird historical niggles and backwards compatibility hacks that lace the Win32 API because of, ultimately, shitty C++ code. I've seen similar, or even worse. And yet, I've got absolutely nothing to complain about compared to some of the horror stories I've heard from other devs and the codebases they work on.
However, as with any challenging skill in life, you have to be shitty at C++ before you can hope to be good at it. We need some brave souls to attempt to become good programmers otherwise we won't have any. The biggest problem with software today is all the shitty programmers out there who are employed as if they were good at it. C++ helps weed those programmers out because it's very difficult to be at all productive in that language of you're shitty.
You can't be serious. A C++ program has difficulty being beautiful because changing anything takes lots of time to compile. C++ subtly trains your brain not to ever change anything.
Beautiful C++ code does exist though, and is often the output of a single developer.
I think that's the power of C++ (the fact you can do both), and without OOP would be useless.
Maybe its the well-thought standard library, maybe its the way the compiler helps you. Maybe its because we can actually catch bugs at compile time instead of those runtime errors and silent drops of javascript
It is a way out of the C++ tar pit, because it does C++ interop better than any other language. D needs to continue to outrun C++ evolving, though. See http://dconf.org/2016/talks/watson.html or https://www.youtube.com/watch?v=IkwaV6k6BmM
It has powerful meta-programming. It is effectively the opposite of Go, which does not even have generics. This certainly provides foot shooting as well, so other languages (e.g. Rust) are more conservative with that. D examples: https://qznc.github.io/d-tut/meta.html
Those are the two reasons, which D has ahead of all other languages (ok, not Lisp wrt meta-programming). If you compare it to another specific language, there are more things to talk about.
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.
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
D certainly needs more libraries, but which language doesn't? The currently available stuff is: 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/ 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). 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.
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.
This comes from the Mir package: http://mir.dlang.io
And there is some scientific code stuff here: https://dlangscience.github.io/
(Ilya, the Mir guy, is a huge fan, who champions the "betterC" D style. This discussion triggered the rant here.)
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.
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.)
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.
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.
Unfortunately a new split seems to be coming up around the whole BetterC discussion.
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.
That is my fear. Some of the issues raised are non-issues, but as an outsider you cannot distinguish them. I envy Rust. Grunt work and PR seems go much smoother over there.
Author says exactly the same, don't try to replace C++, offer an alternative to C-like scripting languages.
> This explains a lot of the statements in the publication.
Is it really that easy for you to generalize about thousands of people all round the world? I know quite a few excellent engineers in my home town with background in various other languages (me included) who also happen to work mainly in php because when you live outside US it's much easier to find a well paid remote jobs in php then for instance in C++. Are we all ignorant fools not entitled to have an opinion on other languages because of it?
>> huh? Rust tries to solve the real problem of shooting yourself in the foot in C without compromising on being as close as possible to bare metal.
By having a more complex language design. You can't deny that lifetimes and the borrow checker make Rust a much more complex language than C
D is a great language, I don't see why other languages are attacked in nearly every post about D. Spend time talking about D as though it existed in a vacuum, spend some time planning in that fashion too. D started off as C+++, but it is its own beast now.
> [Post] Editor support
My first Go PR happened after the fantastic Go VSCode support dropped - even some of the Google gophers are using it now. Prior to VSCode support, I found Go unapproachable. Vim and Emacs support is all good and well, but not everyone uses that and "you should be" is a non-sequitur.
There is very little about the future of D and it is certainly nothing official like the Vision document [0] twice a year.
[0] https://wiki.dlang.org/Vision/2016H2
No surprise this list is so long:
No. We understand it is complex. We also understand why: memory management is complex in and of itself, but RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language.
D agrees with the "everything" part. D wants to give you options, so you can use GC/RC/manual where appropriate.
Sadly, I have not found the time to wrestle with the Rust borrow checker myself. I still have doubts if it is worth it. For example, assume you write a graph data structure. To pass the lifetime analysis, you have to store the nodes in some background store vector. If you want to free/reuse memory of nodes, Rust essentially requires you to write a garbage collector for the nodes yourself.
Afaik there are plans to add an optional GC to the standard library? So ultimately, D and Rust converge to the same point from different angles. Both want all the options. Rust started from safe manual and gains options. D started with safe automatic and gains safety for manual.
Again, those options are what I listed as the wrong approaches. Manual = ad-hoc memory management.
There's an additional option only present in Rust: automatic memory management via static analysis. Rust does not allow manual memory management at all unless writing unsafe code. Unlike Rust, D code with memory allocations is either GC'd or unsafe.
Just to make it clear: the borrow and lifetime checkers are not manual memory management. Lifetimes are just hints for the compiler to do its automatic memory management at compile time.
> ultimately, D and Rust converge to the same point
Definitely not.
Ok, we disagree on the terminology here. I would consider that manual, because it looks the same in C++. Rust only has the static analysis to weed out all the unsafe/broken code.
In the Rust community, instead of trying to argue whether or not Rust is manual or automatic (or "safe manual memory management", or "static automatic memory management", or etc.), we tend to just say "in Rust, you do need to think about memory management, but you don't need to worry about memory management". :P
It is definately worth it to have such ownership. This style was discovered in C++ and made better in Rust.
A leaner version of this is the C++11 version, which has std::unique_ptr and raw pointers. Very popular in today's C++.
lol no
That was my reaction as well. I'm surprised that this kind of "deep" analysis is on the front page.
Ok if you want to build drivers or OSes related stuff.
For AAA games, I can understand, but they will not switch to a new language as long as there is no engine like Unreal or Unity3D (GCed) that worth the switch. And the rest are indie and a GC will not affect performance.
For web services, GUI application, the GC would be desirable because it will enable the developper to work on the business model and not the computer model and it will removed stupid memory management kind of bugs. Plus, 1200 fps vs 1120 fps is not faster since we can't see the difference.
Is it that the D's GC is really slow or really memory inefficient?