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