On Wednesday, 23 September 2015 at 23:00:29 UTC, Laeeth Isharc
wrote:
I don't know if focusing on trying to produce a killer app (not
that I suggest you suggest that) will produce the desired
result, since it's trying to short-cut a process that is
essentially organic. Too large an influx of new arrivals
before you are ready for them (docs, libraries, etc) isn't
necessarily only positive. If you are going to host the
Olympics, it's a good idea to make sure the street signs are up
first.
Of course often much better to visit a place before a massive
influx of tourists or permanent overseas residents.
I agree that D may not be ready for a large influx of new users,
but that is a cyclic process that is necessary for growth, ie 10k
new users come in, 5k go away because they run into issues, 5k
stick around and a few pitch in to make things better. A killer
app is a way to get a lot of attention and potential new users
quickly, but nobody's saying that alone is enough. But it is one
way to add to the userbase that might lead to more growth and
more killer apps and libraries later.
Rails led to a lot of new ruby users, some of whom found flaws
with the language and left. Others worked on alternate
implementations and improvements.
What could be done to make its benefits on the server clearer?
One obvious thing is better documentation and more blog posts.
Same as always, publicizing the server successes it has had and
blog posts comparing D and benchmarking vibe.d against other
popular web languages and frameworks. Some on the forums have
suggested getting vibe.d in this apparently popular web benchmark:
https://www.techempower.com/benchmarks/
More D libraries aimed at use on the server, that make getting up
and running there easier, along with posts publicizing them. I
thought this was an interesting snippet from a recent blog post,
highlighting the importance of such marketing:
"What we never know is how quickly diffusion happens. I’ve
observed 'no-brainer' technologies or ideas lie unadopted for
decades, languishing in perpetual indifference and suddenly, with
no apparent cause, flip into ubiquity and inevitability at a
vicious rate of adoption.
Watching this phenomenon for most of my life, I developed a
theory of causation. This theory is that for adoption to
accelerate there has to be a combination of conformability to the
adopter’s manifest needs (the pull) combined with a concerted
collaboration of producers to promote the solution (the push).
Absent either pull or push, adoption of even the brightest and
most self-evident ideas drags on."
http://www.asymco.com/2015/09/21/how-quickly-will-ads-disappear/
There will need to be a paid toolchain at some point, to spur
more development and more manpower on sanding down the rough
edges of the tools. That's a chicken-and-egg situation right
now, as there might not be enough devs and businesses making
money off D to pay for such tools yet.
Hobby/open-source project today, business tomorrow? Who would
wish to bet against that happening with some of the free tool
sets that are already here? (And that would be something to be
welcomed).
Since the D frontend and druntime/phobos are boost-licensed and
at least ldc is mostly BSD-licensed, it is certainly allowed to
integrate proprietary fixes and additions with some of the D
compilers and the standard library. This could be the basis for
a paid toolchain, as I've pointed out before. llvm/clang
certainly started out as such a project and is part of a big
business today, with proprietary additions.
On a related note, I feel like Microsoft is really missing the
boat here, especially when reading Manu and Walter on why llvm
doesn't support MS debuginfo:
"I've actually had quite a few conversations with LLVM dev's about
this, and one of the key excuses for not supporting MS debuginfo
was
the classic 'it's not documented.' I promptly pointed them at your
work every single time it came up, but they ignored or dismissed
it
every time. Dev's are funny like that."
http://forum.dlang.org/post/[email protected]
The problem for Microsoft is that all new languages are using
llvm to generate code. If that code cannot be debugged on
Windows not only because they don't provide any open source way
to integrate such languages with their platform but _do not even
bother to document_ their debuginfo format, so the only way it
gets supported is if Walter reverse-engineers it, there go all
those potential Windows developers. By contrast, the two major
OS platforms of the last decade, iOS and Android, have toolchains
that are almost completely or completely open-source. This means
random people on the internet, like Dan and me, have been able to
get D mostly working on those platforms, with much less work.
Microsoft wouldn't even have to open source everything in their
toolchain, just the parts that would make it easy for other
languages to integrate. Or at least document your damn debug
format! Maybe Microsoft thinks their in-house languages are much
better, but even if that's true, you're missing out on all the
devs using those outside languages.
Of course, part of this, which goes unmentioned by Manu, is that
the llvm devs likely work for Apple and aren't incented to
support Microsoft. But there's nothing stopping Microsoft from
contributing to llvm or just documenting the format. They've
been doing some stuff with llvm lately, so maybe things are
changing, but this is a clear win that is likely much more
important:
http://blog.llvm.org/2015/04/llilc-llvm-based-compiler-for-dotnet.html
http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx
In that second link, they actually note "debugging-friendly
code-generation" as a benefit of using the VC++ backend. I'm
sorry, if you have to refrain from documenting your format in
order to help your backend, you've already lost.
