Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.

We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:

Https://golang.org/pkg/
Https://docs.oracle.com/javase/8/docs/api/
Https://doc.rust-lang.org/std/

Dne 7.9.2016 v 07:58 Brian via Digitalmars-d napsal(a):

> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>
> We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
>
> Https://golang.org/pkg/
> Https://docs.oracle.com/javase/8/docs/api/
> Https://doc.rust-lang.org/std/

No, I do not agree that we need HTTP client, database abstraction layer and mail delivery in standard library, those shoud be just packages idealy available from code.dlang.org, but what I think should be part of standard library is some form of async IO

On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak wrote:
> ... I think should be part of standard library is some form of async IO

hello, we can write it as a separate lib as there are no things like JCP and JSR, standartization committee

On Wednesday, 7 September 2016 at 06:51:40 UTC, Daniel Kozak wrote:
> Dne 7.9.2016 v 07:58 Brian via Digitalmars-d napsal(a):
>
>> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>>
>> We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
>>
>> Https://golang.org/pkg/
>> Https://docs.oracle.com/javase/8/docs/api/
>> Https://doc.rust-lang.org/std/
>
> No, I do not agree that we need HTTP client, database abstraction layer and mail delivery in standard library, those shoud be just packages idealy available from code.dlang.org, but what I think should be part of standard library is some form of async IO

Fully rely on third party to promote the D language ecology? Why Java popular, why golang hot? Don't understand reflection!

My studio have collie( https://github.com/putaolabs/collie ) & hunt framework ( https://github.com/putaolabs/hunt ), but I think it's far from enough!

On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>
> We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
>
> Https://golang.org/pkg/
> Https://docs.oracle.com/javase/8/docs/api/
> Https://doc.rust-lang.org/std/

See

https://wiki.dlang.org/Wish_list#std.database.
https://wiki.dlang.org/Wish_list#Native_curl_replacement

On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>

Your opinion is largely shared with the leadership about the size of the standard library. It's just that Phobos reviews are really strict, and things go a bit slowly to enter it.

On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>
> We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
>
> Https://golang.org/pkg/
> Https://docs.oracle.com/javase/8/docs/api/
> Https://doc.rust-lang.org/std/

The only problem is lack of resources. IMO, there is no valid argument to limit the Phobos functionality used by most of programmers (like database, gui, multimedia, network, dsp, numeric, etc)

Piotrek

On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
>
> We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
>
> Https://golang.org/pkg/
> Https://docs.oracle.com/javase/8/docs/api/
> Https://doc.rust-lang.org/std/

1. When you say "We need to", I assume that means you have some open pull requests or are working on some, right?

2. Everything but the math library is extremely prone to change within a couple of years and is therefore not really a good candidate for standardization. There's a reason that there are three different ways to connect to a MySQL database within the PHP standard library: they tried to standardize something that shouldn't really be standardized.

On Wednesday, September 07, 2016 15:22:01 Jack Stouffer via Digitalmars-d wrote:
> On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote:
> > Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library.
> >
> > We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up:
> >
> > Https://golang.org/pkg/ Https://docs.oracle.com/javase/8/docs/api/ Https://doc.rust-lang.org/std/
>
> 1. When you say "We need to", I assume that means you have some open pull requests or are working on some, right?
>
> 2. Everything but the math library is extremely prone to change within a couple of years and is therefore not really a good candidate for standardization. There's a reason that there are three different ways to connect to a MySQL database within the PHP standard library: they tried to standardize something that shouldn't really be standardized.

There are definitely things that function better as 3rd party libraries than as part of the standard library, but the big thing here - regardless of the exact functionality in question - is that someone needs to actually do the work. And that's where we generally fall flat.  Once someone has actually implemented something, _then_ we can discuss whether it makes sense to put it in Phobos, but there isn't necessarily much point in debating that point when there isn't even software to debate over. Regardless of whether the functionality should be in Phobos, it still needs to be implemented, and it can start on code.dlang.org. Whether it gets into the standard library or not is very much a secondary issue to whether it's available in the first place. So, as usual, the question comes down to manpower. We don't have as many appropriately skilled programmers involved as we'd like, and many of the ones that we do have are short on time.

- Jonathan M Davis

On Wednesday, 7 September 2016 at 15:22:01 UTC, Jack Stouffer wrote:

> 2. Everything but the math library is extremely prone to change within a couple of years and is therefore not really a good candidate for standardization. There's a reason that there are three different ways to connect to a MySQL database within the PHP standard library: they tried to standardize something that shouldn't really be standardized.

Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process.

As for PHP, it did most things wrong. What I mean is if one of car manufactures makes bad cars shouldn't we use all of them.

Piotrek