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.
