Re:Haskell: The Bad Parts, part 2 (2020)
by Kototama on Tuesday February 09, 2021 @06:55PM
(#26084171)
PureScript would almost fit :-). It would just need a modern Haskell backend but having a strict language built on a lazy-one is probably not the best idea :-).
Re:Haskell: The Bad Parts, part 2 (2020)
by YawningAngel on Tuesday February 09, 2021 @07:09PM
(#26084284)
You can avoid lazy behaviour entirely in Haskell if you want to, so your purescript to haskell compiler can just only generate contrived haskell code that doesn't exhibit laziness
Re:Haskell: The Bad Parts, part 2 (2020)
by cies on Wednesday February 10, 2021 @03:33AM
(#26086803)
Idris maybe? If Idris has easy interop with the Rust ecosystem, we'd have a great backend (and with wasmer possibly also fontend) option.
Re:Haskell: The Bad Parts, part 2 (2020)
by Kototama on Thursday February 11, 2021 @06:06AM
(#26100277)
I was also thinking as Rust as a backend for a FP language in the last day. I found some Ocaml binding for Rust. It would be interesting to see how it fits.
or like Perl and the Raku Programming Language https://raku.org :-)
I personally love Haskell: I think it's in a great place as a language (even if it isn't wildly popular) and on a positive trajectory. But I definitely feel the same pain points Snoyman brings up, and maybe some others. (Template Haskell >.<) I don't see any way of fixing many of the biggest issues if we care about backwards-compatibility at all, and a language with 30 years of existing code can never get away from that. I also don't think te community could weather a Python 2 → 3 transformation (much less Perl 5 → 6). So the only path I see towards simultaneously keeping what's great about Haskell and improving all that isn't would be another language that can coexist simultaneously, just like Elixir and Erlang.