<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-07-21 15:17 GMT+02:00 Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Probably I need to better explain why I think we should try that.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br></span></blockquote><div><br></div><div>It is a good idea, but there are other ways to achieve it.</div><div>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: <a href="https://github.com/rejectedsoftware/vibe.d/issues/1134#issuecomment-111365416">https://github.com/rejectedsoftware/vibe.d/issues/1134#issuecomment-111365416</a></div><div>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 ?<br>We could also, at a later stage, integrate Vibe.d's docs within the website.<br><br>Regarding version incompatibilities: read my previous post.<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- what about vibe.d's dependencies<br>
- how would dub know about the distributed vibe.d package<br>
- how to use multiple vibe.d versions in parallel<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br></span></blockquote><div><br></div><div>Once again, bundling it would be against where Vibe is currently going at : more features by creating smaller packages that integrates together.</div></div></div></div>