www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some Notes on 'D for the Win'

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

http://tomerfiliba.com/blog/dlang-part2/
Aug 23 2014
next sibling parent reply "nan0a" <nan0a gmail.com> writes:
On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
I posted in the thread (under the same name as here) and regularly discuss D in /r/programming. I really enjoy trying out new languages and I think D is excellent - I was up and running in it in just a few days. TDP+Ali's book are great references. One of the things I like the best about D is the community, it's very lively. I have a few complaints about the language because nothing is perfect(e.g, attribute puke), but overall I find the language extremely usable. Rust was mentioned a few times in the thread -- I've been using Rust for a while too(which I see constantly mentioned anytime D is) and I'm always tripping over my own feet trying to understand the memory/type system, lifetimes, etc. I'm not even going to claim that I'm a good programmer, but I'm not sure how I feel about Rust being widely adopted outside of extremely memory-safe applications(e.g, Mozilla's Servo.) The obvious ML/functional inspiration is also going to be a stumbling block for C/C++/Java/etc programmers IMO, I've done some hobby work with Haskell so I wasn't exactly fish out of water but I could understand why some may be. Keep up the great work on D.
Aug 23 2014
next sibling parent "eles" <eles215 gzk.dot> writes:
On Saturday, 23 August 2014 at 20:23:37 UTC, nan0a wrote:
 On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright 
 wrote:
 language because nothing is perfect(e.g, attribute puke), but
Yeah, this should be addressed. Eventually...
Aug 23 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 23 August 2014 at 20:23:37 UTC, nan0a wrote:
 On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright 
 wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
I posted in the thread (under the same name as here) and regularly discuss D in /r/programming. I really enjoy trying out new languages and I think D is excellent - I was up and running in it in just a few days. TDP+Ali's book are great references. One of the things I like the best about D is the community, it's very lively. I have a few complaints about the language because nothing is perfect(e.g, attribute puke), but overall I find the language extremely usable. Rust was mentioned a few times in the thread -- I've been using Rust for a while too(which I see constantly mentioned anytime D is) and I'm always tripping over my own feet trying to understand the memory/type system, lifetimes, etc. I'm not even going to claim that I'm a good programmer, but I'm not sure how I feel about Rust being widely adopted outside of extremely memory-safe applications(e.g, Mozilla's Servo.) The obvious ML/functional inspiration is also going to be a stumbling block for C/C++/Java/etc programmers IMO, I've done some hobby work with Haskell so I wasn't exactly fish out of water but I could understand why some may be. Keep up the great work on D.
I sometimes have the feeling that because the D community discusses every tiny feature or change elaborately (and rightly so), people coming from the outside have the impression that it's a half-baked (and thus unreliable) thing. Other languages often just "cover up" the discussions, or in the case of Go, decisions are presented post factum (with a lot of hype and "Hurra!" around them), which gives the impression of a clean and tight (and thus reliable) project. The changes to D (especially new killer features, improved libraries and the like) are often not communicated to the general public (as in "This is new, and this is how you use it"). So people from the outside have the impression that it's a bit of a mess and they are ignorant as regards features and improvements. Maybe that's part of the "anti D" attitude often encountered.
Aug 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 11:20:51 UTC, Chris wrote:
 I sometimes have the feeling that because the D community 
 discusses every tiny feature or change elaborately (and rightly 
 so), people coming from the outside have the impression that 
 it's a half-baked (and thus unreliable) thing.
How is it not half-baked when DMD is released with regressions? D lacks proper quality assurance and a clear distinction by experimental releases/features and production quality. Features should have at least 6-12 months of testing before being used in production, IMO.
 Other languages often just "cover up" the discussions, or in 
 the case of Go, decisions are presented post factum (with a lot 
 of hype and "Hurra!" around them), which gives the impression 
 of a clean and tight (and thus reliable) project.
Go has reached feature stability and does not push experimental features into the production compiler. The libraries are limited in scope and thus of reasonable quality AFAIK. Note that on Google App Engine the Go runtime is still listed as experimental. Only Java 7 and Python 2.7 are labeled as ready for production. The problem is that D will stay at 95% done forever without proper management. A common thumb-of-rule is that 90% remains to be done when 90% of the code is written. I.e. the final polish, refactoring and maintenance is the most work. Don't underestimate the importance of the last 5%. Go is lack-lustre, but it is more mature than D.
 So people from the outside have the impression that it's a bit 
 of a mess and they are ignorant as regards features and 
 improvements.
The process is a mess if you don't do feature freeze on one version that is mature and keep it in maintenance mode (only receiving safety bug fixes and focusing on stability).
Aug 25 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 25 August 2014 at 12:35:51 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 25 August 2014 at 11:20:51 UTC, Chris wrote:
 I sometimes have the feeling that because the D community 
 discusses every tiny feature or change elaborately (and 
 rightly so), people coming from the outside have the 
 impression that it's a half-baked (and thus unreliable) thing.
How is it not half-baked when DMD is released with regressions? D lacks proper quality assurance and a clear distinction by experimental releases/features and production quality. Features should have at least 6-12 months of testing before being used in production, IMO.
 Other languages often just "cover up" the discussions, or in 
 the case of Go, decisions are presented post factum (with a 
 lot of hype and "Hurra!" around them), which gives the 
 impression of a clean and tight (and thus reliable) project.
Go has reached feature stability and does not push experimental features into the production compiler. The libraries are limited in scope and thus of reasonable quality AFAIK. Note that on Google App Engine the Go runtime is still listed as experimental. Only Java 7 and Python 2.7 are labeled as ready for production. The problem is that D will stay at 95% done forever without proper management. A common thumb-of-rule is that 90% remains to be done when 90% of the code is written. I.e. the final polish, refactoring and maintenance is the most work. Don't underestimate the importance of the last 5%. Go is lack-lustre, but it is more mature than D.
 So people from the outside have the impression that it's a bit 
 of a mess and they are ignorant as regards features and 
 improvements.
The process is a mess if you don't do feature freeze on one version that is mature and keep it in maintenance mode (only receiving safety bug fixes and focusing on stability).
I'd say half-baked refers to real world usability. Nimrod would be half-baked, because it is still young and a lot of features will change (breaking changes). The language sounds interesting, but I wouldn't touch it right now. D on the other hand is already perfectly usable for production code, which, for me, is the most important thing. Whether or not the whole infrastructure is good enough (there's always room for improvement) is not so important for this particular aspect (i.e. actual coding). I started to use D before dub was the official package manager. Although I use dub a lot now, I could manage without it for two or more years (which in turn says a lot about D itself). Here's a list of Go apps: http://go-lang.cat-v.org/go-code Similar to D apps. Some of them still going, some of them in a limbo, some of them dead (would be nice to know why they were discontinued). I wonder how safe it would be to use Go in production (breaking changes, availability / implementation of useful features etc.)
 Note that on Google App Engine the Go runtime is still listed 
 as experimental. Only Java 7 and Python 2.7 are labeled as 
 ready for production.
They are listed as "experimental" partly for legal reasons, I suppose, and "ready for production" still means "experimental". All software is experimental. No matter how you label it. Java has moved very slowly over the years and I think Go has kind of slowed down a bit. D is still moving quite fast as regards adding features and improvements and is remarkably stable and reliable.
Aug 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 13:30:45 UTC, Chris wrote:
 D on the other hand is already perfectly usable for production 
 code, which, for me, is the most important thing.
That would depend on what you mean by "usable for production code". For me "usable" means that I can fix compiler/library bugs by recompiling the project 12 months from now without any source code changes. It also means no regressions and a long testing window.
 Whether or not the whole infrastructure is good enough (there's 
 always room for improvement) is not so important for this 
 particular aspect (i.e. actual coding).
Well, I think it is important that you cannot know which part of Phobos you can rely on. The basic problem here is that the D "managers" think that the language will take off if it gains more features. So new features are eagerly pushed without polish and serious harnessing. I think the opposite is true, I think it will take off when people see that the distributed tar-ball only includes code that is polished and harnessed. (leaving the less robust stuff to other repositories or as an experimental switch)
 discontinued). I wonder how safe it would be to use Go in 
 production (breaking changes, availability / implementation of 
 useful features etc.)
Pretty safe! https://golang.org/doc/devel/release.html
 Note that on Google App Engine the Go runtime is still listed 
 as experimental. Only Java 7 and Python 2.7 are labeled as 
 ready for production.
They are listed as "experimental" partly for legal reasons, I suppose, and "ready for production" still means "experimental". All software is experimental. No matter how you label it.
For contractual reasons, but based on real world management needs. The Java and Python runtimes have a stable configuration window of 12 months (meaning no changes without 12 months notice). While Go and PhP can be dropped by Gogle over night IIRC. So, Go is not useful for production on App Engine unless you do double implementation (like reimplementing parts in Go for performance reasons).
Aug 25 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 13:51:22 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 discontinued). I wonder how safe it would be to use Go in=20
 production (breaking changes, availability / implementation of=20
 useful features etc.)
Pretty safe! =20 While Go and PhP can be dropped by Gogle over night IIRC.
pretty safe.
Aug 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 14:04:03 UTC, ketmar via 
Digitalmars-d wrote:
 On Mon, 25 Aug 2014 13:51:22 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 discontinued). I wonder how safe it would be to use Go in 
 production (breaking changes, availability / implementation 
 of useful features etc.)
Pretty safe! While Go and PhP can be dropped by Gogle over night IIRC.
pretty safe.
It is. You can use Go on Compute Engine.
Aug 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 14:07:53 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 It is. You can use Go on Compute Engine.
i can use D in production. i'm pretty sure that current GDC will not rot after five years: i will stil be able to build gcc 4.9.1 and gdc with 2.065 backend, then fix and compile my code. what's wrong with it?
Aug 25 2014
prev sibling next sibling parent reply "eles" <eles215 gzk.dot> writes:
On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
Comment: "The only thing I hate about D is the GC, I think that to include a GC in a system programming language like D was a very big mistake... I know it's possible to disable the GC but its standard library needs it so you must live with it."
Aug 23 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 23 August 2014 at 21:52:01 UTC, eles wrote:
 On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright 
 wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
Comment: "The only thing I hate about D is the GC, I think that to include a GC in a system programming language like D was a very big mistake... I know it's possible to disable the GC but its standard library needs it so you must live with it."
Examples of real, working desktop OS, that people really used at their work, done in system programming languages with GC. Mesa/Cedar https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000 Oberon and derivatives http://progtools.org/article.php?name=oberon§ion=compilers&type=tutorial SPIN http://en.wikipedia.org/wiki/Modula-3 http://en.wikipedia.org/wiki/SPIN_%28operating_system%29 What is really needed for the average Joe systems programmer to get over this "GC in systems programming" stygma, is getting the likes of Apple, Googlel, Microsoft and such to force feed them into programming languages. The day when Swift, .NET Native, Go (with better low level support) are the languages on their SDKs. It doesn't help that Singularity project died, and outside Microsoft no one knows what Midori (its sucessor) is about. Maybe Facebook could do an operating system in D. :) -- Paulo
Aug 23 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/24/2014 2:39 AM, Paulo Pinto wrote:
 Maybe Facebook could do an operating system in D. :)
The way facebook's been growing/expanding (ex, oculus rift. Bought by a social networking site? Go figure.), I wouldn't be surprised to see a facebook OS some day.
Aug 24 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Aug-2014 23:31, Nick Sabalausky пишет:
 On 8/24/2014 2:39 AM, Paulo Pinto wrote:
 Maybe Facebook could do an operating system in D. :)
The way facebook's been growing/expanding (ex, oculus rift. Bought by a social networking site? Go figure.), I wouldn't be surprised to see a facebook OS some day.
Written in D, of course :) -- Dmitry Olshansky
Aug 24 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/24/2014 3:34 PM, Dmitry Olshansky wrote:
 24-Aug-2014 23:31, Nick Sabalausky пишет:
 On 8/24/2014 2:39 AM, Paulo Pinto wrote:
 Maybe Facebook could do an operating system in D. :)
The way facebook's been growing/expanding (ex, oculus rift. Bought by a social networking site? Go figure.), I wouldn't be surprised to see a facebook OS some day.
Written in D, of course :)
That would indeed be a heck of a feather in D's cap. I mean, heck, PHP is easily one of the worst languages in major use, and one of the biggest reasons^H^H^H^H^H^H^Hexcuses people have given for using it is "Well, Facebook is written in PHP!" - Even years after that statement had become woefully inaccurate (half the codebase in C/C++ including all/most of the critical stuff plus the "PHP" stuff not being normal PHP but the third incarnation of their own rewrite - Yea, not exactly "Is written in PHP"). Point of course being: Given what facebook "endorsement" (sort of) has done for *PHP*, even when it wasn't even entirely true(!), imagine what a boon *true* largescale FB usage could do for a language like D. Or even if not, at the very least it would get people to knock it off with the appeal-to-authority language selection arguments ;)
Aug 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 24 Aug 2014 23:15:53 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Or even if not, at the very least it would get people to knock it off=20
 with the appeal-to-authority language selection arguments ;)
yeah, sometimes "but look at FB! they using D and hired it's core developers!" works better than any technical arguments. i'm not happy with this, but if it works...
Aug 24 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 24 Aug 2014 06:39:28 +0000
schrieb "Paulo Pinto" <pjmlp progtools.org>:

 Examples of real, working desktop OS, that people really used at 
 their work, done in system programming languages with GC.
 
 Mesa/Cedar
 https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000
 
 Oberon and derivatives
 http://progtools.org/article.php?name=oberon§ion=compilers&type=tutorial
 
 SPIN
 http://en.wikipedia.org/wiki/Modula-3
 http://en.wikipedia.org/wiki/SPIN_%28operating_system%29
 
 What is really needed for the average Joe systems programmer to 
 get over this "GC in systems programming" stygma, is getting the 
 likes of Apple, Googlel, Microsoft and such to force feed them 
 into programming languages.
Yes, but when these systems were invented, was the focus on a fast lag free multimedia experience or on safety? How do you get the memory for the GC heap, when you are just about to write the kernel that manages the systems physical memory? Do these systems manually manage memory in performance sensitive parts or do they rely on GC as much as technically feasible? Could they use their languages as is or did they create a fork for their OS? What was the expected memory space at the time of authoring the kernel? Does the language usually allow raw pointers, unions, interfacing with C etc., or is it more confined like Java? I see how you can write an OS with GC already in the kernel or whatever. However there are too many question marks to jump to conclusions about D. o the larger the heap the slower the collection cycles (how will it scale in the future with e.g. 1024 GiB RAM?) o the less free RAM, the more often the collector is called (game consoles are always out of RAM) o tracing GCs have memory overhead (memory, that could have been used as disk cache for example) o some code needs to run in soft-real-time, like audio processing plugins; stop-the-world GC is bad here o non-GC threads are still somewhat arcane and system specific o if you accidentally store the only reference to a GC heap object in a non-GC thread it might get collected (a hypothetical or existing language may have a better offering here) "For programs that cannot afford garbage collection, Modula-3 provides a set of reference types that are not traced by the garbage collector." Someone evaluating D may come across the question "What if I get into one of those 10% of use case where tracing GC is not a good option?" It might be some application developer working for a company that sells video editing software, that has to deal with complex projects and object graphs, playing sounds and videos while running some background tasks like generating preview versions of HD material or auto-saving and serializing the project to XML. Or someone writing an IDE auto-completion plugin that has graphs of thousands of small objects from the source files in import paths that are constantly modified while the user types in the code-editor. Plus anyone who finds him-/herself in a memory constrained and/or (soft-)realtime environment. Sometimes it results in the idea that D's GC is some day going to be as fast as the primary one in Java or C#, which people found to be acceptable for soft-real-time desktop applications. Others start contemplating if it is worth writing their own D runtime to remove the stop-the-world GC entirely. Personally I mostly want to be sure Phobos is transparent about GC allocations and that not all threads stop for the GC cycle. That should make soft-real-time in D a lot saner :) -- Marco
Aug 25 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
On 25.08.2014 12:14, Marco Leise wrote:
 Am Sun, 24 Aug 2014 06:39:28 +0000
 schrieb "Paulo Pinto" <pjmlp progtools.org>:

 Examples of real, working desktop OS, that people really used at
 their work, done in system programming languages with GC.

 Mesa/Cedar
 https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000

 Oberon and derivatives
 http://progtools.org/article.php?name=oberon§ion=compilers&type=tutorial

 SPIN
 http://en.wikipedia.org/wiki/Modula-3
 http://en.wikipedia.org/wiki/SPIN_%28operating_system%29

 What is really needed for the average Joe systems programmer to
 get over this "GC in systems programming" stygma, is getting the
 likes of Apple, Googlel, Microsoft and such to force feed them
 into programming languages.
Yes, but when these systems were invented, was the focus on a fast lag free multimedia experience or on safety?
BlueBottle an Oberon sucessor has a video player. Codecs are written in Assembly everything else in Active Oberon. This is no different from using C, as the language does not support vector instructions.
 How do you
 get the memory for the GC heap, when you are just about to
 write the kernel that manages the systems physical memory?
Easy, the GC lives at the kernel.
 Do these systems manually manage memory in performance
 sensitive parts or do they rely on GC as much as technically
 feasible?
They are a bit more GC friendly than D. Only memory allocated via NEW is on the GC heap. Additionally, there is also the possibility to use manual memory management, but only inside UNSAFE modules.
 Could they use their languages as is or did they
 create a fork for their OS? What was the expected memory space
 at the time of authoring the kernel? Does the language usually
 allow raw pointers, unions, interfacing with C etc., or is it
 more confined like Java?
I am lost here. These languages have a symbiotic relationship with the OS, just like C has with UNIX. Thankfully no C at sight. Spin does support C and has a POSIX interface implemented in Modula-3, though.
 I see how you can write an OS with GC already in the kernel or
 whatever. However there are too many question marks to jump to
 conclusions about D.

 o the larger the heap the slower the collection cycles
    (how will it scale in the future with e.g. 1024 GiB RAM?)
 o the less free RAM, the more often the collector is called
    (game consoles are always out of RAM)
 o tracing GCs have memory overhead
    (memory, that could have been used as disk cache for example)
 o some code needs to run in soft-real-time, like audio
    processing plugins; stop-the-world GC is bad here
 o non-GC threads are still somewhat arcane and system
    specific
 o if you accidentally store the only reference to a GC heap
    object in a non-GC thread it might get collected
    (a hypothetical or existing language may have a better
    offering here)

 "For programs that cannot afford garbage collection, Modula-3
 provides a set of reference types that are not traced by the
 garbage collector."
 Someone evaluating D may come across the question "What if I
 get into one of those 10% of use case where tracing GC is not
 a good option?" It might be some application developer working
 for a company that sells video editing software, that has to
 deal with complex projects and object graphs, playing sounds
 and videos while running some background tasks like generating
 preview versions of HD material or auto-saving and serializing
 the project to XML.
 Or someone writing an IDE auto-completion plugin that has
 graphs of thousands of small objects from the source files in
 import paths that are constantly modified while the user types
 in the code-editor.
 Plus anyone who finds him-/herself in a memory constrained
 and/or (soft-)realtime environment.

 Sometimes it results in the idea that D's GC is some day going
 to be as fast as the primary one in Java or C#, which people
 found to be acceptable for soft-real-time desktop applications.
 Others start contemplating if it is worth writing their own D
 runtime to remove the stop-the-world GC entirely.
 Personally I mostly want to be sure Phobos is transparent about
 GC allocations and that not all threads stop for the GC cycle.
 That should make soft-real-time in D a lot saner :)
Those questions I can hardly answer due to lack of experience. I can only tell that we have replaced C++ applications by Java ones for telecommunications control and they perform fast enough. The same type of work Erlang is used for. Another thing is that many programmers don't know how to use profilers. I was able in some cases, thanks to memory profilers, to have a better memory use in Java/C#, than the legacy application done with the standard malloc that was part of the compiler. But this will only change with generation change. -- Paulo
Aug 25 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
Just spent some time reading about Nimrod. It looks like it has a lot of potential. One quote from the FAQ: "Nimrod primarily focuses on thread local (and garbage collected) heaps and asynchronous message passing between threads. Each thread has its own GC, so no "stop the world" mechanism is necessary. An unsafe shared memory heap is also provided. Future versions will additionally include a GC "per thread group" and Nimrod's type system will be enhanced to accurately model this shared memory heap." Cool! When I first started reading about D, I was quite excited (still am, but certainly frustrated with a few things). I never felt that level of excitement when I read about Go and Rust. I never even thought about them as competitors with D. But Nimrod has perked my interested. It looks like much more of a competitor with D than Go and Rust. Mike
Aug 23 2014
parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 23 August 2014 at 23:46:43 UTC, Mike wrote:
 One quote from the FAQ:
 "Nimrod primarily focuses on thread local (and garbage 
 collected) heaps and asynchronous message passing between 
 threads. Each thread has its own GC, so no "stop the world" 
 mechanism is necessary. An unsafe shared memory heap is also 
 provided.
Do you have an idea, how Nimrod shares memory? Thread-local GCs mean the memory should be deep copied between threads, which is not always a good idea, e.g. when you receive a big complex data structure from network in one thread and pass it to the main thread.
Aug 24 2014
parent "Kagamin" <spam here.lot> writes:
Though it will be a big win for server software, which rarely 
shares memory.
Aug 24 2014
prev sibling parent "ixid" <nuaccount gmail.com> writes:
On Saturday, 23 August 2014 at 18:29:43 UTC, Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/2ed9ah/some_notes_on_d_for_the_win/

 http://tomerfiliba.com/blog/dlang-part2/
I'd surprised not to have seen anyone point this out (perhaps I missed it)given all the talk of niches for D. D should be promoted as the start up language. That's what it's try to do by being highly productive but also offering serious performance and some start up people are more willing to take a risk to get an edge. It would also give D some serious cool. Perhaps that's how to market it?
Aug 25 2014