[foresto]

I like a lot about D. My main criticism of the language is that it quickly becomes too noisy as more of its nice features are used. I think this could be fixed, for example with better attribute defaults in function signatures, and I think Walter is aware of this.

I could tolerate the noisy language bits, but:

The standard library (Phobos) was so riddled with paper cuts that every day I used it felt like trying to navigate the surface of a coral reef... barefoot... in a hurricane... while blindfolded. It drove me off after a few months. (That was last year.)

A Phobos V3 design has begun, but given how few people they have to work on it, I am skeptical of it ever developing into a library that I would want to use. Here's hoping for a pleasant surprise. :)

[Clouudy]

You have any specific complaints about Phobos and a standard library you like?

[foresto]

A few examples from a little over a year ago:

Heavy reliance on the range interface, without automatic support for common range-like types like arrays, so calling code must be cluttered with wrappers.

Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)

The doubly-linked list implementation had no obvious way to remove a node by reference; removal of an inner item seemed to require traversing the list.

Inconsiderately designed class hierarchies. (e.g. InternetAddress & Internet6Address shared a base class that lacked a port field.)

Inconsiderately designed interfaces. (e.g. CRC32 could deliver a result only as a byte array, which fits the generic std.digest interface, but not as an integer, which is how 32-bit CRCs are often used in the real world.)

Unfortunate naming choices scattered about, such as a function name implying behavior subtly different from what the function does and a user probably expects (leading to surprising bugs) or named after a specific computer science algorithm instead of its purpose (making the needed operation hard to discover).

Various types and functions defined without the attributes required by other parts of the stdlib, or required in order to use/override them in safety-minded code. (e.g. nothrow, @safe, scope)

Time module lied about system clock resolution despite having internally retrieved the correct value from the OS.

Generally useful functionality kept private within the library, rather than made public, forcing users to either re-implement it themselves or lean on arcane trickery to get at it. (e.g. string escaping.)

Logger output customization was needlessly difficult.

No viable async/coroutine support. Vibe.d is the closest substitute, but is a third-party package, integrates poorly with Phobos, isn't documented very well, and is buggy.

...

Mind, these are just highlights of things I discovered while using D for one small project (a network protocol library and tool) so this is by no means a comprehensive account of problems in Phobos. All these problems could be worked around, but I ended up spending far too much time investigating them and developing workarounds instead of being productive.

I acknowledge that I was new to D, so some of my complaints might have had solutions. (However, I would point out that a solution that isn't easy to find might as well not exist.) Regardless, the pattern was clear: Phobos was a PITA to use. Too many paper cuts.

> a standard library you like?

I stuck with C, C++, and Python for more than a few years. Their standard libraries all have significant problems, but none frustrated me so much as to drive me away from the language.

[alphaglosined]

The following statement originates from Adam Wilson who is heading the PhobosV3 project, and I will second it.

The issues you have are examples of known problems that PhobosV2 has suffered under. Coroutines, for instance we would like to have in language, a proposal (me, not Adam) have already made one, but it's sitting till next year. Naming and interfaces issues are a big part of what will change in PhobosV3.

[Neku42]

If you introduce coroutines, please consider unifying them conceptually w/ generators (or better yet - ranges)

[Neku42]

>Heavy reliance on the range interface, without automatic support for common range-like types like arrays, so calling code must be cluttered with wrappers.

But D arrays/slices are already ranges. Is this referring to string autodecoding or something else completely? I fail to recall any situations where builtin types required wrappers often.

>Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)

This is mirroring C++ iterator design and IMO the right move though I agree that specifically for ranges it is rather awkward to use in practice.

What would you return instead? A pointer? What if one wants to find the position of the element and do something after that with that position/subrange.

[schveiguy]

Thank you for this post. I can tell you that we do appreciate comments like this, and the deficiencies you cite are many of the reasons we are rewriting phobos and druntime.

The time module "lied" seems like a straight up bug. Can you give any more details on it?

[foresto]

https://issues.dlang.org/show_bug.cgi?id=24446

Thanks for responding well to constructive criticism.

[schveiguy]

Wow, this was introduced in 2012!

https://github.com/dlang/druntime/pull/88