On Sunday, 19 May 2019 at 03:33:15 UTC, Andrei Alexandrescu wrote:
> https://news.ycombinator.com/item?id=19948642

Thanks for sharing. I think the hacker news comments were nearly as interesting as the article itself. It's a hard problem figuring out what should go in the standard library or not and there's probably n one right answer.

On 5/21/19 2:14 AM, Atila Neves wrote:
> On Sunday, 19 May 2019 at 03:33:15 UTC, Andrei Alexandrescu wrote:
>> https://news.ycombinator.com/item?id=19948642
> 
> Thanks for sharing. I think the hacker news comments were nearly as interesting as the article itself. It's a hard problem figuring out what should go in the standard library or not and there's probably n one right answer.

I didn't know this about Rust, so I found the following comment interesting:

> For example, the libstd doesn't even have support for random number generation. There's a rand crate, which is now on 6th major breaking version. That's perfectly fine, because multiple versions can coexist in one program, and every user can upgrade (or not) at their own pace. And the crate was able to refine its interface six times, instead of being stuck with the first try forever.

Multiple coexisting versions is an interesting way of solving dependency hell.

On 5/21/19 11:15 AM, David Gileadi wrote:
> On 5/21/19 2:14 AM, Atila Neves wrote:
>> For example, the libstd doesn't even have support for random number generation. There's a rand crate, which is now on 6th major breaking version. That's perfectly fine, because multiple versions can coexist in one program, and every user can upgrade (or not) at their own pace. And the crate was able to refine its interface six times, instead of being stuck with the first try forever.
> 
> Multiple coexisting versions is an interesting way of solving dependency hell.

In terms of multiple simultaneously *installed* versions, I consider it an absolutely essential feature of any *good* package manager (This is a big part of why I hate most system-level Linux package managers, including the one on my own machine). But the idea of multiple versions *within one program* is indeed interesting.

Doesn't strike me as something you'd want to frequently take advantage of, but having it there as a viable workaround for when problems do arise could certainly be quite nice.

On Tue, May 21, 2019 at 12:29:55PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 5/21/19 11:15 AM, David Gileadi wrote:
> > On 5/21/19 2:14 AM, Atila Neves wrote:
> > > For example, the libstd doesn't even have support for random number generation. There's a rand crate, which is now on 6th major breaking version. That's perfectly fine, because multiple versions can coexist in one program, and every user can upgrade (or not) at their own pace. And the crate was able to refine its interface six times, instead of being stuck with the first try forever.
> > 
> > Multiple coexisting versions is an interesting way of solving dependency hell.
> 
> In terms of multiple simultaneously *installed* versions, I consider it an absolutely essential feature of any *good* package manager (This is a big part of why I hate most system-level Linux package managers, including the one on my own machine). But the idea of multiple versions *within one program* is indeed interesting.
> 
> Doesn't strike me as something you'd want to frequently take advantage of, but having it there as a viable workaround for when problems do arise could certainly be quite nice.

This is a very interesting idea indeed.  Goes along well with Andrei's recent idea of addition vs. replacement.

And I think it's probably not hard to adopt in D (should we deem it a good idea -- that's still arguable): all you need is for module declarations to come with an attached version number, then include that in the mangling. This automatically gives a unique identifier to symbols in the module, so you could import multiple versions of the same module and have the symbols resolve correctly. Just a minor change in module declarations and in module name mangling.

Of course, how to handle imports that may have multiple satisfying versions is another, stickier, question.


T

-- 
Meat: euphemism for dead animal. -- Flora

Am Tue, 21 May 2019 09:39:29 -0700 schrieb H. S. Teoh:

> On Tue, May 21, 2019 at 12:29:55PM -0400, Nick Sabalausky (Abscissa) via
>> In terms of multiple simultaneously *installed* versions, I consider it an absolutely essential feature of any *good* package manager (This is a big part of why I hate most system-level Linux package managers, including the one on my own machine). But the idea of multiple versions *within one program* is indeed interesting.
>> 
>> Doesn't strike me as something you'd want to frequently take advantage of, but having it there as a viable workaround for when problems do arise could certainly be quite nice.
> 
> This is a very interesting idea indeed.  Goes along well with Andrei's recent idea of addition vs. replacement.
> 
> And I think it's probably not hard to adopt in D (should we deem it a good idea -- that's still arguable):

Having multiple versions of libraries only works well though if there are no dependency cycles between third party modules. Random has a very 'closed' API, so for that it works well.

As another extreme example, consider we have six different versions for std.range. Then we have std.file which provides a v1 range, std.format which only formats v3 ranges, vibe.d which still uses v2 and your applications which want's to combine all these and pass ranges from std.file to vibe.d and std.format.

-- 
Johannes

On Tuesday, 21 May 2019 at 18:06:44 UTC, Johannes Pfau wrote:
> Having multiple versions of libraries only works well though if there are no dependency cycles between third party modules. Random has a very 'closed' API, so for that it works well.

In the JavaScript world, npm doesn't have that problem because it gives each dependency its own dependency tree. (If D tried that, the ABI compatibility issues would be painful, and the embedded developers would weep at the bloat.)

On 5/21/19 6:30 PM, sarn wrote:
> On Tuesday, 21 May 2019 at 18:06:44 UTC, Johannes Pfau wrote:
>> Having multiple versions of libraries only works well though if there are no dependency cycles between third party modules. Random has a very 'closed' API, so for that it works well.
> 
> In the JavaScript world, npm doesn't have that problem because it gives each dependency its own dependency tree. (If D tried that, the ABI compatibility issues would be painful, and the embedded developers would weep at the bloat.)

Wow, that actually explains quite a lot about the modern web.

On Tuesday, 21 May 2019 at 22:30:17 UTC, sarn wrote:
> On Tuesday, 21 May 2019 at 18:06:44 UTC, Johannes Pfau wrote:
>> Having multiple versions of libraries only works well though if there are no dependency cycles between third party modules. Random has a very 'closed' API, so for that it works well.
>
> In the JavaScript world, npm doesn't have that problem because it gives each dependency its own dependency tree. (If D tried that, the ABI compatibility issues would be painful, and the embedded developers would weep at the bloat.)

And that's why a simple vue.js project on my machine gives a node_modules directory that's crowded as a termite mound ...

Please no ...

/P

On Wednesday, 22 May 2019 at 08:00:15 UTC, Paolo Invernizzi wrote:
> And that's why a simple vue.js project on my machine gives a node_modules directory that's crowded as a termite mound ...
>
> Please no ...

Plain npm  usage does not seem to pull in two versions of the same library.

What is common is to have one module for a single function. That's what the directory bloat comes from. So node_modules look more crowded than it actually is. A lot of those functions belong in a standard library though.

For instance Angular pulls in:

nice-try: call a function and discard exceptions
once: throw an error if the function is called twice
onetime: a function returns a cached value if called many times
extend: merge two objects
extend-shallow: merge in properties from other object

And so on…

On Wednesday, 22 May 2019 at 09:16:28 UTC, Ola Fosheim Grøstad wrote:
> Plain npm  usage does not seem to pull in two versions of the same library.

npm allows you to specify a semver range, so if the range does not overlap then it will pull in a "duplicate". Although for libraries that are exposed externally (like react), you can specify that it is a peer dependency that should only exists as one semver version. In which case it should complain.

At least, that is my shallow understanding of the system.

Allowing version 1 and 2 of a library to coexist in the same build is no different than depending on two independent libraries that provides the same functionality under different names.

Makes sense to allow a build to succeed if two modules depends on two different versions of some simple set of functions. Especially in a culture where there tends to be one function per module.