Dependent Haskell

Academically, both reference counting (C++, Swift, some patterns in Rust) and tracing garbage collection (Java, C#) fall under the umbrella of garbage collection.

It only reads like a troll piece because you are deliberately taking his statements in an adversarial context. It's weird to complain about the tone of other posts, and then go on to write a comment like yours.

> This is an explainabrag which is also wrong: languages without these features can also have "clean, maintainable code" and nothing about this list implies "runs fast."

I agree with you here. However, I would also agree with the claim that Haskell is simple at its core. It's simple in a mathematical sense, and that doesn't imply that the language is easy to understand or that such simplicity offers all kinds of advantages other languages lack.

> The author rushes past real-world facts to get to the architecture-astronaut rocket ship, solving type-theoretical problems and pretending it's an engineering exercise. Blast off, I guess.

The author writes a small inaccurate section on the current state of affairs, before writing a very well-explained piece on how to get GHC to be better dependently typed.

Dependent types are not something you care about, so its quite obvious why you are only responding to a small preface section of the post, while dismissing the meat of it as "solving type-theoretical problems".

I assure you that dependent types, how to get there, are very important to a large number of people. An inaccurate preface doesn't take away from, or affect, this exercise.

I wish other readers reading this comment take time to read the bulk of the article, if they are interested in dependent types(or want to learn about it). It is very well written and explained, and it is not a comparative study of mainstream languages with Haskell, in case you get that impression from the other comments here.

> This is an explainabrag

My goal here was to show that standard Haskell boils down to a small set of features, therefore it's a simple language. Surely, "simple" does not imply "good" (Brainfuck is also simple), so I then assert that the combination of features that Haskell consists is fertile soil for writing maintainable and performant code.

> languages without these features can also have "clean, maintainable code"

Some people may prefer ML modules to type classes, sure. As to the other features, I have a hard time imagining a clean codebase in a language without some form of polymorphism, first class functions, and algebraic data types. (And lazy evaluation is a great addition to the list). Perhaps there are other sweet spots in the language design space, but I have not seen them yet.

> and nothing about this list implies "runs fast."

GHC is good at optimising this kind of code. https://stackoverflow.com/a/35038374

> Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?"

It's often hard to debug, and it means that the program can't be running for a long period of time. I suppose I should've used a better example, e.g. "use-after-free", to highlight the dangers of manual memory management.

> Haskell is particularly prone to "space leaks" due to its laziness.

Space leaks are benign compared to memory leaks in that the memory is eventually freed. That said, I'd be happy to have some sort of static analysis to prevent them.

> Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?"

Swift relies on automatic reference counting, which is similar to garbage collection in that it isn't done by the programmer and has a runtime performance cost. Remarkably, it seems to be worse on both accounts: the cost of decrementing/incrementing these counters is very real, and handling reference cycles is not automatic (you need to carefully use weak references).

Here's an interesting discussion of RC vs GC in context of .NET https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-m...

Rust, on the other hand, offers a static analysis with no runtime performance overhead to manage memory safely.

> dynamically typed languages with static type checking

You're talking about gradually typed languages. Sure, these are not unityped, but they also not purely dynamically typed (you said it yourself – they have static type checking). Perhaps that's just a difference between our uses of the term "dynamically typed" and we don't have a true disagreement here?

By the way, Haskell can do that too, we have the `Dynamic` type right in the `base` package.

> This read like a troll piece.

I'm sorry.

especially when "performant" means "11.5 average FPS when making a breakout game clone with 12 bricks on Android" https://www.youtube.com/watch?v=t5-dFlt7iyc

...

and being happy that it then can run at 450 fps on a desktop computer with non-negligible manual optimization work https://www.youtube.com/watch?v=PXxwYYNZhU8

The key difference with C++ templates is that in C++ you can't have a type parameterised by a value that's only know at runtime, e.g. a std::array where N is read from stdin. In a dependently typed language, you can. Object orientation is a different matter entirely; in the sense it implies Java-style class-based inheritance, it's almost in the opposite spirit to dependent types, as such late-binding (virtual methods) means it's possible to call methods such that the compiler has no idea which method will be called at compile time, making it hard to reason about the code at compile time.