On 2/18/17 10:20 PM, Seb wrote:
> On Monday, 9 May 2016 at 10:44:13 UTC, ZombineDev wrote:
>> On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:
>>> On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
>>>> But given that std.net.curl handles stuff like SSL/TLS, we _can't_
>>>> actually replace all of its functionality - at least not without
>>>> adding a dependency on a different C library, since there's no way
>>>> that it's sane to do the crypto stuff ourselves without a crypto
>>>> expert, and even then, we should think twice about it. I could see
>>>> implementing the SSL/TLS protocols themselves but not the crypto
>>>> they use. If we replace std.net.curl, we likely should just provide
>>>> the basic HTTP functionality, and leave the rest to a dub package
>>>> that we move std.net.curl to.
>>>
>>> Any chances that we can produce good crypto code over time? And
>>> verify it with experts, of course.
>>
>> https://github.com/etcimon/botan AFAIK, it is already used in
>> production by its author, in combination with libasync + vibe.d +
>> http2 for a full stack D solution.
>
>
> So what's the consensus on this issue?
> Can't we simply move std.net.curl and etc.c.curl to undead and just
> _not_ include it in Phobos?
> Anyone reasonable will use requests [1], vibe.d's async requestHTTP [2]
> or their home-grown library anyways. As mentioned in another thread [3],
> Phobos is bloated with "old" modules that wouldn't have made it through
> today's review process.

For some time I was a proponent of yanking stuff from Phobos into oblivion. Now I'm not. Stop breaking code. Yes, we should think harder before introducing libraries into Phobos but continuing on with removal of stuff just introduces the continuous churn for no adequate benefit.

What would anyone get from std.net.curl removal? Are you going to find all of D programs and patch them to use something else?

Yes, Phobos is full of historical accidents and cruft. I'm constantly tempted to propose Phobos v2 properly _designed_ (not *grown*) and without the junk. I really think it might be a good idea but only when we actually know what a proper design looks like.

---
Dmitry Olshansky

On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky wrote:
> Yes, Phobos is full of historical accidents and cruft. I'm constantly tempted to propose Phobos v2 properly _designed_ (not *grown*) and without the junk. I really think it might be a good idea but only when we actually know what a proper design looks like.

You are not the only one!
Did you follow Ilya's proposal about a betterC modular standard library?

http://forum.dlang.org/post/phexetutyelrssyrucvw@forum.dlang.org

Unfortunately it died because of the fear of "balkanizing the community" with such a development...

(though I am not sure how it could be more "balkanized" as atm everyone seems to grow their own home-made libraries)

On Sat, 18 Feb 2017 21:41:51 +0000, ketmar wrote:

> Seb wrote:
>> So what's the consensus on this issue?
> 
> leave curl where it is now.
> 
> i am teh user. i have alot of code depending on std.net.curl. i hope that "we are not breaking user's code" motto is not just a PR slogan.

I've got a fair bit too.

On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky wrote:
> [...]
> For some time I was a proponent of yanking stuff from Phobos into oblivion. Now I'm not. Stop breaking code. Yes, we should think harder before introducing libraries into Phobos but continuing on with removal of stuff just introduces the continuous churn for no adequate benefit.
>
> What would anyone get from std.net.curl removal? Are you going to find all of D programs and patch them to use something else?
>
> Yes, Phobos is full of historical accidents and cruft. I'm constantly tempted to propose Phobos v2 properly _designed_ (not *grown*) and without the junk. I really think it might be a good idea but only when we actually know what a proper design looks like.

Due to writing the AppStream metadata generator in D, which is an infrastructure piece of many Linux distributions, I have a fair bit of knowledge now about the problems people (especially newcomers who just want to scratch an itch and submit a quick patch) encounter when working with D code. The inconsistent standard library is - after compiler bugs - the biggest issue. Some people described Phobos as "PHP-esque" in terms of design, and I have to agree with them. Working with it is often unpleasant, and you can clearly see which parts of it were designed recently and which are "historical accidents".

Constantly shuffling stuff around in Phobos and adding/removing things will not solve the problem, it will just give newcomers a feeling of insecurity and make the language feel less mature.
Stunningly, a lot of projects write their own primitives instead of using Phobos (Vibe, lots of dub modules just providing containers, just now another general purpose utility library was announced on the forums, ...) which is a clear sign that Phobos isn't seen to be sufficient.

I think investigating to build a "Phobos2" standard library would be a very good idea - make it opt-in for a while, and then set a flag-date and switch, so people will only need to adjust their code once to jump on the new version, and don't constantly need to play catch with Phobos API breaks and riddle their code with version() and static if instructions to be able to compile with multiple Phobos and LDC/GDC/DMD versions.

Cheers,
    Matthias

On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek wrote:
> As discussed yesterday at DConf, curl in phobos must go.
>
> The plan is as follows.
>
> 1. undocument everything curl related in may 2016
> 2. deprecate everything curl related in may 2017
> 3. delete everything curl related in may 2018
> 3.1 move curl stuff to undead
>
> PR: https://github.com/dlang/phobos/pull/4283

Two of the most important modules in a standard library are containers & networking. In Phobos they are terrible. How about focusing on that than this nonsense? The Curl wrapper is about the only useful bit of networking code in the entire standard library. How on earth are you gonna compete with Go & Rust with useless container & networking modules?

On Sunday, 19 February 2017 at 04:00:33 UTC, Gavin wrote:
> On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek wrote:
>> As discussed yesterday at DConf, curl in phobos must go.
>>
>> The plan is as follows.
>>
>> 1. undocument everything curl related in may 2016
>> 2. deprecate everything curl related in may 2017
>> 3. delete everything curl related in may 2018
>> 3.1 move curl stuff to undead
>>
>> PR: https://github.com/dlang/phobos/pull/4283
>
> Two of the most important modules in a standard library are containers & networking. In Phobos they are terrible. How about focusing on that than this nonsense? The Curl wrapper is about the only useful bit of networking code in the entire standard library. How on earth are you gonna compete with Go & Rust with useless container & networking modules?

I'm of the opinion that we should grow the curl wrapper.

Take what is done with python for example: their most famous library ever is requests, and anybody doing networking in python first reaches for it. What is the standard library urllib module for then? Well it's the basis requests is written on, it's meant to provide basic, low-level access to the network, and that's ok. People just learned to use requests.

Right now unfortunately the curl wrapper isn't a very good building block to build libraries but by growing it into something with better ranges etc it could be. The critics of the API and memory usage don't need to be: just grow transparently a second facade to the library. No code broken, better tools for better libraries and happier users.

The only real point left is managing the C code in phobos but as Andrei said (not in this terms) if Phobos can't do it what good is the "interfacing with C is dead easy" pitch?