www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Microsoft to contribute to Clang and LLVM project

reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
News article, Microsoft releases Clang with Microsoft CodeGen:

http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx

The interesting bit is at the end:

"
Clang with Microsoft CodeGen isn't just a private fork of the 
open-source Clang compiler. We'll be contributing the vast majority of 
the Clang and LLVM changes we've made back to the official Clang and 
LLVM sources. The biggest of these changes is support for emitting debug 
information compatible with the Visual Studio debugger
"

With these developments, one asks again, is it wise to spend any more 
time working and using the Digital Mars backend for D?...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Dec 07 2015
next sibling parent reply Karabuta <Karabutaworld gmail.com> writes:
On Monday, 7 December 2015 at 11:26:27 UTC, Bruno Medeiros wrote:

 News article, Microsoft releases Clang with Microsoft CodeGen:

 http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx

 The interesting bit is at the end:

 "
 Clang with Microsoft CodeGen isn't just a private fork of the 
 open-source Clang compiler. We'll be contributing the vast 
 majority of the Clang and LLVM changes we've made back to the 
 official Clang and LLVM sources. The biggest of these changes 
 is support for emitting debug information compatible with the 
 Visual Studio debugger
 "

 With these developments, one asks again, is it wise to spend 
 any more time working and using the Digital Mars backend for 
 D?...


Well not everyone uses visual studio. It may be of help to other 
win guys though. Not me ATM. So yes it is soo oo worth it IMO.
Dec 07 2015
parent hnoor0011 <hanifnoor0011 gmail.com> writes:
On Monday, 7 December 2015 at 14:22:15 UTC, Karabuta wrote:

 On Monday, 7 December 2015 at 11:26:27 UTC, Bruno Medeiros



_________________
NOOR
Dec 09 2015
prev sibling next sibling parent reply Bubbasaur <bubba hotmail.com> writes:
On Monday, 7 December 2015 at 11:26:27 UTC, Bruno Medeiros wroçte:

 ...
 With these developments, one asks again, is it wise to spend 
 any more time working and using the Digital Mars backend for 
 D?...


The problem are the companies to work, where I live today the 

Java, I'll not bother to mention of course HTML, JS, PHP...

And what's the relation with you asked? Well many companies here 
have partnership with Microsoft and they use their products like 
VS, so I don't think it's wise.

Matheus.
Dec 09 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 9 December 2015 at 14:35:29 UTC, Bubbasaur wrote:

 The problem are the companies to work, where I live today the 

 Java, I'll not bother to mention of course HTML, JS, PHP...

 And what's the relation with you asked? Well many companies 
 here have partnership with Microsoft and they use their 
 products like VS, so I don't think it's wise.


Hm, I kind of agree with Bruno, and I don't really understand why 
dropping a homegrown backend would not be wise? It probably keeps 
the language from evolving.

If clang and gcc become the de-facto standard compilers then C++ 
will gain a new edge because then the shared subset of extensions 
that clang/gcc share will become portable and adoption of new 
standards will be sped up.
Dec 09 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 9 December 2015 at 15:29:45 UTC, Ola Fosheim 
Grøstad wrote:

 Hm, I kind of agree with Bruno, and I don't really understand 
 why dropping a homegrown backend would not be wise?


Oh nevermind, I misread, thought you meant it wouldn't be wise to 
drop it. I get it now ;-).
Dec 09 2015
prev sibling next sibling parent Xinok <xinok live.com> writes:
On Monday, 7 December 2015 at 11:26:27 UTC, Bruno Medeiros wrote:

 With these developments, one asks again, is it wise to spend 
 any more time working and using the Digital Mars backend for 
 D?...


I asked this very question about a year ago. The thread is here:

http://forum.dlang.org/post/mjwitvqmaqlwvoudjoae forum.dlang.org
Dec 09 2015
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 7 December 2015 at 11:26:27 UTC, Bruno Medeiros wrote:

 News article, Microsoft releases Clang with Microsoft CodeGen:

 http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx

 The interesting bit is at the end:

 "
 Clang with Microsoft CodeGen isn't just a private fork of the 
 open-source Clang compiler. We'll be contributing the vast 
 majority of the Clang and LLVM changes we've made back to the 
 official Clang and LLVM sources. The biggest of these changes 
 is support for emitting debug information compatible with the 
 Visual Studio debugger
 "

 With these developments, one asks again, is it wise to spend 
 any more time working and using the Digital Mars backend for 
 D?...


Walter has decades invested in his backend, he won't even look at 
code for other compilers.  He's still working on his dmd backend, 
just added DWARF exception-handling support.  Dmd is still the 
fastest to compile and provides reasonably good code generation, 
though not the best, so dmd still has use as a fast development 
compiler.

Let's see, did I miss a reason?  These are all the ones I've read 
on the forum in the past.
Dec 09 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:

 Let's see, did I miss a reason?  These are all the ones I've 
 read on the forum in the past.


But the real question is whether it is a strategic good move?

Go is the only language now that use its own backend and they 
loose performance over it, and get bad comments for it, but they 
get to tailor it to a reasonable GC so it has some strategic 
value.

Rust recently announced that Mozilla is going to include Rust 
code in their products in 2016. So they are committed.

The science people seem to rally behind Julia JIT, and a JIT and 
mindshare is important in that field.

With Swift on Linux the ARC approach becomes less attractive for 
other languages as you put yourself up for direct comparison. If 
Swift can get reasonable performance on Linux and Android then 
they will take a fair marketshare real fast because of tooling 
and portability, both on mobile and even on web servers.

In this crowded "close to production ready" landscape competition 
becomes more fierce. I think languages like Swift going cross 
platform will create trouble for languages like Nim and D.
Dec 09 2015
next sibling parent reply Jonny <Jonny nomail.com> writes:
On Thursday, 10 December 2015 at 02:22:34 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:

 Let's see, did I miss a reason?  These are all the ones I've 
 read on the forum in the past.


 But the real question is whether it is a strategic good move?

 Go is the only language now that use its own backend and they 
 loose performance over it, and get bad comments for it, but 
 they get to tailor it to a reasonable GC so it has some 
 strategic value.

 Rust recently announced that Mozilla is going to include Rust 
 code in their products in 2016. So they are committed.

 The science people seem to rally behind Julia JIT, and a JIT 
 and mindshare is important in that field.

 With Swift on Linux the ARC approach becomes less attractive 
 for other languages as you put yourself up for direct 
 comparison. If Swift can get reasonable performance on Linux 
 and Android then they will take a fair marketshare real fast 
 because of tooling and portability, both on mobile and even on 
 web servers.

 In this crowded "close to production ready" landscape 
 competition becomes more fierce. I think languages like Swift 
 going cross platform will create trouble for languages like Nim 
 and D.


It would be nice to have a D JIT that is fast as others and can 
be easily used in a D app and interface with it's host without 
too much work.

The more D can do to cover as much ground as it can well, the 
more attractive it is, right?
Dec 09 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 03:02 +0000, Jonny via Digitalmars-d wrote:

=20


[=E2=80=A6]

 It would be nice to have a D JIT that is fast as others and can=20
 be easily used in a D app and interface with it's host without=20
 too much work.


[=E2=80=A6]

But D is a fully compiled language with an AOT compiler. How does a JIT
fit into the workflow?

--=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
Dec 10 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:


 But D is a fully compiled language with an AOT compiler. How does a JIT
 fit into the workflow?


REPL, data/config format, perhaps vibe.d diet templates.

-- 
/Jacob Carlborg
Dec 10 2015
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 13:12 +0100, Jacob Carlborg via Digitalmars-d
wrote:

 On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:
=20

 But D is a fully compiled language with an AOT compiler. How does a
 JIT
 fit into the workflow?


=20
 REPL, data/config format, perhaps vibe.d diet templates.


So use of D syntax as a language that isn't actually D?

--=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
Dec 10 2015
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 10 December 2015 at 12:24:23 UTC, Russel Winder 
wrote:

 On Thu, 2015-12-10 at 13:12 +0100, Jacob Carlborg via 
 Digitalmars-d wrote:

 On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:
 

 But D is a fully compiled language with an AOT compiler. How 
 does a
 JIT
 fit into the workflow?


 
 REPL, data/config format, perhaps vibe.d diet templates.


 So use of D syntax as a language that isn't actually D?


Is PyPy not really Python?
Dec 10 2015
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 15:17 +0000, Jack Stouffer via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 Is PyPy not really Python?


Yes it is. All Python compilers do though is generate bytecodes (as do
all Java compilers). Then there is the question whether to AOT or JIT.
PyPy JITs (as does CPython, sort of). Jython also JITs but this is on
JVM bytecodes.

--=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
Dec 11 2015
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 10 December 2015 at 12:12:28 UTC, Jacob Carlborg 
wrote:

 On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:


 But D is a fully compiled language with an AOT compiler. How 
 does a JIT
 fit into the workflow?


 REPL, data/config format, perhaps vibe.d diet templates.


Like how rdmd simplifies using dmd, you would want something that 
simplifies things further? Like so that when you run something 
from rdmd, it doesn't just compile things and then run, it starts 
running and then JITs what is needed.

I think there definitely would be something convenient about a 
language that you could easily compile or use like a scripting 
language without changing the syntax at all.
Dec 10 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-10 18:36, jmh530 wrote:


 REPL, data/config format, perhaps vibe.d diet templates.


 Like how rdmd simplifies using dmd, you would want something that
 simplifies things further? Like so that when you run something from
 rdmd, it doesn't just compile things and then run, it starts running and
 then JITs what is needed.

 I think there definitely would be something convenient about a language
 that you could easily compile or use like a scripting language without
 changing the syntax at all.


I'm not sure how related rdmd is to the above mentioned features. If one 
would use rdmd for the above, it would require to compile the code as a 
dynamic library and the load that. I guess that could be possible.

-- 
/Jacob Carlborg
Dec 10 2015
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 11 December 2015 at 07:40:55 UTC, Jacob Carlborg wrote:

 I'm not sure how related rdmd is to the above mentioned 
 features. If one would use rdmd for the above, it would require 
 to compile the code as a dynamic library and the load that. I 
 guess that could be possible.


I was really trying to get a handle on what their point was.

rdmd provides an immediacy that is similar to using some 
scripting languages. For me, rdmd is better to use when 
prototyping something than C++, but I'm still more productive 
prototyping something with R or Matlab.

Nevertheless, while I think there is value in an REPL-like 
environment for D, I would also give it a low, low priority.

Some people have said things like D is an AOT compiled language. 
Fine. But imagine you had a scripting language with the exact 
same syntax and semantics as D, but this language can be used 
with an REPL. Maybe there would be a few differences, but for the 
most part a program written in this language could also be 
compiled with dmd.

Consider the relationship between C and Ch. It provides an REPL 
interactive shell for C along with some other changes. While 
there are some differences, you're still basically using an 
interpreted version of C.

Let's suppose there's a Dh that is to D as Ch is to C. Would some 
people find value in Dh? I think yes. Would there be some overlap 
between implementing this hypothetical language and dmd/rdmd? I 
would suspect quite a bit (though I don't know enough of the 
technical details). Would it be possible to use a JIT in the 
implementation? I don't see why not. Should smart people work on 
creating Dh? I'm guessing other priorities are more important.
Dec 11 2015
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 17:36 +0000, jmh530 via Digitalmars-d wrote:

=20


[=E2=80=A6]

 Like how rdmd simplifies using dmd, you would want something that=20
 simplifies things further? Like so that when you run something=20
 from rdmd, it doesn't just compile things and then run, it starts=20
 running and then JITs what is needed.
=20
 I think there definitely would be something convenient about a=20
 language that you could easily compile or use like a scripting=20
 language without changing the syntax at all.


But isn't rdmd just a compiler and executor? It is not an interpreter.
This is AOT with no role for JIT.

--=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
Dec 11 2015
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 10 December 2015 at 02:22:34 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:

 Let's see, did I miss a reason?  These are all the ones I've 
 read on the forum in the past.


 But the real question is whether it is a strategic good move?


Doesn't matter if it is or it isn't, he has decades invested in 
it and will not even look at another backend.  Since he's the 
only one working on it and not that much (with some nips and 
tucks from Martin, Daniel, Rainer, Kenji, and a few others: 
https://github.com/D-Programming-Language/dmd/commits/master/src/backend), I
don't see why others are so concerned about it.  A better use of their time
would be to chip in themselves, on documentation or whatever else they're
capable of contributing.


 Go is the only language now that use its own backend and they 
 loose performance over it, and get bad comments for it, but 
 they get to tailor it to a reasonable GC so it has some 
 strategic value.

 Rust recently announced that Mozilla is going to include Rust 
 code in their products in 2016. So they are committed.

 The science people seem to rally behind Julia JIT, and a JIT 
 and mindshare is important in that field.

 With Swift on Linux the ARC approach becomes less attractive 
 for other languages as you put yourself up for direct 
 comparison. If Swift can get reasonable performance on Linux 
 and Android then they will take a fair marketshare real fast 
 because of tooling and portability, both on mobile and even on 
 web servers.


There is no one language that will work for every market.  With 
the advent of trends like micro-services, you can even use 
multiple languages in the same company relatively safely.  D 
tries to hit a lot of markets, but it cannot possibly hit the 
sweet spot in every market.  Perhaps those are better tools for 
those markets, while D will hit different segments of those 
markets and new markets altogether.


 In this crowded "close to production ready" landscape 
 competition becomes more fierce. I think languages like Swift 
 going cross platform will create trouble for languages like Nim 
 and D.


I agree that Swift is a strong competitor, as I've been saying, 
but it is currently way behind D in platform support, ie 
currently just iOS, OS X, and largely done linux/Glibc.  Each has 
their pros and cons and will garner their own adherents.
Dec 09 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 05:20:26 UTC, Joakim wrote:

 I don't see why others are so concerned about it.  A better use 
 of their time would be to chip in themselves, on documentation 
 or whatever else they're capable of contributing.


I think the primary concern is "what is the plan?". Without a 
clear plan it really doesn't matter what you do or not do as an 
individual with just a few hours per week. It's like voting or 
volunteering for a party with the right ideas, but no clear 
strategy for getting into position. The second concern is that 
people evaluate performance based on the official compiler. They 
evaluate Go, not gccgo, and they evaluate dmd, not ldc with an 
older frontend. This happens repeatedly when people write about 
these languages.


 sweet spot in every market.  Perhaps those are better tools for 
 those markets, while D will hit different segments of those 
 markets and new markets altogether.


That required a strategy. Like, I am now likely to pick up C 
again, just to be able to build tight asm.js. WebGL is now 
becoming mature and asm.js is becoming a massive target, but it 
takes a focused group to do better than emscripten... So you need 
a central strategy in order to organize something like that.


 I agree that Swift is a strong competitor, as I've been saying, 
 but it is currently way behind D in platform support, ie 
 currently just iOS, OS X, and largely done linux/Glibc.  Each 
 has their pros and cons and will garner their own adherents.


Swift may need 1-2 more years, but if people can replace two 
languages with one, then they have a strong adoption card. But I 
am not sure if Swift will be able to gain C speeds consitently, 
though I would not bet on it.

But it is rather obvious that being similar to Swift is not a 
good strategy. If languages get too close, then the better 
ecosystem wins.
Dec 10 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 10 December 2015 at 08:43:21 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 10 December 2015 at 05:20:26 UTC, Joakim wrote:

 I don't see why others are so concerned about it.  A better 
 use of their time would be to chip in themselves, on 
 documentation or whatever else they're capable of contributing.


 I think the primary concern is "what is the plan?". Without a 
 clear plan it really doesn't matter what you do or not do as an 
 individual with just a few hours per week.


I agree that a plan needs to be articulated.  I hoped to get 
something like that from the vision statement, but broad goals 
like improving quality or fostering participation are pretty 
useless.  It should have gone into concrete detail on how they 
favored accomplishing those broad aims, say by better integrating 
Panteleev's Digger and other tools into the build process or 
improving the documentation about getting started on developing D 
itself.

Perhaps they've been burnt in the past by putting time into 
writing out concrete plans for D and nobody taking up those 
tasks- I don't know- but at the very least there should be a 
central place where others can see the core team's prioritized 
TODO lists.  Martin has done great work getting some of the core 
team on trello, but Walter and Andrei do not seem to use it:

https://trello.com/b/XoFjxiqG/active

Anyway, even without a plan, we can see from past commits on the 
backend alone that it's not a time suck.


 It's like voting or volunteering for a party with the right 
 ideas, but no clear strategy for getting into position. The 
 second concern is that people evaluate performance based on the 
 official compiler. They evaluate Go, not gccgo, and they 
 evaluate dmd, not ldc with an older frontend. This happens 
 repeatedly when people write about these languages.


Hopefully, the recent change to the Downloads page to point out 
that dmd is faster to compile while gdc and ldc produce faster 
code will change that. I think you underestimate how much of a 
selling point dmd's speed is, even if I personally will not be 
able to use it on Android/ARM.


 sweet spot in every market.  Perhaps those are better tools 
 for those markets, while D will hit different segments of 
 those markets and new markets altogether.


 That required a strategy. Like, I am now likely to pick up C 
 again, just to be able to build tight asm.js. WebGL is now 
 becoming mature and asm.js is becoming a massive target, but it 
 takes a focused group to do better than emscripten... So you 
 need a central strategy in order to organize something like 
 that.


Personally, I think that entire web platform is stupid, so I 
don't care that D doesn't target it.  Mobile and embedded is a 
_much_ more important target and we're making headway there.  Dan 
recently got the D tests running on the Apple tvOS and watchOS 
simulators: soon you'll be able to run D on your TV or watch! :)


 I agree that Swift is a strong competitor, as I've been 
 saying, but it is currently way behind D in platform support, 
 ie currently just iOS, OS X, and largely done linux/Glibc.  
 Each has their pros and cons and will garner their own 
 adherents.


 Swift may need 1-2 more years, but if people can replace two 
 languages with one, then they have a strong adoption card. But 
 I am not sure if Swift will be able to gain C speeds 
 consitently, though I would not bet on it.


Well, right now, D is on far more platforms, so it has a head 
start, though alpha quality on mobile.  I'm sure Swift will try 
to compete, but Apple is not going to port it to Android and 
it'll be interesting to see how much outside contribution they 
get, considering Apple is the largest company on earth and people 
don't really want to do their work for them.  D, without large 
corporate support, actually doesn't have that problem, ie a giant 
company pushing an OSS project is a double-edged sword.

The first time Apple tried to spur an OSS community with Darwin 
and their base OSS tools, it never took off, with Apple only 
providing open-source code dumps ever since.  It's only later 
efforts like WebKit, now forked by google for Chrome and Android, 
and llvm that have built OSS communities.  While Swift has a 
better chance, since it comes from the llvm group, it will be 
interesting to see how much outsiders contribute to it.


 But it is rather obvious that being similar to Swift is not a 
 good strategy. If languages get too close, then the better 
 ecosystem wins.


You assume that they're very similar and that Swift will have a 
better ecosystem eventually.  They are _somewhat_ similar but 
different enough to attract different devs, and I pointed out 
above why they might not be able to grow their community much 
larger.
Dec 11 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 11 December 2015 at 10:22:18 UTC, Joakim wrote:

 I agree that a plan needs to be articulated.  I hoped to get 
 something like that from the vision statement, but broad goals 
 like improving quality or fostering participation are pretty 
 useless.  It should have gone into concrete detail on how they 
 favored accomplishing those broad aims, say by better 
 integrating Panteleev's Digger and other tools into the build 
 process or improving the documentation about getting started on 
 developing D itself.


Well, my main issue with D is that there is no plan for making 
things simpler in order to add more advanced clean features based 
on modern static analysis at the next stage. New features are 
added, like hacking in C++ support or multiple-alias-this, that 
just adds more complexity.

Although I still have some hope that a refactored codebase could 
make "simplification" possible as a side project by an 
independent group. But making a cleaner version of that language 
doesn't seem to be on the map by the core developers. As such, D 
is in the same tarpit as Go. "We are done". Ok, but then these 
languages will remain in a very small niche that most likely will 
shrink, not grow. To me, both Go and D are stuck a little bit in 
the past and I think both languages will need to move one step 
back in order to make a leap forward.

C++14 would have been great if they had bothered to clean up the 
language before adding even more to it. I think C++ is a good 
example of what happens when one doesn't take a step back and 
clean up in time.


 I think you underestimate how much of a selling point dmd's 
 speed is


Even so, the best performing compiler ought be the official one 
and released first.

Go also is acclaimed for great compilation speed, yet people 
complain about execution and say they switch to Rust over it etc. 
And Rust is known to be slow at compilation.


 Personally, I think that entire web platform is stupid, so I 
 don't care that D doesn't target it.


This is the big problem. It is an open target that is available, 
and you only compete with C/C++. Yet it isn't prestige among 
language devs to target it, and it isn't established, so people 
ignore it. In 5 years people will curse because they didn't 
actively target it before other languages got established on it.

If you want to grow that is exactly the kind of target you want. 
People switch if you are the only alternative. That is exactly 
when they switch to smaller niche products.

People adopted Perl, it was the only real alternative for 
prototyping like transforms of text.

People adopted Php, it was the only real alternative for 
embedding code into html.

People thought those application areas were so boring compared to 
"a general purpose language". It was  not "serious" programming 
areas. So these languages owned those domains for many years, and 
grew big.


 Dan recently got the D tests running on the Apple tvOS and 
 watchOS simulators: soon you'll be able to run D on your TV or 
 watch! :)


That's great fun! But it isn't a business-plan with Swift being 
there already.


 Well, right now, D is on far more platforms, so it has a head 
 start, though alpha quality on mobile.  I'm sure Swift will try 
 to compete, but Apple is not going to port it to Android and


I think they are going to make some core libraries available. I 
think that has been announced.


 The first time Apple tried to spur an OSS community with Darwin 
 and their base OSS tools, it never took off, with Apple only 
 providing open-source code dumps ever since.  It's only later


There is a lot demand for an easy path from iOS to Android that 

compiler made by another company for that purpose. But with Apple 
backing this approach it becomes much more attractive.


 Android, and llvm that have built OSS communities.  While Swift 
 has a better chance, since it comes from the llvm group, it 
 will be interesting to see how much outsiders contribute to it.


There are some speculations on whether Apple might want to 
compete with AWS, Google and Microsoft and use Swift as the 
platform. (iCloud)


 You assume that they're very similar and that Swift will have a 
 better ecosystem eventually.  They are _somewhat_ similar but 
 different enough to attract different devs, and I pointed out 
 above why they might not be able to grow their community much 
 larger.


I assume that some people _might_ bother to weed out the 
efficiencies in Swift that are related to staying compatible with 
Objective-C and turn it into a reasonable high level system level 
language for those that don't need that compatibility.

It won't compete directly with Rust or C++, but it might compete 
fiercely with other languages that go the ARC route.
Dec 11 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 11 December 2015 at 11:42:31 UTC, Ola Fosheim Grøstad 
wrote:

 There is a lot demand for an easy path from iOS to Android that 

 compiler made by another company for that purpose. But with 
 Apple backing this approach it becomes much more attractive.


For those interested, this is the alternative Swift compiler I 
was referring to. I haven't tried it though, but it seems to mix 


http://www.elementscompiler.com/elements/silver/
Dec 11 2015
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 11 December 2015 at 11:42:31 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 11 December 2015 at 10:22:18 UTC, Joakim wrote:

 I agree that a plan needs to be articulated.  I hoped to get 
 something like that from the vision statement, but broad goals 
 like improving quality or fostering participation are pretty 
 useless.  It should have gone into concrete detail on how they 
 favored accomplishing those broad aims, say by better 
 integrating Panteleev's Digger and other tools into the build 
 process or improving the documentation about getting started 
 on developing D itself.


 Well, my main issue with D is that there is no plan for making 
 things simpler in order to add more advanced clean features 
 based on modern static analysis at the next stage. New features 
 are added, like hacking in C++ support or multiple-alias-this, 
 that just adds more complexity.


Unless you articulate what your alternate plan is to make things 
simpler, perhaps along with some github PRs or a DIP, things will 
keep going as they are.


 Although I still have some hope that a refactored codebase 
 could make "simplification" possible as a side project by an 
 independent group. But making a cleaner version of that 
 language doesn't seem to be on the map by the core developers. 
 As such, D is in the same tarpit as Go. "We are done". Ok, but 
 then these languages will remain in a very small niche that 
 most likely will shrink, not grow. To me, both Go and D are 
 stuck a little bit in the past and I think both languages will 
 need to move one step back in order to make a leap forward.

 C++14 would have been great if they had bothered to clean up 
 the language before adding even more to it. I think C++ is a 
 good example of what happens when one doesn't take a step back 
 and clean up in time.


I completely agree that languages need to clean up and release 
breaking versions at some point, just as D did with the 2.0 
release.


 I think you underestimate how much of a selling point dmd's 
 speed is


 Even so, the best performing compiler ought be the official one 
 and released first.


I don't see why, usually you prototype first with the faster 
compiler, then build for production with the slower one with 
better codegen.  Of course, it doesn't help that ldc/gdc are 
behind in the frontend version they're using, but you could 
always use an older dmd to prototype if you know you'll need 
ldc/gdc.


 Go also is acclaimed for great compilation speed, yet people 
 complain about execution and say they switch to Rust over it 
 etc. And Rust is known to be slow at compilation.


I'm sure both types of speed have their own audience, but with D 
you can have both. :)


 Personally, I think that entire web platform is stupid, so I 
 don't care that D doesn't target it.


 This is the big problem. It is an open target that is 
 available, and you only compete with C/C++. Yet it isn't 
 prestige among language devs to target it, and it isn't 
 established, so people ignore it. In 5 years people will curse 
 because they didn't actively target it before other languages 
 got established on it.


I don't think system programming languages have much of a shot at 
web dev, which is why I've always said the market for vibe.d is 
limited, no matter how great it is.  C/C++ certainly have almost 
no penetration there.  Web devs use scripting languages to 
prototype, then switch to Java when they need to scale.  D could 
maybe hit those who want to scale beyond that, but that's not 
many places.

Your asm.js/WebAssembly target is a little different, but using 
the web for such apps is just as dumb.  There are good reasons 
why mobile is ascendant and webapps on the downswing.


 If you want to grow that is exactly the kind of target you 
 want. People switch if you are the only alternative. That is 
 exactly when they switch to smaller niche products.

 People adopted Perl, it was the only real alternative for 
 prototyping like transforms of text.

 People adopted Php, it was the only real alternative for 
 embedding code into html.

 People thought those application areas were so boring compared 
 to "a general purpose language". It was  not "serious" 
 programming areas. So these languages owned those domains for 
 many years, and grew big.


"Grew big" _in those domains_, ie they have made no inroads into 
other markets.  This is what I keep pointing out to you: you can 
optimize for one niche and do extremely well there, but then you 
often find yourself stuck in that niche, as Go finds itself today.


 Dan recently got the D tests running on the Apple tvOS and 
 watchOS simulators: soon you'll be able to run D on your TV or 
 watch! :)


 That's great fun! But it isn't a business-plan with Swift being 
 there already.


It is for those who want to be cross-platform, as D pretty much 
passes all its tests on Android and iOS, while Swift is still 
only on iOS.


 Well, right now, D is on far more platforms, so it has a head 
 start, though alpha quality on mobile.  I'm sure Swift will 
 try to compete, but Apple is not going to port it to Android 
 and


 I think they are going to make some core libraries available. I 
 think that has been announced.


Not for Android, Apple will _never_ make Swift for Android, the 
community will have to do that.


 The first time Apple tried to spur an OSS community with 
 Darwin and their base OSS tools, it never took off, with Apple 
 only providing open-source code dumps ever since.  It's only 
 later


 There is a lot demand for an easy path from iOS to Android that 

 compiler made by another company for that purpose. But with 
 Apple backing this approach it becomes much more attractive.


Apple is not backing any approach: they're making the source 
available so devs can do anything they want with it.


 Android, and llvm that have built OSS communities.  While 
 Swift has a better chance, since it comes from the llvm group, 
 it will be interesting to see how much outsiders contribute to 
 it.


 There are some speculations on whether Apple might want to 
 compete with AWS, Google and Microsoft and use Swift as the 
 platform. (iCloud)


If so, they're pretty dumb, as server hosting is a low-margin, 
highly competitive business.  I have no idea why google or MS 
would want to be in it.  Amazon I kind of understand, because 
their retail business is even lower-margin!

I think Apple has long ago learned the lessons of WebObjects, 
Xserve, and OS X Server: stay out.


 You assume that they're very similar and that Swift will have 
 a better ecosystem eventually.  They are _somewhat_ similar 
 but different enough to attract different devs, and I pointed 
 out above why they might not be able to grow their community 
 much larger.


 I assume that some people _might_ bother to weed out the 
 efficiencies in Swift that are related to staying compatible 
 with Objective-C and turn it into a reasonable high level 
 system level language for those that don't need that 
 compatibility.

 It won't compete directly with Rust or C++, but it might 
 compete fiercely with other languages that go the ARC route.


Which isn't D either, unless you include D because of the GC.  
Swift looks like a strong competitor- I've always said that- but 
it's yet to be seen what kind of uptake it gets out of its home 
turf of iOS.

On Sunday, 13 December 2015 at 12:29:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 10 December 2015 at 15:16:05 UTC, Paulo Pinto 
 wrote:

 Both are now getting AOT compilers as part of their standard 
 toolchains.


 I found this video interesting:

 https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Introducing-the-dotnet-CLI


 them from other languages?


Yep, that's what Paulo keeps referring to.
Dec 15 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 15 December 2015 at 16:17:32 UTC, Joakim wrote:

 Unless you articulate what your alternate plan is to make 
 things simpler, perhaps along with some github PRs or a DIP, 
 things will keep going as they are.


I don't think series of DIPs will change anything. First we need 
to be close to consensus on what ought to be done better.

But since Swift has SIL and Rust is getting MIR, I'm starting to 
think that it would be overall less work to build a new language 
adopted to one of those than polishing Nim, Crystal and D... That 
option didn't really exist before, and it won't resonate well 
with D designers either.

But it is a reasonable strategy when languages seem to be 
converging on semantics that are rather similar.

The basic question is: can you afford to compete?

Yes, if you reuse existing infrastructure, not only what exists, 
but what is coming.



 Your asm.js/WebAssembly target is a little different, but using 
 the web for such apps is just as dumb.  There are good reasons 
 why mobile is ascendant and webapps on the downswing.


I don't think there is a downswing for web-apps.



 you can optimize for one niche and do extremely well there, but 
 then you often find yourself stuck in that niche, as Go finds 
 itself today.


Being stuck in Go's niche would be a fantastic situation for D as 
Go's market penetration might be 20x that of D. The main 
limitation for Go is the Go language authors' vision and 
attitudes. Not really related to the domain.



 Which isn't D either, unless you include D because of the GC.


D2 appears to be going for ref counted ownership, so I assume 
that the outcome will be that D2 becomes comparable to Swift with 
ARC.

D2 might have trouble finding a key feature to market after Swift 
adds hygienic macros. Depending on how they go about it.
Dec 15 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 15 December 2015 at 20:02:27 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 15 December 2015 at 16:17:32 UTC, Joakim wrote:

 you can optimize for one niche and do extremely well there, 
 but then you often find yourself stuck in that niche, as Go 
 finds itself today.


 Being stuck in Go's niche would be a fantastic situation for D 
 as Go's market penetration might be 20x that of D. The main 
 limitation for Go is the Go language authors' vision and 
 attitudes. Not really related to the domain.


If it were merely the D team's goal to quickly gain usage like 
Go, such higher market penetration would be fantastic, but I 
don't think that's what they're after.  It seems to be unseating 
C/C++ as the major systems and application programming languages, 
while simultaneously expanding that market upwards into 
higher-level domains C++ can't get into today.

That's a longer game, one you don't rush into.  Will D get there? 
I have no idea, but the recent improvements in C++ imply that new 
AoT-compiled languages like D, Rust, and Go are at least 
pressuring C++ to up its game.  In that sense, the new languages 
can't lose, because even if they go out of use, their best 
features will already have made it into C++.

But I don't think they have to worry about that, as I suspect the 
market for AoT-compiled languages is simply becoming more 
fragmented again, as the scripting languages market has long 
been.  Each of these AoT languages will likely maintain their own 
niche, and C++ has so much legacy baggage- they never talk about 
getting rid of the preprocessor, that's when I'll know they're 
serious- that at least one of them will displace it at the top, 
maybe D. :)
Dec 15 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 16 December 2015 at 04:36:28 UTC, Joakim wrote:

 don't think that's what they're after.  It seems to be 
 unseating C/C++ as the major systems and application 
 programming languages, while simultaneously expanding that 
 market upwards into higher-level domains C++ can't get into 
 today.


I think that  this cannot happen without making asm.js a primary 
target. Being able to port engines to the browser is just too 
valuable. Even for compilers...


 been.  Each of these AoT languages will likely maintain their 
 own niche, and C++ has so much legacy baggage- they never talk 
 about getting rid of the preprocessor, that's when I'll know 
 they're serious- that at least one of them will displace it at 
 the top, maybe D. :)


Yes, learning C++ is time consuming. I don't think it will be 
replaced in a decade, but Swift will take away some from it in 
the applications area. Just like C++ has taken away from C. Maybe 
Rust, maybe D3... ;)
Dec 16 2015
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 December 2015 at 02:22:34 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:

 [...]


 But the real question is whether it is a strategic good move?

 Go is the only language now that use its own backend and they 
 loose performance over it, and get bad comments for it, but 
 they get to tailor it to a reasonable GC so it has some 
 strategic value.

 Rust recently announced that Mozilla is going to include Rust 
 code in their products in 2016. So they are committed.

 The science people seem to rally behind Julia JIT, and a JIT 
 and mindshare is important in that field.

 With Swift on Linux the ARC approach becomes less attractive 
 for other languages as you put yourself up for direct 
 comparison. If Swift can get reasonable performance on Linux 
 and Android then they will take a fair marketshare real fast 
 because of tooling and portability, both on mobile and even on 
 web servers.

 In this crowded "close to production ready" landscape 
 competition becomes more fierce. I think languages like Swift 
 going cross platform will create trouble for languages like Nim 
 and D.


Just as a side effect of that, see the list of supported 
languages in Visual Studio 2015 Update 1 for editing and basic 
intelisense.

http://blogs.msdn.com/b/visualstudio/archive/2015/11/30/visual-studio-update-1-rtm.aspx
Dec 09 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 02:22 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:

=20


[=E2=80=A6]

 The science people seem to rally behind Julia JIT, and a JIT and=20
 mindshare is important in that field.
=20


[=E2=80=A6]

Julia doesn'have that great a penetration in the market compared to
Python, R, C++ and Fortran.

--=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
Dec 10 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 10:51:00 UTC, Russel Winder 
wrote:

 Julia doesn'have that great a penetration in the market 
 compared to Python, R, C++ and Fortran.


Sure, in day-to-day work people use what they have until they 
need to start over. How is the landscape going to unfold? What 
languages would you consider for a from-scratch scientific 
library? Same thing with Swift, what languages will you consider 
for cross platform mobile development in a year or two?

Interestingly C++'s position has been strengthened within Google 
in the last few years, according to Chandler Carruth, so it does 
not look like Go will driven towards replacing C++? But, it 
probably has a solid position for smaller scale servers. I 
personally hope Google will adopt Swift. And I think that would 
be a better strategy for Google than pushing Go, Dart and so on.
Dec 10 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 11:16 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:

 On Thursday, 10 December 2015 at 10:51:00 UTC, Russel Winder=20
 wrote:

 Julia doesn'have that great a penetration in the market=20
 compared to Python, R, C++ and Fortran.


=20
 Sure, in day-to-day work people use what they have until they=20
 need to start over. How is the landscape going to unfold? What=20
 languages would you consider for a from-scratch scientific=20
 library? Same thing with Swift, what languages will you consider=20
 for cross platform mobile development in a year or two?


Julia clearly has a strong and (relatively slowly) growing community.
It will require the "killer app" effect to change it from being a
fairly niche language given the state of the R, Python, C++, Fortran
establishment.

Clearly Go is biting into the C and Python usage, but I suspect mostly
only in networking and networking-related things.=C2=A0


 Interestingly C++'s position has been strengthened within Google=20
 in the last few years, according to Chandler Carruth, so it does=20
 not look like Go will driven towards replacing C++? But, it=20
 probably has a solid position for smaller scale servers. I=20
 personally hope Google will adopt Swift. And I think that would=20
 be a better strategy for Google than pushing Go, Dart and so on.


C++17 and C++20 are very likely to undermine any move by C++ folk to
Rust or D I suspect.

--=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
Dec 10 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 12:28:16 UTC, Russel Winder 
wrote:

 Julia clearly has a strong and (relatively slowly) growing 
 community. It will require the "killer app" effect to change it 
 from being a fairly niche language given the state of the R, 
 Python, C++, Fortran establishment.


Yes, it will certainly take time. I've recently watched some of 
the videos from JuliaCon2015 and I'm getting this "constructive 
tinkerer" feeling from them. I'm perceiving the same kind of 
enthusiasm as you get from fans of SmallTalk, Processing and 
other "tinkering-languages". Such domain-oriented eco-systems can 
build very strong communities over time, I think.



 Clearly Go is biting into the C and Python usage, but I suspect 
 mostly only in networking and networking-related things.


Yes, Python is much better for transforming data easily, so I am 
bit sceptical of Go as a replacement for other languages. Seems 
to be more of a "narrow" language, like for delivery of 
dynamic/interactive web content.


 C++17 and C++20 are very likely to undermine any move by C++ 
 folk to Rust or D I suspect.


As long as the message "next version of modern C++ is going to be 
much better" is being delivered they probably will stick with 
it... I guess that is the strategy, announce the next version of 
C++ before the current one is implemented.

And that might also be a reason for people dropping Go. There is 
just no hope if you are unhappy with the current language.

I think maybe over time some embedded C++ could move to Rust. 
There seems to be some sporadic efforts to do runtime-less Rust. 
The language itself doesn't seem to be runtime heavy.
Dec 10 2015
prev sibling parent reply Suliman <evermind live.ru> writes:
 C++17 and C++20 are very likely to undermine any move by C++ 
 folk to Rust or D I suspect.


So I hope Walter and Andrew will do steps like including vibed in 
DMD distributive and will focus on Web-assembly. I am not sure 
that strategy of better integration with C++ is help to get more 
people interesting in D. It's just like IBM, that added support 
of Windows apps in OS/2 instead of writing native.

I really hope to see D more high level language instead language 
concurrent with with came niche with Rust.
Dec 10 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:

 So I hope Walter and Andrew will do steps like including vibed 
 in DMD distributive and will focus on Web-assembly. I am not 
 sure that strategy of better integration with C++ is help to 
 get more people interesting in D.


I think it would require making D semantics aligned with C++, 
rather than trying to align C++ semantics with D. A 50% solution 
isn't really worth it.

Objective-C++ is a 100% C++ compatible solution. And that really 
makes a big difference.
Dec 10 2015
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:

 C++17 and C++20 are very likely to undermine any move by C++ 
 folk to Rust or D I suspect.


 So I hope Walter and Andrew will do steps like including vibed 
 in DMD distributive and will focus on Web-assembly. I am not 
 sure that strategy of better integration with C++ is help to 
 get more people interesting in D. It's just like IBM, that 
 added support of Windows apps in OS/2 instead of writing native.

 I really hope to see D more high level language instead 
 language concurrent with with came niche with Rust.


But here it is also problematic.



Both are now getting AOT compilers as part of their standard 
toolchains.

Java will eventually get a better story for value types with Java 
10.


used to develop project Midori.

Given that one cannot consider a programming language without the 
eco-system, I don't see the type of customers we work with, 
switching away from the JVM or CLR.

--
Paulo
Dec 10 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 10 December 2015 at 15:16:05 UTC, Paulo Pinto wrote:

 Both are now getting AOT compilers as part of their standard 
 toolchains.


I found this video interesting:

https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Introducing-the-dotnet-CLI


them from other languages?
Dec 13 2015
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:

 So I hope Walter and Andrew will do steps like including vibed 
 in DMD distributive


Please no.

Not everything has to be in Phobos; this just puts unnecessary 
pressure on Phobos maintainers to work on vibe.d as well, and it 
will slow down vibe.d development DRASTICALLY due to the extra 
scrutiny for Phobos PRs. Not to mention that breaking changes 
will no longer be able to happen with vibe.d. Also, vibe.d seems 
to be doing just fine as it is.
Dec 10 2015
next sibling parent Suliman <evermind live.ru> writes:
On Thursday, 10 December 2015 at 15:25:16 UTC, Jack Stouffer 
wrote:

 On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote:

 So I hope Walter and Andrew will do steps like including vibed 
 in DMD distributive


 Please no.

 Not everything has to be in Phobos; this just puts unnecessary 
 pressure on Phobos maintainers to work on vibe.d as well, and 
 it will slow down vibe.d development DRASTICALLY due to the 
 extra scrutiny for Phobos PRs. Not to mention that breaking 
 changes will no longer be able to happen with vibe.d. Also, 
 vibe.d seems to be doing just fine as it is.


You are right, but maybe at last to merge some common API?
Dec 10 2015
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-12-10 at 15:25 +0000, Jack Stouffer via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 Please no.
=20
 Not everything has to be in Phobos; this just puts unnecessary=20
 pressure on Phobos maintainers to work on vibe.d as well, and it=20
 will slow down vibe.d development DRASTICALLY due to the extra=20
 scrutiny for Phobos PRs. Not to mention that breaking changes=20
 will no longer be able to happen with vibe.d. Also, vibe.d seems=20
 to be doing just fine as it is.


The days of "batteries included" in language distributions are well
over. Something Python is having to come to terms with and not doing
too well as yet. (Though Continuum Analytics are driving one possible
future forward very well.)

The core distribution, here Druntime and Phobos, should only be that
which is consciously in integral and required part of the language.
Everything else should be in packages. Ceylon + Herd, Rust + Cargo +
crates.io, Go + (Git|Mercurial), etc. My feeling is that Ceylon is a
bit restrictive in that it only has a central curated repository. Go is
being over libertarian in having no central repository but great
support for DVCS repositories. Rust may be taking the best middle path,
there is a curated central repository but also, easy access to Git and
Mercurial repositories.=C2=A0

Clearly D has a package system, but in this it is like Ceylon. I think
it needs to be more like Rust. So in this sense Dub needs to be more
like Cargo. (It is already very like, in fact may have influenced.)

--=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
Dec 11 2015
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:

 just added DWARF exception-handling support


I think this illustrates the entire problem. How many years has 
GCC and LLVM had this?
Dec 09 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 10 December 2015 at 04:12:20 UTC, Jack Stouffer 
wrote:

 I think this illustrates the entire problem. How many years has 
 GCC and LLVM had this?


http://clang.llvm.org/docs/MSVCCompatibility.html

"Exceptions and SEH: Partial. C++ exceptions (try / catch / 
throw) and structured exceptions (__try / __except / __finally) 
mostly work on x64. 32-bit exception handling support is being 
worked on."


LLVM really isn't in all that different of a place than dmd. They 
have stuff that works but doesn't have full compatibility with 
the others yet. Same thing here.
Dec 09 2015