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.

Reply via email to