Haskell might be easy when you get the hang of it, but the vast majority of programmers haven't, and the language ideas are alien compared to the mainstream ones (Python, JS, C++, Lua).
The design of Haskell also encourages users to be very clever, which only makes code harder to read.
I have to write object-oriented bullshit all day for my job, if I started a fun new project like this I'd happily choose Haskell. If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.
I think this is an unfair and unnecessarily-snarky take.
My list of languages is fairly long these days. I’ve written php, ruby, and go in reasonable volume for mostly personal projects. I used to teach embedded C at uni. I write python professionally every day. Recently I’ve even started playing with rust (and had some success thanks to the awesome book). The list is far longer, these are just the ones used the most. I’ve been writing code in some capacity for the last 20 or so years (first self-taught, then at university, and more recently professionally full-time).
Despite all that, and not for lack of trying, for whatever reason purely functional languages are the only ones that elude me. Every couple of years I try Haskell or erlang again and I just get nowhere fast.
Maybe it’s because I was never very good at maths, maybe it’s because I haven’t had sufficient motivation, or maybe I just haven’t found the right monad blog post to convert me. All I know is Haskell remains chronically out of reach to many experienced and inexperienced devs alike.
That's because all of the languages you listed are really similar conceptually. PHP, Ruby, Go, C, and Python (and others you didn't list: Java, C++, C#, Perl, Lua, JavaScript) are far more similar to each other than they are to Haskell - they have different syntax and slightly different semantics, but for the most part they're all in the same language family. It's much easier to pick up Java after learning PHP than it is to learn programming for the first time - or, alternatively, to learn a structured language after having written unstructured BASIC for your whole life.
Lisp users (of which I am one) frequently talk about how all of those languages are "basically the same" - but for all that, Common Lisp is still way more similar to Python than it is to Haskell (which I've also tried and failed to learn).
Also, Haskell isn't just a functional language - it also is a lazy language, which means you have to now learn two new ways of thinking at once.
Erlang is similarly in a different world from the mainstream imperative-OO languages, but I don't think that being functional is the only thing that makes it hard to learn - it also has a fundamentally different model of concurrency (as well as being designed around concurrency) that is difficult to learn if you're just used to pthreads.
Similarly, I think that Prolog (logic programming), Adga (is it a programming language, or a theorem prover?), Rust (maybe; lifetimes), and Forth (stack programming) all present unique challenges to people like us that have only written Python/Ruby/Perl/Go/Lisp...
I hadn’t before considered the laziness part of Haskell, perhaps I simply hadn’t made it far enough to be aware of it before. Maybe that perspective will help me next time I feel the urge to try out fp again.
fwiw to your point about other languages, Rust has certainly presented a challenge due to new paradigms but it’s never felt insurmountable. The rust book is truly an incredible piece of writing that imo makes the language so much more accessible than it would otherwise be.
What you want is something that puts the movement of memory between processes and threads front-and-center. Half the difficulty of writing a 3D rendering engine is coming up with a good memory model for loading 3D models and textures to push them onto the GPU. That really sounds more like Rust's wheelhouse than Haskell.
I would pick Rust as well here but just because Haskell has exceptions and it has less emphasis on safety and less pleasant defaults than Rust. In order to get the Haskell I want I need several pragmas and a different prelude...
I would say Rust is pretty functional itself, though.
GC hasn't been an noticeable issue as a result.
What does it mean for the 3D environment to be inherently object-oriented?
Exactly how Haddock produces such wonderful automatic documentation, I don't know, but good God it does. The strict static types clearly help -- you can see exactly what every function inputs and outputs, what every data type needs, etc. And then you can jump to the definitions of any of those things, and if need be (almost never), the source code that defines them.
This is BS - find me some "clever" code in one of these Haskell projects and I bet it's not clever but simply using a set of abstractions there maintainers like and grok and the reader just doesn't understand.
What people call "clever" code in mainstream programming is not in any way similar to the Haskell being referred to.
Luckily in the Haskell world, we don't ascribe negative attributes like "cleverness" to code that isn't outsider-friendly. We gain a lot by not requiring that all our code is understandable by a mainstream programmer.
So users will probably be able to hack together what they want, but they may struggle to grow a large developer community. But that can still work out okay.
However, I think that purely functional languages are useful for basically everything. Haskell is my general purpose language of choice, unless libraries or system constraints force me to another language.
In other words, those problems that don't involve users and the outside world.
Pure languages for pure problems. Impure languages for impure problems. It computes.