Criticizing Hare language approach for generic data structures

What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.

I’m not bashing Go though. I appreciate the focus on readability among other things. It’s a fine language for the use cases it was actually designed for, like pushing petabytes of ad data to serving clusters all around the world with acceptable latency and reliability.

Hare's problems are much deeper. They stem directly from Drew's fundamental misunderstanding of the nature of software development. Drew is correct that managing complexity is central to the problem of software development. He is 100% wrong on how a programming language can contribute to solving that central problem.

There has been a great deal of progress, in the past five decades since C burst on the scene, on managing complexity in programming tasks, with programming language design taking a big bite. Hare adopts exactly none of that success, setting users straight back to the 1970s again. That might have been fine if demands on programmers were no greater than in the 1970s (although the bugginess of software coded then argues otherwise), but anyway we do not live in that world anymore. The programs we want to run don't fit in 64K of RAM and run single-threaded with no network connections, anymore. Where a 1970s language is used for programs today, we all suffer from the failings the language almost unavoidably invites into them.

The fundamental insight that Drew has wholly missed is that essential complexity demands more attention to get right than is typically available for one use case. We have learned that pulling complexity into a library component, or (better) a Standard Library component, or failing that a programming language feature, enables attention to be paid to it amortized across all the programs and libraries that depend on it. All the meaningful progress in programming languages since been in finding ways to bring more of what must be expressed into one place so it may be more widely usable, and able to command correspondingly more attention to its performance and correctness. Standard library components in our modern languages successfully remove their complexity from what programmers must manage.

The ways we have discovered to help with this process include powerful type systems that have been put to work doing heavy lifting far beyond mere "type checking". We have generics to work with types the way types work with values. Certain languages provide extra tools such as destructors/Drop traits that enable automating resource management. Many languages assert direct responsibility for pieces of that task, imposing borrow checking or GC. There is much left to do.

Hare provides exactly none of the tools that have been discovered to encapsulate complexity into carefully correct and generally useful components, or to enable using such a component in all the different places and ways it would be useful. This failing is painfully evident in the library components it does attempt.

In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy. Evaluated as a toy, there is nothing wrong with it. But it is not presented as a toy. As a tool for programming in the modern world, it is sorely lacking everywhere that C is sorely lacking, that make C directly responsible for the massive suffering documented in the litany of CVEs, botnets, database exposures, and ransom events.