It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.
There's cadmium there, yeah.
But cadmium is not addictive, and is not a reason for cigarettes being addictive.
Removing the cadmium will not make cigarettes less addictive.
Tobacco plants pull metals in from the soil, which includes cadmium, and radioisotopes of polonium and lead.
For simple languages, it can be a bit of a pain to write and maintain a lexer and a parser. For example, if I'm gonna parse JSON and nothing more, I think it's a bit silly to use a two external DSLs when I could use a simple eDSL. I think Happy and Alex both have their places, absolutely. For parsing full on programming languages I can imagine using parser combinators to be a bit painful. But parser combinators work great for a lot of cases.
I don't really think many people are calling it a panacea. From my experience in the community most people I know who write Haskell write it for productivity reasons (including me, I'd rather be using Idris 2 with algebraic effects though.)
I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case.
I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell.
And about interesting applications in Haskell, I'd consider https://hasura.io/ pretty interesting!
EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.
I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language.
Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you.
In my opinion, the only truly hard to read languages are languages that require you to keep large amounts of context in memory while reading a specific part of the codebase, be it due to lack of support for abstractions for proper encapsulation, messy overloading, insane inheritance hierarchies, or something else.
EDIT: Readability also requires you have a codebase that's well written, and even that's subjective.
Honestly, my main issues are with the lack of generics and the "dynamically typed effect system". The idea of a minimalist runtime and language reminds me of Clean a little bit.
I used to use CL quite a bit, but have since abandoned it for Haskell, so I'm a bit biased.
There's a number of issues with that:
- I'd be missing all the optimizations that can be performed due to purity.
- There's more to Haskell's type system than just vanilla Hindley-Milner, and the implementation of it isn't particularly trivial. https://github.com/stylewarning/coalton is the closest thing and it's still missing a large amount of the type system.
- Doing the implementation would be a significant amount of work to get it to integrate well with the language, and it would be a layer tightly glued on top instead of integrated with the language. I've seen many good DSLs embedded in lisp, but a type system is hard to embed in any language because it changes fundamental semantics of the language. Typed Racket is a massive project and it's lacking things like ADTs.
- A major part of Haskell is the standard library, a good chunk of the semantics of Haskell people use on a day to day basis, like monads and etc, are a part of the standard library.