Microsoft to contribute to Clang and LLVM project

Joakim via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 15 08:17:32 PST 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:
>> 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.


More information about the Digitalmars-d mailing list