His argument for why he dislikes Go and Javascript is ostensibly "they are easy to grok"...
I don't think this presentation was made out of ill-will or spite, but I think this presentation leaves little room for the mediocre; and frankly if a field is devoid of mediocre performers, you end up with a handful of gray-beards in a code cloister.
This is where, I think, the programmer mentality and the human empathy understanding are out of balance, and lead to false truths about how humans ought to behave.
I sorta like his point about contributing upstream, but again, I think that he neglects the fact that that isn't a straight-forward process to someone new to a language. He brings up that "the Rust community is welcoming", but (a) that doesn't really apply to most communities and (b) especially when you're just starting and haven't had too much exposure, you probably haven't witnessed (or realise you have witnessed) a bug in the 4 (often mature) standard libraries you regularly use.
My beliefs are getting seriously distorted in this thread.
That's not a fair characterization. While it was not elegantly posed, the argument was in essence "these languages optimize for ease of adoption instead of power". It's objectively true that go and javascript deliberately aren't able to do a bunch of things that a language like haskell can. Different choices were made. That doesn't mean that go and javascript have no place in programming, since we definitely need languages that are easy to get started in to on-board new people. However, the question is whether it's right that those languages then end up being people's choice for the rest of their professional career. A programmer is more likely to grow when using tools that enable growth.
On the other hand, while I haven't written haskell, I have written a bunch of scala and C++, and both suffer from an excess of syntax. In both cases skilled practitioners learn to ignore some of the language features, to ensure their own sanity when maintaining those code bases later on. There is something to be said about having a language that doesn't allow wizardry when viewed through the lens of maintainability. From what I understand that is go's design.
I like Chris, and he’s clearly a smart guy, but he’s not a person that pedagogical lessons should be learned from.
The book he wrote is a good example - and I enjoyed the book and recommend it. But it’s full of him using big words because at times he can, almost showing off, not because he should. I liked the book, and am glad he teaches the fundamentals of the lambda calculus, but it is very particular to Chris’s style, and that makes it the best programming book written in his eyes, despite not being the “best” programming book objectively.
I've no idea whether he thinks it's the only good Haskell book (do you have a reference for him claiming that?) but there is a sizeable segment of the Haskell community that considers it the best Haskell book. (I've never read it, personally.)
It would be surprising if it were otherwise given its origins and age.
I've been to a few meetups that Chris was present at and I have to say I was always somewhat surprised that he fancied himself a great teacher because I've found him to be impatient, condescending, and completely lacking empathy. I don't mean to say he's impossible to learn from (I am aware of people who site him as a reason they know some topic very well), just that in my experience teaching hundreds of people of varying skill levels he is not someone I would put in front of students.