Why Phobos is cool

[Petar]

On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
> Phobos sometimes gets a bad name around these parts, but 
> actually it's pretty cool (in spite of well-known warts).  One 
> of the cool things about it is the batteries-included 
> philosophy that used to be its guiding principle.  Over the 
> course of my usage of D, the following have stood out as being 
> particularly convenient when I needed it:
>
> 1) std.bigint: one time, I was working on a quadratic 
> irrational arithmetic module, and pretty quickly discovered 
> that numerical overflow was a problem that cropped up pretty 
> often.  Or rather, I was seeing what I *thought* was caused by 
> arithmetic overflow, and wanted to be sure.  Solution?  Easy: 
> templatize the coefficient type, import std.bigint, and within 
> several minutes, I have a working implementation that can 
> support arbitrarily large coefficients -- with which I not only 
> confirmed that the observed problems were caused by arithmetic 
> overflow, but also obtained a working solution simultaneously.  
> Win!
>
> 2) std.numeric.poly: another time, I had to work with 
> evaluating a bunch of polynomials, and specifically, with 
> evaluating their roots quickly and accurately.  I could roll my 
> own, poorly, and get results that may or may not be 
> highly-skewed by accumulated errors... or I could use 
> std.numeric.poly to get a reliable evaluation of the 
> polynomial, and, better yet, use std.numeric.findRoot to 
> compute roots with the confidence that the value I get will 
> have as small an error as is possible within the constraints of 
> built-in hardware floats. Plus, this saved me tons of 
> development and debugging time to roll my own solution. Win!
>
> 3) Just today, I needed to implement a fast Fourier transform. 
> Not expecting this to be in Phobos, I was glancing over various 
> algorithms to decide which one suited my use case best and is 
> easy enough to implement quickly. And then I discovered 
> std.numeric.Fft, already done and nicely-packaged and ready to 
> use.  Total win!!
>
> Seriously, D + Phobos is cool beans.  Yes it's not perfect -- 
> the language has its fair share of dark corners, WATs, and 
> Phobos has its share of poorly-designed APIs and outdated 
> modules.  But seriously, a lot of what's currently there is 
> pretty darned cool, and we shouldn't let all the bad stuff 
> cloud our appreciation of just how cool it already is.
>
>
> T

I suggest checking http://mir-algorithm.libmir.org/.
Ilya has been doing a truly amazing job at both developing, 
maintaining and optimizing this library.
Also he has put a hard focus on memory allocators, @nogc and 
betterC (for exposing libmir to C and C++ users and also for 
scripting languages like Python or Julia).
AFAIK his work has been sponsored by Symmetry, so I suppose 
libmir gets a lot of internal use there.

Meanwhile, if you look at std.numeric, for past several years, 
basically all contributions but a few have been just around basic 
stuff like code style, imports and fixing a few compile errors in 
generic code.

Phobos is dead. There haven't been any new modules since ~2016. 
Actually the last one (IIRC) was std.experimental.ndslice, which 
Ilya contributed and then removed (1-2 releases after) from 
Phobos to start libmir.

Since std.experimental.allocator was added to Phobos circa 2015, 
there hasn't been a single Phobos or Druntime module using it 
(ndslice and checkedint don't count). Many packages on 
code.dlang.org enthusiastically embraced 
std.experimental.allocator only to get burned a few dmd releases 
after as Phobos doesn't follow SemVer. The solution? Many of the 
most popular OSS D apps libraries (I can only comment on those) 
transitioned to using the Dub fork: 
https://github.com/dlang-community/stdx-allocator. How does it 
help? Well, OSS D libraries can't control the compiler that their 
users are using. For example, vibe.d tries to support the last 5 
major versions of dmd/ldc, and Dub the last 15+ major versions. 
This means they can't depend on std.experimental.* as there's no 
telling what kind changes can happen for such a large timespan. 
Instead they can stick a particular version of 
https://code.dlang.org/packages/stdx-allocator in their 
dub.{json,sdl} file and be sure that it won't suddenly break 
their code.

The sooner we realize this and start collectively working on 
improving Dub and code.dlang.org, the better. Yes, Dub is not a 
great build tool. And so what? Most great build tools were not so 
great in their infancy. I doubt Scons was much better in 1999. If 
people continue avoiding Dub for whatever reason it won't get 
better by itself.
There's no reason why Dub can't expose a lower-level DSL for 
precise target dependency graph building. It's just a matter of 
people making a sustained effort in contributing one.

The Rust community has realized that a slim standard library + a 
solid package manager is the way to go. Rust is also backed by 
Mozilla. And so what? I seriously doubt that more than 5-10% of 
all of the 42k packages on https://crates.io/ were created by 
Mozilla employees. Instead the core Rust team realized that they 
can't build everything by themselves, and focused on helping the 
community scale by putting a concentrated effort on Cargo (their 
version of Dub).