So maybe would be good to pot in phobos vibe's json lib and some other good stuff, to prevent overlapping phobos and vibe's lib that are doing similar things?

On Tuesday, 21 July 2015 at 08:36:12 UTC, Suliman wrote:
> So maybe would be good to pot in phobos vibe's json lib and some other good stuff, to prevent overlapping phobos and vibe's lib that are doing similar things?

I think sönke did already start to work on the json lib at least

On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:
> On 7/20/15 5:30 PM, Martin Nowak wrote:
>> On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:
>>> In what version of DMD do you plan to include dub and vibe?
>>
>> It doesn't make sense to include vibe.d.
>
> I think it does - this has been discussed before. -- Andrei

Have you used dub and vibe.d extensively yourself? I'm seeing quite a lot of pushback on this idea from people who do.

On 7/21/15 4:07 AM, extrawurst wrote:
> I agree, i am a fan of vibe.d too but including it in phobos just tastes
> wrong.

I was thinking of distributing vibe.d as an integrated but distinct package, not part of phobos.

> if you absolutely want to distribute such a lib then consider
> libasync (https://github.com/etcimon/libasync) which is at least
> completely written in D.

Yah, phobos needs features to better support vibe.d and libasync is one of them.


Andrei

On 7/21/15 4:36 AM, Suliman wrote:
> So maybe would be good to pot in phobos vibe's json lib and some other
> good stuff, to prevent overlapping phobos and vibe's lib that are doing
> similar things?

Yes. -- Andrei

On 7/21/15 4:46 AM, John Colvin wrote:
> On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:
>> On 7/20/15 5:30 PM, Martin Nowak wrote:
>>> On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:
>>>> In what version of DMD do you plan to include dub and vibe?
>>>
>>> It doesn't make sense to include vibe.d.
>>
>> I think it does - this has been discussed before. -- Andrei
>
> Have you used dub and vibe.d extensively yourself?

No.

> I'm seeing quite a
> lot of pushback on this idea from people who do.

Well we'll need to address it.


Andrei

On 7/21/15 3:00 AM, Martin Nowak wrote:
> On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:
>> On 7/20/15 5:30 PM, Martin Nowak wrote:
>>> On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:
>>>> In what version of DMD do you plan to include dub and vibe?
>>>
>>> It doesn't make sense to include vibe.d.
>>
>> I think it does - this has been discussed before. -- Andrei
>
> It has, in length
> http://forum.dlang.org/post/mdnrus$188e$1@digitalmars.com, but you
> remain one of the very few to think it is a good idea to distribute
> vibe.d with dmd.

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 doesn't make sense because dub is the enabling tool for the whole
> package ecosystem, with which vibe.d is fully integrated (dub was
> formerly called vpm - vibe package manager).
> Copying a vibe.d version into the distribution creates a lot of problems
> without solving anything.

I agree it does not "solve" anything the same way Rails does not "solve" anything for Ruby.

> - 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.

> If your long-term goal is to integrate vibe into phobos, fine,
> though I'm not a fan of this strategy b/c an independent package
> ecosystem can grow faster.
> Simply copying a dub package into the distribution doesn't help anyone.

I think it could help. This is like one of those business ideas discussions - there are lots of reasons for which any isn't going to work. The point is finding ways to make it work.


Andrei

On Tuesday, 21 July 2015 at 13:17:36 UTC, Andrei Alexandrescu wrote:
> On 7/21/15 3:00 AM, Martin Nowak wrote:
>> [...]
>
> Probably I need to better explain why I think we should try that.
>
> [...]

I can agree with the idea behind it, I am just apposed adding the package to the actual download bundle because of it would decouple it from an ecosystem that we want to encourage D users to use: dub

Bundling dub with dmd IMO will be a major thing helping people benefit from all the awesome work that went into all the great libs and applications in there.

Maybe we can go by an installer option that automatically creates a vibe.d example project and lunching it (while using dub for that all the way).

>
> [...]

On 7/21/15 9:17 AM, Andrei Alexandrescu wrote:

> 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.

Rails is not shipped with ruby. You have to install it separately. In fact, vibe.d follows almost the same model as rails (I may be sketchy on the details, still learning ruby/rails), with gem substituting for dub.

I think what we need is dub to be shipped with d (If it's not already).

-Steve

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.