digitalmars.D - Microsoft to contribute to Clang and LLVM project
- Bruno Medeiros (15/15) Dec 07 2015 News article, Microsoft releases Clang with Microsoft CodeGen:
- Karabuta (3/17) Dec 07 2015 Well not everyone uses visual studio. It may be of help to other
- hnoor0011 (3/4) Dec 09 2015 _________________
- Bubbasaur (8/12) Dec 09 2015 The problem are the companies to work, where I live today the
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (8/14) Dec 09 2015 Hm, I kind of agree with Bruno, and I don't really understand why
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/6) Dec 09 2015 Oh nevermind, I misread, thought you meant it wouldn't be wise to
- Xinok (3/6) Dec 09 2015 I asked this very question about a year ago. The thread is here:
- Joakim (9/23) Dec 09 2015 Walter has decades invested in his backend, he won't even look at
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (18/20) Dec 09 2015 But the real question is whether it is a strategic good move?
- Jonny (7/29) Dec 09 2015 It would be nice to have a D JIT that is fast as others and can
- Russel Winder via Digitalmars-d (15/19) Dec 10 2015 [=E2=80=A6]
- Jacob Carlborg (4/6) Dec 10 2015 REPL, data/config format, perhaps vibe.d diet templates.
- Russel Winder via Digitalmars-d (13/20) Dec 10 2015 So use of D syntax as a language that isn't actually D?
- Jack Stouffer (3/14) Dec 10 2015 Is PyPy not really Python?
- Russel Winder via Digitalmars-d (16/19) Dec 11 2015 Yes it is. All Python compilers do though is generate bytecodes (as do
- jmh530 (9/14) Dec 10 2015 Like how rdmd simplifies using dmd, you would want something that
- Jacob Carlborg (6/14) Dec 10 2015 I'm not sure how related rdmd is to the above mentioned features. If one...
- jmh530 (25/29) Dec 11 2015 I was really trying to get a handle on what their point was.
- Russel Winder via Digitalmars-d (14/23) Dec 11 2015 But isn't rdmd just a compiler and executor? It is not an interpreter.
- Joakim (18/40) Dec 09 2015 Doesn't matter if it is or it isn't, he has decades invested in
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (22/32) Dec 10 2015 I think the primary concern is "what is the plan?". Without a
- Joakim (49/84) Dec 11 2015 I agree that a plan needs to be articulated. I hoped to get
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (57/86) Dec 11 2015 Well, my main issue with D is that there is no plan for making
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (6/10) Dec 11 2015 For those interested, this is the alternative Swift compiler I
- Joakim (50/149) Dec 15 2015 Unless you articulate what your alternate plan is to make things
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (23/33) Dec 15 2015 I don't think series of DIPs will change anything. First we need
- Joakim (22/30) Dec 15 2015 If it were merely the D team's goal to quickly gain usage like
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (8/18) Dec 16 2015 I think that this cannot happen without making asm.js a primary
- Paulo Pinto (6/27) Dec 09 2015 Just as a side effect of that, see the list of supported
- Russel Winder via Digitalmars-d (17/21) Dec 10 2015 On Thu, 2015-12-10 at 02:22 +0000, Ola Fosheim Gr=C3=B8stad via Digitalm...
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (13/15) Dec 10 2015 Sure, in day-to-day work people use what they have until they
- Russel Winder via Digitalmars-d (21/37) Dec 10 2015 On Thu, 2015-12-10 at 11:16 +0000, Ola Fosheim Gr=C3=B8stad via Digitalm...
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (21/29) Dec 10 2015 Yes, it will certainly take time. I've recently watched some of
- Suliman (7/9) Dec 10 2015 So I hope Walter and Andrew will do steps like including vibed in
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (6/10) Dec 10 2015 I think it would require making D semantics aligned with C++,
- Paulo Pinto (14/23) Dec 10 2015 But here it is also problematic.
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/7) Dec 13 2015 I found this video interesting:
- Jack Stouffer (8/10) Dec 10 2015 Please no.
- Suliman (3/13) Dec 10 2015 You are right, but maybe at last to merge some common API?
- Russel Winder via Digitalmars-d (28/38) Dec 11 2015 The days of "batteries included" in language distributions are well
- Jack Stouffer (3/4) Dec 09 2015 I think this illustrates the entire problem. How many years has
- Adam D. Ruppe (10/12) Dec 09 2015 http://clang.llvm.org/docs/MSVCCompatibility.html
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
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
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
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
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
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
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
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
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
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: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?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
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
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
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: =20So 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_winderBut 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.
Dec 10 2015
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:Is PyPy not really Python?On 2015-12-10 11:52, Russel Winder via Digitalmars-d wrote:So use of D syntax as a language that isn't actually D?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.
Dec 10 2015
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
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: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.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.
Dec 10 2015
On 2015-12-10 18:36, jmh530 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. -- /Jacob CarlborgREPL, 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
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
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
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: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.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.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
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
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 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.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.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.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! :)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.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.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.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
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 isEven 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 andI 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 laterThere 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
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
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: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 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 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 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.I think you underestimate how much of a selling point dmd's speed isEven 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.I'm sure both types of speed have their own audience, but with D you can have both. :)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.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."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.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.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.Not for Android, Apple will _never_ make Swift for Android, the community will have to do that.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 andI think they are going to make some core libraries available. I think that has been announced.Apple is not backing any approach: they're making the source available so devs can do anything they want with it.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 laterThere 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.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.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)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: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.On Thursday, 10 December 2015 at 15:16:05 UTC, Paulo Pinto wrote:Yep, that's what Paulo keeps referring to.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 15 2015
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
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: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. :)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.
Dec 15 2015
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
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: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[...]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
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
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
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 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=A0Julia 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?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
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
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
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
On Thursday, 10 December 2015 at 13:31:00 UTC, Suliman wrote: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. -- PauloC++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
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
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 distributivePlease 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
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:You are right, but maybe at last to merge some common API?So I hope Walter and Andrew will do steps like including vibed in DMD distributivePlease 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
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
On Thursday, 10 December 2015 at 01:09:30 UTC, Joakim wrote:just added DWARF exception-handling supportI think this illustrates the entire problem. How many years has GCC and LLVM had this?
Dec 09 2015
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