[Silhouette]

Particularly if you have a complex and multi-faceted problem domain at hand, ecosystem and library support can be a dealbreaker, for which many people would sacrifice expressiveness and language power.

Just to reiterate: I think the current situation is perfectly understandable. Obviously the ecosystem does make a huge difference to how productive someone can be in any given programming language, and the choices of language that projects are making are perfectly rational given their constraints and objectives.

It's just unfortunate that this creates momentum behind languages like C, PHP and JavaScript, which then concentrates the effort of library development within their ecosystems, creating a vicious cycle. In terms of robustness and productivity, the industry would be better served by moving almost all development work away from that sort of underpowered, poorly specified, error-prone language as soon as possible, but you can't do that without the libraries. Developing that ecosystem for any new language takes huge amounts of time and effort, so to have any realistic chance of catching on, you first need an excellent bridge to existing libraries. Sadly, the FFI infrastructure even in relatively good languages tends to be clunky at best, and that is a huge barrier to adoption for all the reasons you mentioned.

Starting off from first principles can be quite impractical these days, so stitching together others' work is becoming a common paradigm.

On the other hand, the trade-off for that reduction in NIH early development effort is that you now have a discovery problem up-front and a dependency management problem indefinitely. I don't think that as an industry we've really found a good balance yet between not reinventing the wheel and not spending forever choosing which of 57 pre-existing wheels to use.

What I'd love to see is a new generation of languages that accept the modern reality of combining packages from diverse sources and so place much greater emphasis on supporting that kind of software architecture. Interoperability between packages, each with their own related but probably slightly different concepts and conventions, needs to be much more of a priority IMHO. When we can compose data structures and algorithms across packages from different sources, and have all the marshalling and type safety and error handling mechanisms just work with minimal programmer intervention, then we'll be getting somewhere. But of course that's just one more substantial issue that any new language has to address on top of everything else, which is no small thing to ask.

[vezzy-fnord]

It's not just clunky FFIs. There are simply some APIs and standards (like POSIX) that are more-or-less designed with a specific language in mind, in the aforementioned case that being C. Using them from a different language can simply feel awkward, though I suppose there has been a shortage of effort in bridging the gap.

I agree that the ridiculous dependency chains and brittle build tooling/bootstrapping are getting out of hand in modern development. Go actually gets this thing right, but is bare bones in every other regard (which I also appreciate, I enjoy Rob Pike's work).

I can't really think of any solution to this dilemma, though. Fundamentally, it's not just limitations of languages, but of operating systems, as well. Having a file server-centric OS design instead of a daemon-centric one for providing services alone will simplify a whole lot of things that we're used to abstracting in libraries.