Interesting. I guess that was all after my stint playing w/ D. I had never heard about this Amber effort until I googled for tango today, for example. From my perspective as a user, it definitely felt like the API divide was a problem - there were things that were only available on top of phobos and other things that were only available on top of tango and you couldn't use both together.

But yes, all of this was weeeeell over a decade ago. Despite having experienced this friction back then, I still think of D as an extremely productive/pragmatic language with a snappy compiler. Some of the stuff that pops up here and there about new developments in D2-land are also very interesting. If anyone's on the fence about it, I would definitely recommend giving it a shot.

See the api divide wouldn't matter if the runtimes were merged (this actually happened, you can still use Tango today if you like) since you'd just import the other modules and have them side by side. Sure some libs might depend on std.socket and others on tango.socket, but that's not a huge problem since they can exist side-by-side. You might just need an adapter if you wanted to pass a socket from one lib to another that uses the different thing. Slight hassle but totally solvable.

But with the incompatible language runtime components, you couldn't merge the user level libs either. The base Object and Exception classes worked one way in one lib but another in the other and both used the same underlying function names leading to a linker conflict. The user-level namespaces in D are always isolated to modules, but this low level language runtime is global.

That was solved when the Tango requirements got merged upstream.