www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Microsoft now giving away VS 2013

reply Walter Bright <newshound2 digitalmars.com> writes:
http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

This is good news for D! It lowers the bar for writing 64 bit D code on
Windows, 
and it also enables us to abandon support for versions of VS prior to 2013.
Nov 12 2014
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:
 This is good news for D! It lowers the bar for writing 64 bit D 
 code on Windows, and it also enables us to abandon support for 
 versions of VS prior to 2013.
Does it? Weren't the relevant parts available as part of VS Express and/or the Windows SDK? (Dreamspark Premium makes you rather oblivious in that regard.) In any case, this is good news for Windows development indeed. David
Nov 12 2014
prev sibling next sibling parent reply "ZombineDev" <valid_email he.re> writes:
Probably more important:

Microsoft starts to open source .NET and take it cross-platform 
to Mac, Linux:

http://venturebeat.com/2014/11/12/microsoft-starts-to-open-source-net-and-take-it-cross-platform-to-mac-linux/

https://github.com/Microsoft/dotnet

License

.NET open source projects typically use either the MIT or Apache 
2 licenses for code. Some projects license documentation and 
other forms of content under Creative Commons Attribution 4.0. 
See specific projects to understand the license used.
Nov 12 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 01:45:31 UTC, ZombineDev wrote:
 Probably more important:

 Microsoft starts to open source .NET and take it cross-platform 
 to Mac, Linux:

 http://venturebeat.com/2014/11/12/microsoft-starts-to-open-source-net-and-take-it-cross-platform-to-mac-linux/

 https://github.com/Microsoft/dotnet

 License

 .NET open source projects typically use either the MIT or 
 Apache 2 licenses for code. Some projects license documentation 
 and other forms of content under Creative Commons Attribution 
 4.0. See specific projects to understand the license used.
Yeah, I thought that was cool. The JIT, GC and core library. https://github.com/dotnet/corefx So, how to write a source-to-source compiler from CS to D…? ;-)
Nov 13 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
Grøstad wrote:
 So, how to write a source-to-source compiler from CS to D…? ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone. Or rather, it would be if anyone actually used WP. (Going after Microsoft's also-ran mobile OS isn't particularly compelling when our story for targeting Android is still in such a dire state.) -Wyatt
Nov 13 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Wyatt:

 So, how to write a source-to-source compiler from CS to D…? ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone.
Perhaps it's better to make LDC2-LLVM output the intermediate code of the dotnet :-) Bye, bearophile
Nov 13 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 November 2014 at 13:59:32 UTC, Wyatt wrote:
 On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
 Grøstad wrote:
 So, how to write a source-to-source compiler from CS to D…? ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone. Or rather, it would be if anyone actually used WP. (Going after Microsoft's also-ran mobile OS isn't particularly compelling when our story for targeting Android is still in such a dire state.) -Wyatt
In Germany I get to see Lumias all the time in trains and in the southern countries there are more people with Lumias than iPhones. -- Paulo
Nov 13 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 13 November 2014 at 14:17:43 UTC, Paulo  Pinto wrote:
 In Germany I get to see Lumias all the time in trains and in 
 the southern countries there are more people with Lumias than 
 iPhones.
Oh? Interesting; I'm honestly a bit surprised. (I see more Blackberry kit than WP in the US.) Any observations relative to the prevalence of Android handsets? -Wyatt
Nov 13 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/13/2014 10:38 AM, Wyatt wrote:
 Oh?  Interesting; I'm honestly a bit surprised. (I see more Blackberry
 kit than WP in the US.)
I've never seen a blackberry in the US. Although I've only ever seen one person with a windows phone, and that person switched to android soon after.
Nov 13 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 November 2014 at 15:38:07 UTC, Wyatt wrote:
 On Thursday, 13 November 2014 at 14:17:43 UTC, Paulo  Pinto 
 wrote:
 In Germany I get to see Lumias all the time in trains and in 
 the southern countries there are more people with Lumias than 
 iPhones.
Oh? Interesting; I'm honestly a bit surprised. (I see more Blackberry kit than WP in the US.) Any observations relative to the prevalence of Android handsets? -Wyatt
Android is the PC of the mobile world in Europe. The majority of Europeans uses pre-paid SIM cards and you don't want to buy an iOS device with pre-paid prices.... -- Paulo
Nov 14 2014
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 13 November 2014 at 13:59:32 UTC, Wyatt wrote:
 On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
 Grøstad wrote:
 So, how to write a source-to-source compiler from CS to D…? ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone. Or rather, it would be if anyone actually used WP. (Going after Microsoft's also-ran mobile OS isn't particularly compelling when our story for targeting Android is still in such a dire state.)
Dire state? All druntime/phobos tests pass on Android/x86, except for std.datetime: http://wiki.dlang.org/Build_DMD_for_Android OK, that's not ARM that everybody cares about, but that just means combining an ARM backend from ldc or gdc and the existing linux/ARM and Android support in druntime/phobos, then hacking around the lack of native TLS on Android. gdc supposedly supports emulated TLS, so all the pieces should be in place there to do it. I've been recently looking into hacking the packed TLS solution I used with dmd for Android/x86 into ldc and llvm. Dan Olson got pretty far with iOS support too, early this year: http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net D has some support for mobile, albeit not fully polished.
Nov 13 2014
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 November 2014 06:21, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 13 November 2014 at 13:59:32 UTC, Wyatt wrote:
 On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim Grøstad wrote:
 So, how to write a source-to-source compiler from CS to D…? ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone. Or rather, it would be if anyone actually used WP. (Going after Microsoft's also-ran mobile OS isn't particularly compelling when our story for targeting Android is still in such a dire state.)
Dire state? All druntime/phobos tests pass on Android/x86, except for std.datetime: http://wiki.dlang.org/Build_DMD_for_Android OK, that's not ARM that everybody cares about, but that just means combining an ARM backend from ldc or gdc and the existing linux/ARM and Android support in druntime/phobos, then hacking around the lack of native TLS on Android. gdc supposedly supports emulated TLS, so all the pieces should be
Just missing a piece of runtime that ties emuTLS with the D GC. Currently there's a deadlock situation between the GC allocating new memory, and the emuTLS layer adding a new root for the GC to scan. Should be trivial to make it work, but I haven't yet got back to investing time in it. Iain.
Nov 14 2014
prev sibling parent reply "Chad Joan" <chadjoan gmail.com> writes:
On Friday, 14 November 2014 at 06:21:45 UTC, Joakim wrote:
 On Thursday, 13 November 2014 at 13:59:32 UTC, Wyatt wrote:
 On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
 Grøstad wrote:
 So, how to write a source-to-source compiler from CS to D…? 
 ;-)
I think it would be more useful would be to go the other way around for targeting Windows Phone. Or rather, it would be if anyone actually used WP. (Going after Microsoft's also-ran mobile OS isn't particularly compelling when our story for targeting Android is still in such a dire state.)
Dire state? All druntime/phobos tests pass on Android/x86, except for std.datetime: http://wiki.dlang.org/Build_DMD_for_Android OK, that's not ARM that everybody cares about, but that just means combining an ARM backend from ldc or gdc and the existing linux/ARM and Android support in druntime/phobos, then hacking around the lack of native TLS on Android. gdc supposedly supports emulated TLS, so all the pieces should be in place there to do it. I've been recently looking into hacking the packed TLS solution I used with dmd for Android/x86 into ldc and llvm. Dan Olson got pretty far with iOS support too, early this year: http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net D has some support for mobile, albeit not fully polished.
We really should have had a toolchain compiling D into working (release quality) Android/iOS executables about 3-5 years ago. This would have allowed D to scoop up a HUGE share of deployment in a market that was very new and welcoming of experimentation. It seems like there have been a few people enthusiastically working on this, but with little support from the broader community. I really wish this were a higher development priority and more actively encouraged a long time ago.
Nov 14 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 14 November 2014 at 14:20:00 UTC, Chad Joan wrote:
 We really should have had a toolchain compiling D into working 
 (release quality) Android/iOS executables about 3-5 years ago.
I agree. Well, to a large extent: the first Android smartphone was only released 6 years ago, would've been a bit early to jump in the year after. I picked it up last year because nobody was working on it, after years of people asking.
 This would have allowed D to scoop up a HUGE share of 
 deployment in a market that was very new and welcoming of 
 experimentation.
I don't know, I think D really has a chance to do well on mobile, but have other alternative languages, ie not C/C++/java, done _that_ well on Android? I know the Rust guys are now working on it, but while languages like FreePascal are on there, I have not heard of any big success story.
 It seems like there have been a few people enthusiastically 
 working on this, but with little support from the broader 
 community.  I really wish this were a higher development 
 priority and more actively encouraged a long time ago.
I have been a bit surprised by this. It definitely seems many are x86/desktop/server-centric and seemingly ignoring the great opportunity for native languages and furious growth in mobile.
Nov 14 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 14 November 2014 at 18:35:56 UTC, Joakim wrote:
 On Friday, 14 November 2014 at 14:20:00 UTC, Chad Joan wrote:
 We really should have had a toolchain compiling D into working 
 (release quality) Android/iOS executables about 3-5 years ago.
I agree. Well, to a large extent: the first Android smartphone was only released 6 years ago, would've been a bit early to jump in the year after. I picked it up last year because nobody was working on it, after years of people asking.
 This would have allowed D to scoop up a HUGE share of 
 deployment in a market that was very new and welcoming of 
 experimentation.
I don't know, I think D really has a chance to do well on mobile, but have other alternative languages, ie not C/C++/java, done _that_ well on Android? I know the Rust guys are now working on it, but while languages like FreePascal are on there, I have not heard of any big success story. ...
Native development in Android is a world of pain, given Android's team stance on the NDK and poor tooling support. You just have a tiny subset of APIs, the ones important for game development, i.e. OpenGL, in memory framebuffers, sound, hardware sensors and partial POSIX. For everything else either you go JNI or have to bring third party dependencies that increase the apk size. It is ridiculous to the point there isn't access to the SQLLite, SKIA and other C and C++ libraries from Android. One is forced to integrate an own version. Or Android Studio that still doesn't have a public roadmap about C and C++ support parity to Eclipse ADT/CDT. So NDK is only worthwhile for gaming or business code with the UI written in Java. Xamarin and Phonegap are the only success stories in the traditional app market. One has teams of developers creating platform wrappers and the other just uses the browser via the web view, thus easier platform integration. I was playing around with Qt and gave up, as only the upcoming 5.4 will have UI controls with support for Android. -- Paulo
Nov 14 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 14 November 2014 at 19:51:02 UTC, Paulo Pinto wrote:
 On Friday, 14 November 2014 at 18:35:56 UTC, Joakim wrote:
 I don't know, I think D really has a chance to do well on 
 mobile, but have other alternative languages, ie not 
 C/C++/java, done _that_ well on Android?  I know the Rust guys 
 are now working on it, but while languages like FreePascal are 
 on there, I have not heard of any big success story.
...
Native development in Android is a world of pain, given Android's team stance on the NDK and poor tooling support. You just have a tiny subset of APIs, the ones important for game development, i.e. OpenGL, in memory framebuffers, sound, hardware sensors and partial POSIX. For everything else either you go JNI or have to bring third party dependencies that increase the apk size. It is ridiculous to the point there isn't access to the SQLLite, SKIA and other C and C++ libraries from Android. One is forced to integrate an own version. Or Android Studio that still doesn't have a public roadmap about C and C++ support parity to Eclipse ADT/CDT. So NDK is only worthwhile for gaming or business code with the UI written in Java. Xamarin and Phonegap are the only success stories in the traditional app market. One has teams of developers creating platform wrappers and the other just uses the browser via the web view, thus easier platform integration. I was playing around with Qt and gave up, as only the upcoming 5.4 will have UI controls with support for Android.
If you're not going to use the platform language, whether Java or Obj-C, you have to expect some hurdles, especially if you're going to try to shoehorn in a new language. D will have to work into those app niches you mentioned first, but as stuff like Qt becomes more viable on Android, official platform support may not matter as much.
Nov 14 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 14 November 2014 at 22:35:30 UTC, Joakim wrote:
 On Friday, 14 November 2014 at 19:51:02 UTC, Paulo Pinto wrote:
 On Friday, 14 November 2014 at 18:35:56 UTC, Joakim wrote:
 I don't know, I think D really has a chance to do well on 
 mobile, but have other alternative languages, ie not 
 C/C++/java, done _that_ well on Android?  I know the Rust 
 guys are now working on it, but while languages like 
 FreePascal are on there, I have not heard of any big success 
 story.
...
Native development in Android is a world of pain, given Android's team stance on the NDK and poor tooling support. You just have a tiny subset of APIs, the ones important for game development, i.e. OpenGL, in memory framebuffers, sound, hardware sensors and partial POSIX. For everything else either you go JNI or have to bring third party dependencies that increase the apk size. It is ridiculous to the point there isn't access to the SQLLite, SKIA and other C and C++ libraries from Android. One is forced to integrate an own version. Or Android Studio that still doesn't have a public roadmap about C and C++ support parity to Eclipse ADT/CDT. So NDK is only worthwhile for gaming or business code with the UI written in Java. Xamarin and Phonegap are the only success stories in the traditional app market. One has teams of developers creating platform wrappers and the other just uses the browser via the web view, thus easier platform integration. I was playing around with Qt and gave up, as only the upcoming 5.4 will have UI controls with support for Android.
If you're not going to use the platform language, whether Java or Obj-C, you have to expect some hurdles, especially if you're going to try to shoehorn in a new language. D will have to work into those app niches you mentioned first, but as stuff like Qt becomes more viable on Android, official platform support may not matter as much.
Agreed, but Android makes those hurdles worse because the team doesn't believe in providing proper access to the NDK, whereas Objective-C++ and C++/CX exist to ease the life of C++ developers in iOS and WP, instead of JNI pain. -- Paulo
Nov 14 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-13 09:50, "Ola Fosheim Grøstad"
 So, how to write a source-to-source compiler from CS to D…? ;-)
that uses the compiler, visits the AST and generates D code from it. Bonus: Run the tool on the .Net compiler and on the tool itself. Then we'll -- /Jacob Carlborg
Nov 14 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 14 November 2014 at 08:05:49 UTC, Jacob Carlborg wrote:


 generates D code from it.
Sounds like an interesting project. Maybe someone else will create a generic source-to-source compiler kit for various languages.
 Run the tool on the .Net compiler and on the tool itself. Then 

 written in D :D
This somehow reminds me of "Gnu's not unix".
Nov 14 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
Grøstad wrote:
 Yeah, I thought that was cool. The JIT, GC  and core library.

 https://github.com/dotnet/corefx

 So, how to write a source-to-source compiler from CS to D…? ;-)
Why would you do it? One nice feature of .net from day one was that you can write code in any language, they interoperate on byte code level.
Nov 14 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 14 November 2014 at 15:32:45 UTC, Kagamin wrote:
 Why would you do it? One nice feature of .net from day one was 
 that you can write code in any language, they interoperate on 
 byte code level.
I have no need for it at the moment, but please note that some web services only provide .net clients. So being able to convert those client libraries to other languages open up new integration possibilities.
Nov 14 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 14 November 2014 at 16:28:21 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 14 November 2014 at 15:32:45 UTC, Kagamin wrote:
 Why would you do it? One nice feature of .net from day one was 
 that you can write code in any language, they interoperate on 
 byte code level.
I have no need for it at the moment, but please note that some web services only provide .net clients. So being able to convert those client libraries to other languages open up new integration possibilities.
The proper way is for the other languages to provide a compiler that generates MSIL. Plus, it is quite easy to expose .NET objects as COM, so any language able to consume COM should be able to talk to .NET. -- Paulo
Nov 14 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 13 November 2014 at 01:45:31 UTC, ZombineDev wrote:
 http://venturebeat.com/2014/11/12/microsoft-starts-to-open-source-net-and-take-it-cross-platform-to-mac-linux/

 .NET open source projects typically use either the MIT or 
 Apache 2 licenses for code. Some projects license documentation 
 and other forms of content under Creative Commons Attribution 
 4.0. See specific projects to understand the license used.
It can sound more optimistic, than it is. Framework is big, and what will be opensourced is unknown. As of now, it's only immutable collections and XmlDocument. ASP.NET vNext stuff looks like a limited rewrite than a published source.
Nov 13 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:
 http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

 This is good news for D! It lowers the bar for writing 64 bit D 
 code on Windows, and it also enables us to abandon support for 
 versions of VS prior to 2013.
Actually I think it makes the life harder to earn Windows developers hearts for D, specially with .NET Native around the corner (it will come in Windows 10). enticing proposal. I would have a very hard time to convince any of our customers to use D instead. -- Paulo
Nov 13 2014
next sibling parent reply "MachineCode" <netorib94 gmail.com> writes:
On Thursday, 13 November 2014 at 09:36:20 UTC, Paulo  Pinto wrote:
 On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
 wrote:
 http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

 This is good news for D! It lowers the bar for writing 64 bit 
 D code on Windows, and it also enables us to abandon support 
 for versions of VS prior to 2013.
Actually I think it makes the life harder to earn Windows developers hearts for D, specially with .NET Native around the corner (it will come in Windows 10). enticing proposal. I would have a very hard time to convince any of our customers to use D instead. -- Paulo
Exactly my thoughts... also syntax sugar, compiled language was source language (so the guys from UNIXes around can move to it) and native language, the C++ guys are going to move from C++ to good for D community. And yeah I know there's Mono and it's open source from day 1. But it's the MS implementation.
Nov 13 2014
parent reply "ZombineDev" <valid_email he.re> writes:

professionally for about 2 years and in my opinion it invites 
writing over-architected OOP with little regard about efficiency. 
My experience is based on working in the code-base of my old job, 
reading forums, books and so on.

Just look at these "beautiful" pieces of art:

http://referencesource.microsoft.com/#PresentationFramework/Framework/System/Windows/Controls/DataGrid.cs
^ just try to find were the performance bottleneck is and 
refactor it :D

And some other elegant pieces:
https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Register.cs

https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Vector.cs

^ Without templates and CTFE the power to weight ratio is pretty 
low.

Of course there are exceptions to the rule. Here is a somewhat 
large, performance oriented project. This an open-source 
implementation of the classic C&C RTS games:
https://github.com/OpenRA/OpenRA

I really don't want to go back to .NET. It's not about that 
Microsoft is evil, anti-FOSS or anything like that.
I just really like the way D allows me to express my intent and 
how flexible it is. It is the overall feeling I get from the 
community that people want to use D to write elegant, yet highly 
optimal code. And when there is a problem preventing this (like 
for some people the GC) a great effort is made to improve the 
situation (e.g. http://wiki.dlang.org/DIPs, etc. )

My impression is that the average .net developer is scared by the 
"low-level stuff" and wants these stuff to be magically taken 
care of. I haven't seen anyone that wants to get rid of the GC 
and even fewer are trying to be proactive and to find a solution 
(like  nogc, RC strings or exceptions in Dland).


politics. Like when the development of Silverlight  platform was 
canceled. It was a huge blow to the .NET community and there was 
no solution (even third-party) so everyone just the left the 
sinking ship.
Nov 13 2014
next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 13 November 2014 at 23:29:42 UTC, ZombineDev wrote:

 professionally for about 2 years and in my opinion it invites 
 writing over-architected OOP with little regard about 
 efficiency.
In my experience, that's how experienced architects work. This too. How would you estimate std.datetime?
 It is the overall feeling I get from the community that people 
 want to use D to write elegant, yet highly optimal code.
If you don't see software development as art and want it to be effective, the code needs to be maintainable, extensible, testable, fast. And it should be written int the first place. Elegance is not in the list.
 My impression is that the average .net developer is scared by 
 the "low-level stuff" and wants these stuff to be magically 
 taken care of. I haven't seen anyone that wants to get rid of 
 the GC and even fewer are trying to be proactive and to find a 
 solution (like  nogc, RC strings or exceptions in Dland).
Performance and memory consumption is a problem in .net too, if you write anything but a "hello world". You can't say "16Gb RAM is quite enough, thank you" or "User can wait 30min for this operation to complete just fine".

 Microsoft's politics. Like when the development of Silverlight  
 platform was canceled. It was a huge blow to the .NET community 
 and there was no solution (even third-party) so everyone just 
 the left the sinking ship.
Wasn't obvious Silverlight was born dead?
Nov 14 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 November 2014 at 23:29:42 UTC, ZombineDev wrote:

 professionally for about 2 years and in my opinion it invites 
 writing over-architected OOP with little regard about 
 efficiency. My experience is based on working in the code-base 
 of my old job, reading forums, books and so on.

 Just look at these "beautiful" pieces of art:

 http://referencesource.microsoft.com/#PresentationFramework/Framework/System/Windows/Controls/DataGrid.cs
 ^ just try to find were the performance bottleneck is and 
 refactor it :D
I have an application fetching thousands of rows from an Oracle database and displaying it under a few ms. It is fast enough. If I really need to find a performance bottleneck there lots of visual profiling tools available.
 And some other elegant pieces:
 https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Register.cs

 https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Vector.cs

 ^ Without templates and CTFE the power to weight ratio is 
 pretty low.
Reflection, dynamic and attributes are also quite powerful meta-programming capabilities. As far as I can tell, D code still doesn't explore UDA that much.
 Of course there are exceptions to the rule. Here is a somewhat 
 large, performance oriented project. This an open-source 
 implementation of the classic C&C RTS games:
 https://github.com/OpenRA/OpenRA

 I really don't want to go back to .NET. It's not about that 
 Microsoft is evil, anti-FOSS or anything like that.
 I just really like the way D allows me to express my intent and 
 how flexible it is. It is the overall feeling I get from the 
 community that people want to use D to write elegant, yet 
 highly optimal code. And when there is a problem preventing 
 this (like for some people the GC) a great effort is made to 
 improve the situation (e.g. http://wiki.dlang.org/DIPs, etc. )

 My impression is that the average .net developer is scared by 
 the "low-level stuff" and wants these stuff to be magically 
 taken care of. I haven't seen anyone that wants to get rid of 
 the GC and even fewer are trying to be proactive and to find a 
 solution (like  nogc, RC strings or exceptions in Dland).
Why should .NET get rid of the GC? It has quite good performance, better than the one D has, and the new one will be even better. Can scale from embedded platforms like Netduino up to Azure scale cloud deployments for games like Age of Ascent or companies of Lufthansa scale. You can use manual memory management in .NET if you really want to, via struts, unsafe, fixed allocations or just direct calling Windows APIs via P/Invoke. What matters is business value from code, not how beautiful it is. This is why, regardless how primitive Go might be, it is being picked up by many companies. It is primitive compared to modern language standards, but companies see business value in it. Even Microsoft has joined the party with Azure support for Docker. Guess in what language the integration is being made?

 Microsoft's politics. Like when the development of Silverlight  
 platform was canceled. It was a huge blow to the .NET community 
 and there was no solution (even third-party) so everyone just 
 the left the sinking ship.
You are always dependent on the politics of whoever develops your tools, regardless of the community or company. Lots of examples both in commercial and open source worlds. The only way around it is if you build your complete stack (OS + language + libraries) yourself. -- Paulo
Nov 14 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Nov-2014 13:48, Paulo Pinto пишет:
 It is primitive compared to modern language standards, but companies see
 business value in it. Even Microsoft has joined the party with Azure
 support for Docker.
Frankly this doesn't have anything to do with Go as in langauge. For instance, just because I use tools written in Perl doesn't mean I endorse Perl. -- Dmitry Olshansky
Nov 14 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 14 November 2014 at 18:30:54 UTC, Dmitry Olshansky 
wrote:
 14-Nov-2014 13:48, Paulo Pinto пишет:
 It is primitive compared to modern language standards, but 
 companies see
 business value in it. Even Microsoft has joined the party with 
 Azure
 support for Docker.
Frankly this doesn't have anything to do with Go as in langauge. For instance, just because I use tools written in Perl doesn't mean I endorse Perl.
Yes you do, this is economy 101. By using tools based on Perl you are creating a market perpection that it is worth creating tools in Perl. So others that do endorse the language, will see their skills being requested to created more tools, which increases the visibility of the language and rises the interest to learn it. -- Paulo
Nov 14 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 14 November 2014 at 19:38:44 UTC, Paulo Pinto wrote:
 On Friday, 14 November 2014 at 18:30:54 UTC, Dmitry Olshansky 
 wrote:
 14-Nov-2014 13:48, Paulo Pinto пишет:
 It is primitive compared to modern language standards, but 
 companies see
 business value in it. Even Microsoft has joined the party 
 with Azure
 support for Docker.
Frankly this doesn't have anything to do with Go as in langauge. For instance, just because I use tools written in Perl doesn't mean I endorse Perl.
Yes you do, this is economy 101. By using tools based on Perl you are creating a market perpection that it is worth creating tools in Perl.
Haha, yes, to quote Google's Go blog: «infrastructure companies like Google, CloudFlare, Canonical, Digital Ocean, GitHub, Heroku, and Microsoft are now using Go to do some heavy lifting» http://blog.golang.org/5years It is fun how they claim Microsoft is using Go to do some heavy lifting… I am sure Microsoft is thrilled with the formulation!
Nov 14 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Nov-2014 23:20, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" пишет:
 On Friday, 14 November 2014 at 19:38:44 UTC, Paulo Pinto wrote:
 On Friday, 14 November 2014 at 18:30:54 UTC, Dmitry Olshansky wrote:
 14-Nov-2014 13:48, Paulo Pinto пишет:
 It is primitive compared to modern language standards, but companies
 see
 business value in it. Even Microsoft has joined the party with Azure
 support for Docker.
Frankly this doesn't have anything to do with Go as in langauge. For instance, just because I use tools written in Perl doesn't mean I endorse Perl.
Yes you do, this is economy 101. By using tools based on Perl you are creating a market perpection that it is worth creating tools in Perl.
Haha, yes, to quote Google's Go blog: «infrastructure companies like Google, CloudFlare, Canonical, Digital Ocean, GitHub, Heroku, and Microsoft are now using Go to do some heavy lifting»
Classics! :) I love these kinds of statements with "heavy lifting" and "great scalability" and "huge amounts of data". And things like e.g. Python web frameworks claiming to be "super fast" at request routing because they compile regular expressions at start-up. How smart... OMG.
 http://blog.golang.org/5years

 It is fun how they claim Microsoft is using Go to do some heavy lifting…
 I am sure Microsoft is thrilled with the formulation!
-- Dmitry Olshansky
Nov 14 2014
parent "Max Samukha" <maxsamukha gmail.com> writes:
On Friday, 14 November 2014 at 20:29:26 UTC, Dmitry Olshansky 
wrote:
 Classics! :)

 I love these kinds of statements with "heavy lifting" and 
 "great scalability" and "huge amounts of data". And things like 
 e.g. Python web frameworks claiming to be "super fast" at 
 request routing because they compile regular expressions at 
 start-up. How smart... OMG.
Simulating brains is just around the corner!
Nov 15 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Nov-2014 22:38, Paulo Pinto пишет:
 On Friday, 14 November 2014 at 18:30:54 UTC, Dmitry Olshansky wrote:
 14-Nov-2014 13:48, Paulo Pinto пишет:
 It is primitive compared to modern language standards, but companies see
 business value in it. Even Microsoft has joined the party with Azure
 support for Docker.
Frankly this doesn't have anything to do with Go as in langauge. For instance, just because I use tools written in Perl doesn't mean I endorse Perl.
Yes you do, this is economy 101.
I guess that's some course number, maybe in USA. Anyhow to the question at hand: I would switch to anything else on the first sight and wouldn't notice the difference. It's just a _happenstance_ (accidental). Something folks frequently mistake for other qualities like maturity, stability or even "the tool for the job". Humans tend to mistake other fundamental qualities in pretty much the same way making conclusions based on emotional qualities/quantities like: 1. if it's really old project it must be stable and well tested 2. this is the new library it must be faster then all of the old ones 3. if A has less LOCs then B, it can't possibly deliver more features and so on ... Nice thing that any of this can go both ways depending on whom you ask, but most would provided a strong opinion w/o ever going down to exact _facts_ of specific project(s).
 By using tools based on Perl you are creating a market perception that
 it is worth creating tools in Perl.
The perception is the key word. People mistake shiny stuff for gold because of it, when one stops thinking is the moment where things like "perception" and "general sentiment" start to creep in.
 So others that do endorse the
 language, will see their skills being requested to created more tools,
 which increases the visibility of the language and rises the interest to
 learn it.
Good point and it also answers the main question about D - to become popular there need to be tools written in D. In fact I wrote a couple at work, simple beasts that do one thing and do it well. Problem is we need OpenSource and General Purpose. For instance a general purpose build tool might be a killer app. There are plenty of other good things to write in D but efficient batch processing tools/CLI are the current sweet spot (IMHO).
 --
 Paulo
-- Dmitry Olshansky
Nov 14 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 14 Nov 2014 23:22:25 +0300
Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Yes you do, this is economy 101.
I guess that's some course number, maybe in USA.
ah, that means "basics of ...", "something from the first semester of the first year of the given discipline".
Nov 14 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 14 November 2014 at 20:22:30 UTC, Dmitry Olshansky 
wrote:
 ...

 Good point and it also answers the main question about D - to 
 become popular there need to be tools written in D. In fact I 
 wrote a couple at work, simple beasts that do one thing and do 
 it well.

 Problem is we need OpenSource and General Purpose. For instance 
 a general purpose build tool might be a killer app. There are 
 plenty of other good things to write in D but efficient batch 
 processing tools/CLI are the current sweet spot (IMHO).
I guess D's adoption depends on those that can somehow push it in their workplace. For me, I have came to realize there is no use for D in the JVM/.NET/Mobile ecosystems I work with. The way we select programming languages, even within those ecosystems, have nothing to do with language bullet features, rather with human factors and whatever technology stack is already in place, or requested by the customer. This does not apply only to D, but to all other languages out there. For example, we never used anything other than JavaScript on the browser side for our web projects. And keeping up with all of that, requires a lot of time already. -- Paulo
Nov 15 2014
prev sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13/11/14 10:36, Paulo Pinto via Digitalmars-d wrote:
 Actually I think it makes the life harder to earn Windows developers hearts for
 D, specially with .NET Native around the corner (it will come in Windows 10).


I don't think there's any point in worrying about this. Microsoft open-sourcing .NET and making Visual Studio freely available is a great contribution to software development. Rather than worrying about whether it will take away opportunities from D, we should just focus on making D as good as it can be and solving the problems of the people who find it compelling.
Nov 13 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 November 2014 10:57, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

 This is good news for D! It lowers the bar for writing 64 bit D code on
 Windows, and it also enables us to abandon support for versions of VS prior
 to 2013.
Many, many corporate VS users get stuck on legacy versions of VS for a very long time. We still use VS2010 at work for instance, with no plan to upgrade. It would be a shame to lose legacy VS support, but I think the focus should certainly emphasise these future releases. A really nice start would be supporting the modern VS debugging stuff, for instance, the latest VS can track variables in registers for debugging release code... that would be a massive win! :) (Note: We should also be able to inspect class members, and step through code with scope's properly... so I won't hold my breath >_<)
Nov 13 2014
parent "Trass3r" <un known.com> writes:
On Thursday, 13 November 2014 at 09:36:26 UTC, Manu via 
Digitalmars-d wrote:
 On 13 November 2014 10:57, Walter Bright wrote:
 This is good news for D! It lowers the bar for writing 64 bit 
 D code on
 Windows, and it also enables us to abandon support for 
 versions of VS prior
 to 2013.
Many, many corporate VS users get stuck on legacy versions of VS for a very long time. We still use VS2010 at work for instance, with no plan to upgrade. It would be a shame to lose legacy VS support, but I think the focus should certainly emphasise these future releases.
It's perfectly possible to install newer versions side-by-side and even combine the new IDE with the old crap compiler for transitioning, which I've done since the very first CTP. Starting with 2013 the express editions are also fully usable and only lack plugin support. The rest is just excuses.
Nov 13 2014
prev sibling parent "MachineCode" <netorib94 gmail.com> writes:
On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:
 http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

 This is good news for D! It lowers the bar for writing 64 bit D 
 code on Windows, and it also enables us to abandon support for 
 versions of VS prior to 2013.
I don't use neither VS for D nor dmd 64-bit compiler but Mono-D + dmd 32-bit instead of. Whay does means
 enables us to abandon support for versions of VS prior to 2013
? why should you be supporting it before?
Nov 13 2014