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 main jobs are for C# or 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 
 main jobs are for C# or
 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 does not involve hacks like C#. There was actually a Swift 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 
 does not involve hacks like C#. There was actually a Swift 
 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 with Java/C#: 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 does not involve hacks like C#. There was actually a Swift 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 Apparently it will become possible to AOT C# libraries and call 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. D is pretty close in syntax to Java and C#. 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. C# 7 and later are getting features from System C#, the version 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 Apparently it will become possible to AOT C# libraries and call 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