2015-07-21 15:17 GMT+02:00 Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com>:
>
> Probably I need to better explain why I think we should try that.
>
> It all starts with a high level thought. We want to accelerate D adoption
> rate way beyond what it is now. Radically, like 10x. We've done a number of
> things, many of which helped. But there's this thought - if we keep on
> doing what we've been doing, we'll keep on getting the results we've been
> getting. (There could be changes of phase, synergy, cumulative effects etc.
> but just waiting for those to happen doesn't sound like the best tactics.)
>
> So I keep an eye on radical new things we could try - things we have not
> done before, and that have worked for others. Some might just not work, but
> we don't know if we don't just try.
>
> At the first D meetup in the Silicon Valley, Vic (an accomplished
> entrepreneur who has been following up D'd path) discussed some ideas for
> improving D's adoption. He mentioned some other languages have improved
> adoption by means of a strong application (e.g. Rails for Ruby) and
> suggested we make vibe.d, which is one of D's most compelling publicly
> available applications, more prominent among D's toolchain. He mentioned
> that many folks start with the high-level need ("I need a web framework")
> and accept the language as an artifact.
>
> I think that's a good idea to try, for several reasons. First, it will
> enhance vibe.d's visibility (there are quite a few D users who haven't
> heard of vibe). Second, it consolidates things and makes it easy for folks
> who want to get vibe.d - no more version incompatibilities, multiple
> downloads, things that don't mesh etc. Third, it provides even non-vibe
> users with a good example of a large framework written in D that they may
> use for inspiration and good language use.
>
>
It is a good idea, but there are other ways to achieve it.
Vibe.d is ATM going in the other direction: Plan is to split it up in more
smaller chunks, and encourage people to write plugins to it: markdown /
reST processors being the leading examples . See the following comment:
https://github.com/rejectedsoftware/vibe.d/issues/1134#issuecomment-111365416
Enhancing visibility won't happen by just bundling it. We can write a
"getting started with Vibe" or "Web development using D" on the website.
Someone would want to take a shot at it / contribute to that ?
We could also, at a later stage, integrate Vibe.d's docs within the website.
Regarding version incompatibilities: read my previous post.
- what about vibe.d's dependencies
>> - how would dub know about the distributed vibe.d package
>> - how to use multiple vibe.d versions in parallel
>>
>
> These may be framed two ways. One is, these are arguments to not integrate
> vibe.d with D. The other is, we buy into the vision that we should try
> bundling vibe with D, and as a matter of course we need to solve some
> practical matters. Clearly these all are solvable.
>
>
Once again, bundling it would be against where Vibe is currently going at :
more features by creating smaller packages that integrates together.
