www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Java binaries

reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
Would it ever be possible to compile D source directly to java to 
take advantage of what java offers. (e.g., the ability to run d 
code inside a browser)

I'm not talking about necessarily fully fledged 
functionality(obviously stuff like asm isn't going to work) but 
basically the ability to use D's syntax and some of it's compiler 
features(mixins, templates, etc).
Feb 16 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/16/2013 7:26 PM, js.mdnq wrote:
 Would it ever be possible to compile D source directly to java to take
advantage
 of what java offers. (e.g., the ability to run d code inside a browser)

 I'm not talking about necessarily fully fledged functionality(obviously stuff
 like asm isn't going to work) but basically the ability to use D's syntax and
 some of it's compiler features(mixins, templates, etc).

Java doesn't have pointers, so right off the bat there'd be big problems.
Feb 16 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/17/2013 1:46 AM, Russel Winder wrote:
 The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D
 only really has a play in one of these, and needs to get real traction
 there first before looking for new lands to conquer. Else it risks being
 seen as a solution looking for a problem to solve.

I agree. There was at one time a D implementation on .net, but it suffered from .net's lack of support for pointers, which meant that slices performed poorly.
Feb 17 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 17.02.2013 21:47, schrieb Walter Bright:
 On 2/17/2013 1:46 AM, Russel Winder wrote:
 The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D
 only really has a play in one of these, and needs to get real traction
 there first before looking for new lands to conquer. Else it risks being
 seen as a solution looking for a problem to solve.

I agree. There was at one time a D implementation on .net, but it suffered from .net's lack of support for pointers, which meant that slices performed poorly.

So how are C++ and C# pointers done in IL ?
Feb 19 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.02.2013 22:59, schrieb rumbu:
 On Tuesday, 19 February 2013 at 21:30:53 UTC, Paulo Pinto wrote:
 Am 17.02.2013 21:47, schrieb Walter Bright:
 On 2/17/2013 1:46 AM, Russel Winder wrote:
 The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D
 only really has a play in one of these, and needs to get real traction
 there first before looking for new lands to conquer. Else it risks
 being
 seen as a solution looking for a problem to solve.

I agree. There was at one time a D implementation on .net, but it suffered from .net's lack of support for pointers, which meant that slices performed poorly.

So how are C++ and C# pointers done in IL ?

There are two kind of pointers in C#: managed and unmanaged. Wrapped in a fixed statement (just to tell the garbage collector to keep fixed references), C# pointers will behave like any native language pointer. This is not the first topic where I read that misconception that slices are a problem for IL. From .net 2.0 (9 years ago) there is the ArraySegment<T> type doing exactly what D slices do. Also, in C# arrays are implicitely convertible to pointers. ...

I know .NET since the early pre-Beta days as my employer at the time, had the privilege to be one of the few Microsoft Partners in Portugal with access to the technology. In those days I did some C# <=> C++ integration work by means of Managed C++, later superseded by C++/CLI. Hence my question. :) -- Paulo
Feb 19 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/19/2013 10:59 PM, rumbu wrote:
 ...

 Anyway, I don't see any use for a D IL compiler, since probably the
 language syntax will look 90% like C#.

Even if that was true, so what?
Feb 19 2013
prev sibling next sibling parent "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright wrote:
 On 2/16/2013 7:26 PM, js.mdnq wrote:
 Would it ever be possible to compile D source directly to java 
 to take advantage
 of what java offers. (e.g., the ability to run d code inside a 
 browser)

 I'm not talking about necessarily fully fledged 
 functionality(obviously stuff
 like asm isn't going to work) but basically the ability to use 
 D's syntax and
 some of it's compiler features(mixins, templates, etc).

Java doesn't have pointers, so right off the bat there'd be big problems.

Java does have pointers... you just can't get to them easily. At the very least, you could allocate and manage your own chunk of memory and do all the pointer arithmetic yourself on that chunk. This would require the chunk to be pinned in some way and the GC to be turned off but it is an option. Also, have you looked much at sun.misc.Unsafe? Or maybe one could use the JNI to write an external memory manager for each platform and all pointer arithmetic is passed through that. Of course, if one goes this far then any "javaD" would need to be able to work well with importing java libraries to be of any use.
Feb 17 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry to come to this thread late, and apologies if I am missing the
real point to this thread.

On Sun, 2013-02-17 at 10:13 +0100, js.mdnq wrote:
 On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright wrote:
 On 2/16/2013 7:26 PM, js.mdnq wrote:
 Would it ever be possible to compile D source directly to java=20
 to take advantage
 of what java offers. (e.g., the ability to run d code inside a=20
 browser)



Running Java in the browser is now unlikely to ever happen again. If anything the target should be JavaScript or Dart, and even Dart would be a huge risk.
 I'm not talking about necessarily fully fledged=20
 functionality(obviously stuff
 like asm isn't going to work) but basically the ability to use=20
 D's syntax and
 some of it's compiler features(mixins, templates, etc).



A lot of work is going into creating Python executability in browsers. Skulpt, Brython, etc., but traction is minimal. Browsers mean HTML5 and ECMAScript (aka JavaScript)
 Java doesn't have pointers, so right off the bat there'd be big=20
 problems.

Java does have pointers... you just can't get to them easily. At=20 the very least, you could allocate and manage your own chunk of=20 memory and do all the pointer arithmetic yourself on that chunk.=20 This would require the chunk to be pinned in some way and the GC=20 to be turned off but it is an option.

There is the possibility of using NIO2 buffers in ways that were never envisaged. This is effectively what happened in RTSJ, which was a real-time systems framework using Java and JVM. RTSJ sadly was too far ahead of its time and so died. The last vestige will die when the Mars Rover does.
 Also, have you looked much at sun.misc.Unsafe?

You really don't want to go there ;-) Obviously for garbage collection and concurrency and parallelism control you have to go there so as to subvert the JVM object model. The question is that unless you are working on the G1 garbage collector or java.util.concurrent primitives, is there any point?
 Or maybe one could use the JNI to write an external memory=20
 manager for each platform and all pointer arithmetic is passed=20
 through that. Of course, if one goes this far then any "javaD"=20
 would need to be able to work well with importing java libraries=20
 to be of any use.

Sounds like a mountain rather than a molehill. We are looking at something vaguely analogous to get CUDA and OpenCL working from GPars/Groovy/Java. Good for users, very ugly for implementors. Unless there is a mapping of the semantics of a language to the intermediate code of the platform, then it is better not to bash head on wall but to go put energies into something more productive. If the D semantics cannot be mapped down to the JVM bytecodes, then D is not a language you want to run on the JVM. Given Java/Scala/Kotlin/Ceylon/Groovy as the static languages and Groovy/JRuby/Jython/Closure as the dynamic languages (yes Groovy is correctly in both categories!) is there really a market for a minor player native code language trying to ease itself onto the JVM platform? The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D only really has a play in one of these, and needs to get real traction there first before looking for new lands to conquer. Else it risks being seen as a solution looking for a problem to solve. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 17 2013
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Sunday, 17 February 2013 at 03:26:13 UTC, js.mdnq wrote:
 Would it ever be possible to compile D source directly to java 
 to take advantage of what java offers. (e.g., the ability to 
 run d code inside a browser)

 I'm not talking about necessarily fully fledged 
 functionality(obviously stuff like asm isn't going to work) but 
 basically the ability to use D's syntax and some of it's 
 compiler features(mixins, templates, etc).

depends on what you mean with "run inside a browser", I would use NaCl instead, if I wanted to run D in a browser, but of course it requires Chrome. http://code.google.com/p/nativeclient/
Feb 17 2013
prev sibling next sibling parent "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Sunday, 17 February 2013 at 09:47:08 UTC, Russel Winder wrote:
 Sorry to come to this thread late, and apologies if I am 
 missing the
 real point to this thread.

 On Sun, 2013-02-17 at 10:13 +0100, js.mdnq wrote:
 On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright 
 wrote:
 On 2/16/2013 7:26 PM, js.mdnq wrote:
 Would it ever be possible to compile D source directly to 
 java to take advantage
 of what java offers. (e.g., the ability to run d code 
 inside a browser)



Running Java in the browser is now unlikely to ever happen again. If anything the target should be JavaScript or Dart, and even Dart would be a huge risk.
 I'm not talking about necessarily fully fledged 
 functionality(obviously stuff
 like asm isn't going to work) but basically the ability to 
 use D's syntax and
 some of it's compiler features(mixins, templates, etc).



A lot of work is going into creating Python executability in browsers. Skulpt, Brython, etc., but traction is minimal. Browsers mean HTML5 and ECMAScript (aka JavaScript)
 Java doesn't have pointers, so right off the bat there'd be 
 big problems.

Java does have pointers... you just can't get to them easily. At the very least, you could allocate and manage your own chunk of memory and do all the pointer arithmetic yourself on that chunk. This would require the chunk to be pinned in some way and the GC to be turned off but it is an option.

There is the possibility of using NIO2 buffers in ways that were never envisaged. This is effectively what happened in RTSJ, which was a real-time systems framework using Java and JVM. RTSJ sadly was too far ahead of its time and so died. The last vestige will die when the Mars Rover does.
 Also, have you looked much at sun.misc.Unsafe?

You really don't want to go there ;-) Obviously for garbage collection and concurrency and parallelism control you have to go there so as to subvert the JVM object model. The question is that unless you are working on the G1 garbage collector or java.util.concurrent primitives, is there any point?
 Or maybe one could use the JNI to write an external memory 
 manager for each platform and all pointer arithmetic is passed 
 through that. Of course, if one goes this far then any "javaD" 
 would need to be able to work well with importing java 
 libraries to be of any use.

Sounds like a mountain rather than a molehill. We are looking at something vaguely analogous to get CUDA and OpenCL working from GPars/Groovy/Java. Good for users, very ugly for implementors. Unless there is a mapping of the semantics of a language to the intermediate code of the platform, then it is better not to bash head on wall but to go put energies into something more productive. If the D semantics cannot be mapped down to the JVM bytecodes, then D is not a language you want to run on the JVM. Given Java/Scala/Kotlin/Ceylon/Groovy as the static languages and Groovy/JRuby/Jython/Closure as the dynamic languages (yes Groovy is correctly in both categories!) is there really a market for a minor player native code language trying to ease itself onto the JVM platform? The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D only really has a play in one of these, and needs to get real traction there first before looking for new lands to conquer. Else it risks being seen as a solution looking for a problem to solve.

Everything started out as minor and if D's language features are truly good and D is as well designed as some think then people will migrate to it. Essentially "If you build it they will come" type of scenario. Those that would use a D for java type of language can't so there is no way to measure how successful it would be. Virtual machine programming has many benefits but we definitely do not need another one. Hence, it would be nice to leverage java, which already has build up it's user base to further the D language paradigm. I like D but so far it doesn't seem to be going anywhere. Why? Because one already has all these other languages and tools to do the job. Imagine this: Suppose with a snap of your fingers you could have the following products: High stable and performant D compiler for all the major platforms(including many embedded) with a large collection of support tools. A D virtual machine that runs on many platforms. A D for java compiler that compiles almost any D program into java bytecode and use java libraries. etc... Now, if you had all this stuff magically out there do you think that the userbase for D would explode? I do... In fact, it would happen for most decent languages. (of course, we could argue about the exact details but D would become a major player within a few years) Hence, having this stuff is important for D's success. Of course, it may not be possible in some cases or sacrifices have to be made. In any case I'm not convinced that a D for java can't be implemented and I do feel it would further D's popularity. Of course, D is still in it's infancy but it would be cool it someone was interested in trying to make a D for java and see where it goes. I think something useful would come out of it. (Please don't say I should do it either...)
Feb 17 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-18 at 03:37 +0100, js.mdnq wrote:
[=E2=80=A6]
 Everything started out as minor and if D's language features are=20
 truly good and D is as well designed as some think then people=20
 will migrate to it. Essentially "If you build it they will come"=20
 type of scenario.

D is out there, but not widely enough known, people are sticking with C and C++ or heading to Go. And then there is Rust.
 Those that would use a D for java type of language can't so there=20
 is no way to measure how successful it would be.

Very true. You can only get a feel for a reaction when the capability is there. However look at the JVM-based milieu. Despite Groovy, Clojure, Ceylon, Kotlin, JRuby, Jython, Scala, the vast majority of organizations are Java fixated. Worse they are worrying about migration from Java 5 or 6 or 7, some even from Java 1.4. It is all to easy to forget from the excitement of the bleeding edge how far behind most of the world is.
 Virtual machine programming has many benefits but we definitely=20
 do not need another one. Hence, it would be nice to leverage=20
 java, which already has build up it's user base to further the D=20
 language paradigm. I like D but so far it doesn't seem to be=20
 going anywhere. Why? Because one already has all these other=20
 languages and tools to do the job.

I cannot see C, C++, D, Go, Rust, etc. ever working on the JVM enough to compete with Java, Scala, Groovy, Ceylon, Kotlin which are designed for the JVM. Creating a backend for D to sit on the JVM would be an interesting academic project that might eventually lead to a product, more likely it would make a great PhD. D's lack of traction is mostly to do with it not making headway against C and C++ in the C and C++ communities. Go is pitched against C, C++ and Python and is beginning to make headway. It has two features that allow this: use of CSP ( at least Rob Pike's variant developed in parallel) for concurrency and parallelism, and the support of Google. D has actors and data parallelism and a huge void for the number of big companies standing up saying they are happily using D. A couple of international banks have ditched large centralized Java mindset for a combination of small Scala install for centralized and Python out in the business units. This has been a huge fillip to both Scala and Python. Not least that I am currently making most of my living from Python training for these organizations. Who are the organizations using D as their strategic programming language? Who are the companies offering D training? Where is the plethora of books on the D language? Getting high scores for posts on StackOverflow and Reddit actually mean very little. A good rating on TIOBE matters more than it should. Having training companies with stock training courses and big, high profile users, is what really matters.
 Imagine this:
=20
 Suppose with a snap of your fingers you could have the following=20
 products:
=20
 High stable and performant D compiler for all the major=20
 platforms(including many embedded) with a large collection of=20
 support tools.
=20
 A D virtual machine that runs on many platforms. A D for java=20
 compiler that compiles almost any D program into java bytecode=20
 and use java libraries.
=20
 etc...
=20
 Now, if you had all this stuff magically out there do you think=20
 that the userbase for D would explode? I do... In fact, it would=20
 happen for most decent languages. (of course, we could argue=20
 about the exact details but D would become a major player within=20
 a few years)
=20
 Hence, having this stuff is important for D's success. Of course,=20
 it may not be possible in some cases or sacrifices have to be=20
 made. In any case I'm not convinced that a D for java can't be=20
 implemented and I do feel it would further D's popularity.

Mapping D to Java and then using a Java compiler is feasible but a huge undertaking, more than trying to compile D to JVM bytecodes. But as soon as anyone mentions JNI as an integral part of a language's implementation, they are on to a loser. JNI needs to be treated with a distributed systems mindset, not a code execution one.
 Of course, D is still in it's infancy but it would be cool it=20
 someone was interested in trying to make a D for java and see=20
 where it goes. I think something useful would come out of it.=20
 (Please don't say I should do it either...)

D is not in it's infancy, it is 10 years old and in language terms should be mature and entering mainstream use. Java and C are weird special cases, but C++, Groovy, Python, JRuby, most other languages take 5 years to develop, 5 years to settle and if they are not major players by then will disappear. Of course most language don't get that far. D is superior to C++ in almost every way except that it has no traction. I am thinking that C++ is no longer the thing that D is able to compete with, just let that community be. C is also shrinking as people realize it is a niche language for operating systems and runtime systems. The action is native vs. JVM vs. PVM. The native+PVM has massive traction in computational arenas. JVM remains the major player other than .NET in almost all Internet life. Go is having a good go (!) at challenging this on behalf of native. Marketingwise D is at a crossroads: continue to see itself as a C++ beater, or a native language for the Internet world. This is about mindset and attitude of people here in this mailing list and the way they present D to the world. vibe.d could be the making of D if pushed appropriately. But it needs a client as well as server activity. GtkD, QtD, wxD, OSXD, WindowsD, i.e. connection into the standard graphics systems, are needed. SQLD, MongoDBD, NeoD, are needed. The effort should be on embedding D in a flexible context. Go has motored a long way down this road already and is beginning to get mind share as the native code system for the Internet. It has a huge distance to travel to challenge Java and ASP.NET, but it is way ahead of D. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 17 2013
prev sibling next sibling parent "rumbu" <rumbu rumbu.ro> writes:
On Tuesday, 19 February 2013 at 21:30:53 UTC, Paulo Pinto wrote:
 Am 17.02.2013 21:47, schrieb Walter Bright:
 On 2/17/2013 1:46 AM, Russel Winder wrote:
 The world is split into native code, PVM, JVM, 
 JavaScript/ECMAScript. D
 only really has a play in one of these, and needs to get real 
 traction
 there first before looking for new lands to conquer. Else it 
 risks being
 seen as a solution looking for a problem to solve.

I agree. There was at one time a D implementation on .net, but it suffered from .net's lack of support for pointers, which meant that slices performed poorly.

So how are C++ and C# pointers done in IL ?

There are two kind of pointers in C#: managed and unmanaged. Wrapped in a fixed statement (just to tell the garbage collector to keep fixed references), C# pointers will behave like any native language pointer. This is not the first topic where I read that misconception that slices are a problem for IL. From .net 2.0 (9 years ago) there is the ArraySegment<T> type doing exactly what D slices do. Also, in C# arrays are implicitely convertible to pointers. Anyway, I don't see any use for a D IL compiler, since probably the language syntax will look 90% like C#.
Feb 19 2013
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 So how are C++ and C# pointers done in IL ?

There are two kind of pointers in C#: managed and unmanaged. Wrapped in a fixed statement (just to tell the garbage collector to keep fixed references), C# pointers will behave like any native language pointer. This is not the first topic where I read that misconception that slices are a problem for IL. From .net 2.0 (9 years ago) there is the ArraySegment<T> type doing exactly what D slices do. Also, in C# arrays are implicitely convertible to pointers.

IIRC, the biggest incompatibility between D and .NET is that D pointers can point to the stack, to unmanaged (non-GC) memory or to managed (GC) memory, while simultaneously having unlimited lifetime. In .NET, arguments that are passed by reference can point to GC or non-GC memory, but pointers inside objects (classes or boxed structs) can only point to (1) non-GC non-stack memory OR (2) the beginning of a GC object. The key problem: a single pointer cannot be used for both purposes! D pointers and ranges can point to stack, GC or non-GC memory, regardless of the location of the pointer or range itself. Also, D pointers can point to the interior of an object and not just the beginning, while .NET pointers, in general, cannot. This doesn't make a D implementation for .NET impossible, but if you want to run arbitrary D code on .NET, I think it would have to run inefficiently because it would constantly have to work around limitations of .NET. I think doing D in .NET efficiently would require a specialized version of D, or something. Note that plain old C++ can be used in .NET because C++ pointers can't point to GC memory without special .NET-specific types. Thus, old-fashioned C++ avoids problems related to the .NET garbage collector.
 Anyway, I don't see any use for a D IL compiler, since probably 
 the language syntax will look 90% like C#.

How is "looking" like C# relevant? D looks 90% like C++ too, and D is still better. Certainly D is more powerful than C# on the whole.
Feb 19 2013
prev sibling next sibling parent "rumbu" <rumbu rumbu.ro> writes:
On Wednesday, 20 February 2013 at 00:15:00 UTC, David Piepgrass 
wrote:

 How is "looking" like C# relevant? D looks 90% like C++ too, 
 and D is still better. Certainly D is more powerful than C# on 
 the whole.

This is not a debate C# vs D. D is clearly more powerful than C# with the current language semantics. But, once D will be adapted to generate IL code, most of advantages will be lost. You cannot have assembler code (may be IL code, but this can be achieved using Emit in C# also), compile time reflection will become redundant because of the intrinsic runtime reflection, most of the templates will be constrained to generic types. In a pottential D#, Phobos will not be used since you have the .net framework. Also because of lack of some D features (like readonly, mutiple interface implementation of the same method, namespaces), more keywords will be needed to describe the code and that will make it similar to C# more than expected. The irony is the fact that digging in the forum history, you will find how D has evolved to be more and more C# like. Just look at the recent changes, "alias" has evolved to the exact syntax of "using" from C#. If the initial audience of D was the C++ programmer, I think it's time to make a step forward and look also to lure the C# programmer since the syntax is very similar. The most important argument for the C# programmer to use D is the fact that D compiles to native code. Offering something like D# to the C# programmer is out of his interest, imho.
Feb 20 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 20 February 2013 at 08:38:00 UTC, rumbu wrote:
 On Wednesday, 20 February 2013 at 00:15:00 UTC, David Piepgrass 
 wrote:

 How is "looking" like C# relevant? D looks 90% like C++ too, 
 and D is still better. Certainly D is more powerful than C# on 
 the whole.

This is not a debate C# vs D. D is clearly more powerful than C# with the current language semantics. But, once D will be adapted to generate IL code, most of advantages will be lost. You cannot have assembler code (may be IL code, but this can be achieved using Emit in C# also), compile time reflection will become redundant because of the intrinsic runtime reflection, most of the templates will be constrained to generic types. In a pottential D#, Phobos will not be used since you have the .net framework. Also because of lack of some D features (like readonly, mutiple interface implementation of the same method, namespaces), more keywords will be needed to describe the code and that will make it similar to C# more than expected. The irony is the fact that digging in the forum history, you will find how D has evolved to be more and more C# like. Just look at the recent changes, "alias" has evolved to the exact syntax of "using" from C#. If the initial audience of D was the C++ programmer, I think it's time to make a step forward and look also to lure the C# programmer since the syntax is very similar. The most important argument for the C# programmer to use D is the fact that D compiles to native code. Offering something like D# to the C# programmer is out of his interest, imho.

A problem here is that Microsoft is probably in the process of also offering standalone compilation for .NET languages as well. Windows Phone 8 .NET applications get compiled to native code, they are not JITted. They might as well decide to use the same solution instead of NGEN on the desktop. -- Paulo
Feb 20 2013