After reading the article (BTW a good one), one thing intrigues me: why the author left Haskell for Lisp(s) ?
Like the other commenter I completely agree that knowing Haskell makes you a better programmer, and when I code in other languages I really miss certain parts of it. On the other hand, the entire Haskell ecosystem feels like a half-finished PhD thesis, and often-promoted libraries suffer from fundamental flaws which are "open research questions". There's a constant drive in many Haskellers to make their code as abstract, type-safe, and generic as possible, but unfortunately practicality and ease of use are often forgotten along the way.
It's a great language, but if you're trying to write production code which builds upon the wider ecosystem you're in for a world of pain. In 2024 Rust has probably rifled enough through Haskell's pockets to make it mostly irrelevant as anything but a testbed for programming language researchers.
(The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)
The "functional core, imperative shell" approach is -fantastic- though and I'm not sure where I picked it up from but a lot of my (especially async/event driven) code looks at least close to that.
It occurs to me that this may be why I've yet to be significantly bothered by function colouring when writing async/await based code in Perl and/or JS, but I'd probably have to give that more thought before I go beyond 'maybe' with that particular idea.
For a junior programmer, the benefit of such constraints is greater because they do need the compiler to tell them no. The benefit is somewhat reduced for senior programmers because experience leads them to naturally avoid things that a Haskell compiler would have yelled at them for.
I wrote Haskell for 10 years or so, both FOSS and professionally. I've "been around the block" so to speak and consider myself to have a decent view of the landscape. Overall, Rust lets me code in the style I want while being very resource efficient. I write Rust professionally.
I mean, if I left Haskell, I think the main reason would be to to shed the load of thinking simultaneously about laziness and how it interacts with optimization. OK, almost any non-Haskell language gets you out of that. But choosing to leave Haskell specifically for Rust would be about efficiency first and foremost, especially improving on the size and complexity of the RTS (and its limited platform support). I could also see wanting the concurrent programming benefits of Rust's ownership system. And it's nice to be able to write embedded or kernel code. And there's a bandwagon to jump on.
Lisp, on the other hand, doesn't really seem like an improvement over Haskell in any of those ways. It solves different problems. Lisp feels like it's on the "opposite side" of Haskell from Rust. So why did you "reverse" and try Lisp to begin with?
I agree that Rust is ugly, by the way. Honestly I think it started with keeping the C syntax and went from there.
I transitioned from Haskell to Rust to capture efficiency and small binaries. Since I'm in the game of shipping CLI tools, this was important for me.
You're right though that Lisp is on the other end of that; we're back to bigger runtimes with no tree-shaking, since that would hinder debugging. For now I'm experimenting with the Interactive Programming paradigm because the debugging story is just too good. For long-lived programs, this may be the way to go.
Rust code can be made nice to look at it, but it isn't the default nor the trend.