On 10/6/17 23:19, Brad Roberts wrote:
> On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
>> What if we stop focusing on the C/C++ people so much? The like their
>> tools and have no perceivable interest in moving away from them
>> (Stockholm Syndrome much?). The arguments the use are primarily meant
>> as defensive ploys, because they compare everything to C/C++ and when
>> it doesn't match in some way or another the other language must be
>> deficient. They've already decided that C/C++ is the meter stick
>> against which all other languages are to be judged. Unsurprisingly,
>> nothing that is NOT C/C++ meets their exacting demands.
>>
>> I saw we ditch the lot and focus on the large languages where D can
>> get some traction (C#/Java).
>
> Or recognize that painting huge diverse groups as if there's a single
> brush with which to do so is a huge fallacy.  Consider that the two
> leaders, as well as a large number of the contributing developers, come
> from the c++ community and that's not a bad thing, but rather a big part
> of _why_ they came to D.
>
> As always, focusing on the users of the language tends to pay a lot more
> dividends than focusing on nay sayers.  Luckily, that's how things tend
> to proceed here, so yay for that.

I'll admit the last sentence was an error. However, my main point is that we really need to stop worrying about other languages, and specifically C/C++. That horse has been beat to death. I enjoy using D and find it superior for many types of project. That's good enough for me. :)

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On 10/7/17 14:08, Laeeth Isharc wrote:
>>> On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
>>> > What if we stop focusing on the C/C++ people so much? The > like
>>> their tools and have no perceivable interest in moving > away from
>>> them (Stockholm Syndrome much?). The arguments the > use are
>>> primarily meant as defensive ploys, because they > compare everything
>>> to C/C++ and when it doesn't match in > some way or another the other
>>> language must be deficient. > They've already decided that C/C++ is
>>> the meter stick > against which all other languages are to be judged.
>>> > Unsurprisingly, nothing that is NOT C/C++ meets their > exacting
>>> demands.
>
> Yes - as Andrei said in a talk, people are looking for an excuse not to
> have to take the time to learn something new.  There's an inordinate
> strength of feeling in discussions in relation to D.  If it's not your
> cup of tea, why do you care so much?  The raising of spurious objections
> is much better than indifference at this point, and you can see this
> year that there has been a shift.  People got downvoted for repeating
> the same old talking points that are now demonstrably not correct,
> whereas before it was a matter of judgement and people could reasonably
> differ.
>
>
>> On Friday, October 06, 2017 23:19:01 Brad Roberts via
>>> Or recognize that painting huge diverse groups as if there's a single
>>> brush with which to do so is a huge fallacy.  Consider that the two
>>> leaders, as well as a large number of the contributing developers,
>>> come from the c++ community and that's not a bad thing, but rather a
>>> big part of _why_ they came to D.
>>>
>>> As always, focusing on the users of the language tends to pay a lot
>>> more dividends than focusing on nay sayers.  Luckily, that's how
>>> things tend to proceed here, so yay for that.
>
> Long tail.  We really couldn't care less about what most people think.
> In fact it's good that most people won't try D because what they will be
> expecting isn't yet what we offer (glossiness and hand-holding).
>
> At any one time there is a proportion of people who are unhappy with
> their existing choices and looking for something better.  It's easy to
> grow in the early days - you don't need to appeal to most programmers.
> You just need to have a slightly stronger appeal to those who are
> already predisposed to like you (and to those who are already using your
> language and would like to use it for more things).
>
> And people conceive of the market in too small a way.  People talk as if
> languages are in a battle to the death with each other - D can't succeed
> because it's too late, or because Rust has momentum.  But the world is a
> very big place, and the set of people who talk much to a broad audience
> about what they are doing is a small one and thinking it reflects
> reality leads to distorted perceptions.
>
> Who would have thought that probably one of the larger code bases (500k
> SLOC) to be rewritten/converted in D might come from Pascal, with D
> competing with ADA?  I don't know what has been decided there, but
> whatever the outcome, that's highly interesting, because it's probably
> true of others.
>
> Similarly Weka came from nowhere.  A random tweet by Fowler led to them
> building their entire company on a language the founders hadn't used
> before.
>
> Because D is a highly ambitious language that isn't confined to a single
> domain, and that's a potential replacement in some domains for many
> other languages, most people won't know anyone who uses D because use is
> much more spread out.  Enterprise users outside of web + big
> tech/startups don't talk about their choices that much.  Microsoft
> didn't send out a press release when they used D in their COM team, for
> example - someone there just figured it was a good tool for the job and
> got on with it.  Similarly the company that Andy Smith worked for (a
> money management company) didn't say anything, and it only happened that
> he talked about it because I suggested it and he happened to have time.
>
> Inordinately at this point in its development D is going to appeal to
> principals over agents, to people who have at least local authority to
> make decisions and don't have to persuade others, because the dynamics
> of how you persuade a committee are based on quite different things than
> making a decision and living or dying by how it turns out.
>
> That's okay.  If people don't feel they can use D at work, they
> shouldn't.  Some people will be able to, and as they have some success
> with it, others will start to imitate them.  And in the meantime maybe
> it will be an advantage of sorts for the earlier adopters.
>
> It matters who your customers are, because that shapes what you become.
> And it's better early on to have people who make decisions on technical
> merits and who have the authority to do so, then to have a
> representative enterprise buyer!
>
>
> On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis wrote:
>> Honestly, I've gotten to the point that I don't care much about trying
>> to appeal to folks who complain about D. If we just make the language
>> the best that we can, that will attract folks - that's largely what's
>> attracted them in the past. Sure, we could and probably should do
>> better with marketing D, and some of the complaints that get leveled
>> at the language are valid and should be addressed, but trying to
>> convince folks who are already convinced that they don't like D just
>> doesn't seem like a good way to spend our time and energy.
>
> I agree with both parts.  It doesn't do any harm to continue to work on
> getting the language's merits across.  There's no point entirely hiding
> our light under a bushel.  But doing good work and making the language
> and ecosystem better is by far more important because that's what
> matters and we're in a time when people will eventually get it even if
> they don't all currently.
>
>> Complaints from folks not using D _can_ help shows us areas in which
>> we're deficient, but they're not necessarily right, and they're not
>> our actual user base.
> Yes.  (I'd put the emphasis on _help_)
>
>
>> And really, what we need is a good language with good tools that
>> supports a vibrant community of those who want to use it. We want that
>> community to grow, because it will help the language and make it
>> easier to get jobs using it, but it's not like we need to convince the
>> whole world to use D - not to mention that there are classes of folks
>> that we don't want; their views and goals just differ too much from ours
>
> People seem to think language decisions are only about technical
> questions.  But they're as much about values, and you're never going to
> get people to agree about values because people are facing different
> problems and are themselves different kinds of people.
>
> https://vimeo.com/230142234  Bryan Cantrill of Joyent nails it
>
>
>>  which is part of why having a diverse set of languages out there can
>> actually be valuable. Different folks prefer different languages, and
>> trying to get everyone to agree is never going to work. As long as D
>> is sucessful enough that those of us who want to use it can use it and
>> do what we need to get done, then that should be plenty. If more folks
>> decide that they like what D's offering, then great. If they prefer
>> C++ or C# or Rust or whatever, then they can have fun doing whatever
>> they need to do with those languages, and we won't have to make
>> changes to D just to make them happy.
>>
>> - Jonathan M Davis
>
>
> In a polyglot environment, D's code generation and introspection
> abilities might be quite valuable if it allows you to write core
> building blocks once and call them from other languages without too much
> boilerplate and bloat.  One could use SWIG, but...

Oh dear, I seem to have accidentally set off a firestorm.

Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them.

I like D because I get a language that feels comfortably similar to C#/Java, than adds a bunch of really useful tools on top of it, and is natively compiled. Instead of worrying about how to get more people to come from a specific language. People will come if they see an advantage in D so lets try to provide as many advantages as possible. :)

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
> On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
>> D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting.
>>
>> We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; @nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense.
>>
>> Honestly, I would _hate_ to use D without a GC. Without it, @safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of @trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory.
>>
>> That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed).
>>
>> Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC.
>>
>> - Jonathan M Davis
>
> The issue is only mentioned, because it keeps getting talked about ( mostly one sided ) on forums and sites like the above mentioned quora.com. Its hard to change people there perception, without counter arguing. Currently as i write this, these claims on quora are unchallenged.
>
> I can make a few simple demos and have D use by default 5 to 10 more memory then the exact same C or C++ program. While D does not actually use it ( its only marked as allocated for the GC ), it does not dispel the notion or feeling of people that a GC = bad.
>
> Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language. The Go developers have done a massive ( an impressive ) amount of work on trying to reduce GC pauses in the last two years, and that communication and effort has helped to reduce the GC myth ( for people looking at Go ).
>
> Another part of the issue is, while D can be run without the GC, i can not tell what parts of the standard library can work without the GC. Even a simple output parsing gave me a compile error when running nogc a while ago.
>
> When every new languages besides Rust or Zig are GC. That same "flaw" is not looked upon as a issue. It seems that D simply carries this GC stigma because the people mentioning are  C++ developers, the same people D targets as a potential user base.
>
> D can have more success in targeting people from scripting languages like PHP, Ruby, Python, where the GC is not looked upon as a negative. The same effect can be seen in Go its popularity with drawing developers from scripting languages despite it not being there intention.
>
> I always felt that D position itself as a higher language and in turn scares people away while at the same time the people it wants to attracts, with most are already set in there ways and looking at excuses to discredit D. The whole C++ has all of D features and does not need a GC / GC is bad excuse we see in the quora.com posting fits that description ( and not only there, also on other sites ).
>
> If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).

+1

But you are losing your time trying to convince D's management that targeting C++ developers instead of scripters is a marketing error.

For instance, I AM a C++ developer, and I use D EXCLUSIVELY for SCRIPTING tasks. Nothing else.

And if you had asked me why I use D then, I would have answered : it's because it's faster and more effective than JavaScript/Node.js, Python and Ruby for these tasks.

GC IS NOT A PROBLEM for scripting. We don't care about that. GC IS NEEDED for scripting languages.

But as a C++ developer, I can tell you that : D's GC is what prevents me to use it for my current C++ programming tasks.

Because I can perfectly live with a GC that progressively collects bits of memory in a predefined amount of time, like in the Nim language, but not one that can pause my application for an unpredictable amount of time.

That's just my personal case and opinion, but I don't think I'm the only C++ programmer on the planet to dislike D's GC for typical C++ development cases, which are generally those where the lack of a GC is the reason that lead to the use of C++.

> If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).

At the moment, for very demanding high-performance web applications, the main choices are :
- Dart
- Go
- C/C++
- Java/Kotlin

This is somewhat confirmed by the following benchmark (despite its well known flaws) :

https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query

I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go.

But only if :
- the fibers automatically uses all cores if allowed to do so;
- the GC problems is designed so that the server never hangs for more than a few milliseconds IN THE WORST CASE (progressive GC)
- dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and database access (MySQL, PostgreSQL, Aerospike) libraries are available, preferably as a standard library (like in Dart and Go).

And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart.

If all that is already available, perfect :)

Then we just need to add the D version of the benchmarks, and the marketing is done.

And moreover I'd be delighted to start using D instead of Go for my next web server developments.

On Sunday, 15 October 2017 at 10:09:02 UTC, Ecstatic Coder wrote:
>> If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).
>
> At the moment, for very demanding high-performance web applications, the main choices are :
> - Dart
> - Go
> - C/C++
> - Java/Kotlin
>
> This is somewhat confirmed by the following benchmark (despite its well known flaws) :
>
> https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query
>
> I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go.
>
> But only if :
> - the fibers automatically uses all cores if allowed to do so;

Even if a given fiber is pinned to particular core it will be balanced with typical http request/response model where you have LOTs of short-lived requests. So no changes required.

> - the GC problems is designed so that the server never hangs for more than a few milliseconds IN THE WORST CASE (progressive GC)

Actually prioritizing low latency will hurt RPS you seem to care about. Java can easily stay in top 20 with pauses of up to ~100ms.

> - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and

Might work. In this benchmark it’s hardly the bottleneck, the hardware used can crank out millions of HTTP responses per second.

> database access (MySQL, PostgreSQL, Aerospike) libraries are available,

That is important actually.

> preferably as a standard library (like in Dart and Go).

Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.

>
> And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart.
>

Well I kind if doing this for Regex at times.
Ilia did this with BLAS libraries. If we had a dozen more of performance maniacs with plenty of spare time we’d win every silly benchmark.

> If all that is already available, perfect :)
[snip]
> And moreover I'd be delighted to start using D instead of Go for my next web server developments.

You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.

techempower bench is not good. It is wierd. On my pc vibe.d is much faster with techempower benchmark. So I do not beleive their results

Dne 15. 10. 2017 12:10 odpoledne napsal uživatel "Ecstatic Coder via Digitalmars-d" <digitalmars-d@puremagic.com>:

If the GC issue can not be tackled and even with the recent communication
> blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).
>

At the moment, for very demanding high-performance web applications, the
main choices are :
- Dart
- Go
- C/C++
- Java/Kotlin

This is somewhat confirmed by the following benchmark (despite its well
known flaws) :

https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query

I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go.

But only if :
- the fibers automatically uses all cores if allowed to do so;
- the GC problems is designed so that the server never hangs for more than
a few milliseconds IN THE WORST CASE (progressive GC)
- dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and database access
(MySQL, PostgreSQL, Aerospike) libraries are available, preferably as a
standard library (like in Dart and Go).

And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart.

If all that is already available, perfect :)

Then we just need to add the D version of the benchmarks, and the marketing is done.

And moreover I'd be delighted to start using D instead of Go for my next web server developments.

On Sunday, 15 October 2017 at 12:14:02 UTC, Dmitry Olshansky wrote:
> On Sunday, 15 October 2017 at 10:09:02 UTC, Ecstatic Coder wrote:
>>> If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).
>>
>> At the moment, for very demanding high-performance web applications, the main choices are :
>> - Dart
>> - Go
>> - C/C++
>> - Java/Kotlin
>>
>> This is somewhat confirmed by the following benchmark (despite its well known flaws) :
>>
>> https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query
>>
>> I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go.
>>
>> But only if :
>> - the fibers automatically uses all cores if allowed to do so;
>
> Even if a given fiber is pinned to particular core it will be balanced with typical http request/response model where you have LOTs of short-lived requests. So no changes required.
>
>> - the GC problems is designed so that the server never hangs for more than a few milliseconds IN THE WORST CASE (progressive GC)
>
> Actually prioritizing low latency will hurt RPS you seem to care about. Java can easily stay in top 20 with pauses of up to ~100ms.
>
>> - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and
>
> Might work. In this benchmark it’s hardly the bottleneck, the hardware used can crank out millions of HTTP responses per second.
>
>> database access (MySQL, PostgreSQL, Aerospike) libraries are available,
>
> That is important actually.
>
>> preferably as a standard library (like in Dart and Go).
>
> Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
>
>>
>> And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart.
>>
>
> Well I kind if doing this for Regex at times.
> Ilia did this with BLAS libraries. If we had a dozen more of performance maniacs with plenty of spare time we’d win every silly benchmark.
>
>> If all that is already available, perfect :)
> [snip]
>> And moreover I'd be delighted to start using D instead of Go for my next web server developments.
>
> You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.

Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.

Can you just confirm that D's fibers use most of the available processors/cores by default ?

I think this is quite automatic with Elixir's Phoenix framework.

http://phoenixframework.org/blog/the-road-to-2-million-websocket-connections
(one more silly benchmark btw, they just open the connections without doing anything useful with them)

Btw, when I say you can actually develop complete web servers in Dart and Go just with the components provided in the standard libraries, I really mean it, even if I personally also use higher level external libraries/frameworks (from Github), which extend the lower level components of Go's standard library.

On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote:
> On Sunday, 15 October 2017 at 12:14:02 UTC, Dmitry Olshansky wrote:
>>> If all that is already available, perfect :)
>> [snip]
>>> And moreover I'd be delighted to start using D instead of Go for my next web server developments.
>>
>> You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
>
> Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.

So are the problems you listed not important for the decision or the answers are not convincing?
>
> Can you just confirm that D's fibers use most of the available processors/cores by default ?
>

There is no “by default” in any non-managed language. If you are coming from C++ I’m really surprised to see this turn of phrase.

Speaking of defaults - Vibe.d is built on Fibers and has muliti-core mode that scales. It may have some issues on huge number of cores but it does work.

> I think this is quite automatic with Elixir's Phoenix framework.

I take it Phoenix framework is “default” in Elixir? :)
>
> http://phoenixframework.org/blog/the-road-to-2-million-websocket-connections
> (one more silly benchmark btw, they just open the connections without doing anything useful with them)
>
> Btw, when I say you can actually develop complete web servers in Dart and Go just with the components provided in the standard libraries, I really mean it, even if I personally also

I programmed in Go.
I also was part of Dart team for about a year.
So yeah, I know what you mean.

> use higher level external libraries/frameworks (from Github), which extend the lower level components of Go's standard library.

You can with C’s standard library. It’s all a matter of perspective and amount of stuff in std vs amount of your code on top.

IMHO what I see is that everybody goes on to invent a library that is somehow better than std lib one.

>> database access (MySQL, PostgreSQL, Aerospike) libraries are available,
>
> That is important actually.
>

So important that it should be a Priority 0 Must Have.

>> preferably as a standard library (like in Dart and Go).
>
> Can’t do that. And it’s not standard in Go and Dart but packages, dub
> should work for that.
>

I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard library...

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Saturday, 14 October 2017 at 22:43:33 UTC, Adam Wilson wrote:
> On 10/7/17 14:08, Laeeth Isharc wrote:

>>
>> In a polyglot environment, D's code generation and introspection
>> abilities might be quite valuable if it allows you to write core
>> building blocks once and call them from other languages without too much
>> boilerplate and bloat.  One could use SWIG, but...
>
> Oh dear, I seem to have accidentally set off a firestorm.
>
> Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them.

If we can convert Pascal users, why won't some C# and Java programmers be receptive to D?  Plenty of people have approached D from Java:

https://dlang.org/blog/2017/09/06/the-evolution-of-the-accessors-library/
https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/
https://github.com/intellij-dlanguage/intellij-dlanguage/
(Kingsley came from Java).

Why can't we easily interop with Java and C#?  I didn't find interop with Java so bad for what I was doing (embedding a Java library via the JVM with callbacks to D code), and Andy Smith found similar.

http://dconf.org/2015/talks/smith.pdf
(towards the end)

C# interop for what I am doing sees easy enough.  (I will generate C# wrappers for D structs and functions/methods).

This work wasn't open-sourced, and nor did Microsoft send out a press release about their use of D in the COM team.  But I spoke to the author in Berlin (maybe you did too), and it wasn't so much work to make it useful:

http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf


> Instead of worrying about how to get more people to come from a specific language. People will come if they see an advantage in D so lets try to provide as many advantages as possible. :)

Yes - agree with this.