Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.

In my experience when exposed to dynamically typed languages, they will argue endlessly on "how bad they are". Also proponents of strongly type systems are often incapable of recognizing the drawbacks of such systems.

See for example https://github.com/fsharp/fslang-suggestions/issues/243#issu... for a critique that is never expressed by Haskellers.



Getting a bit precious about typing is IMHO a weakness of the Haskell community/mindset.

It’s not my favorite language, I’m a Lisp guy, but I stand by my assertion that a random sample from the Haskell population is a better bet on a hard problem than a random sample from the GraphQL population.


It seems fair. I have an hypothesis beyond the fact that it's a niche so self-motivated people are pre-selected: what somebody needs to learn Haskell are in good part applicable to computer science and programming languages whereas for JavaScript you need to learn the quirks and the specificity of the ecosystem first. The second experience does not translate very well to solving hard problems.


Sure thats like saying a random sample of 18 gear manual semi drivers are better drivers than an average suburban suburu dad driver, and … that makes sense!


I've worked with Haskell, OCaml and Erlang professionally. The other half of my career was spent mostly with some variants of C and Python. (I haven't contributed to GHC, though.)

I can get work done in dynamically typed languages without arguing all the time.

And from the point of view of eg Agda, Haskell itself is rather dynamically typed. It's all a continuum.

Of course, some languages are still better than others. And even the same language can get better or worse over time. For example, modern Python is much more palatable than Python used to be in the bad old days.


> See for example https://github.com/fsharp/fslang-suggestions/issues/243#issu...

See Rust traits to get an idea what happens if you 'just' implement type classes without proper support for higher kinded types ;)


I'm not that familiar with Rust at the moment, could you expand?


To use traits like you would type classes in Haskell, for example to define functors or monads in a general way, you need higher kinded types. Which can kind[oh, what a pun] of be implemented in Rust.

   So yes! You can use higher kinded types in rust. Whether you should I will
   leave up to you. But it certainly doesn't seem like a very attractive option 
   for most projects considering the syntactic noise of the implementation, a 
   typechecker that gets often confused and requires help, as well as error 
   messages that don't make much sense. Especially the last is a shame since 
   extremely helpful error messages is what rust is known for, and I 
   wholeheartedly agree (under normal circumstances).
https://hugopeters.me/posts/14/

   Yes, But Why, Really?
   Because sometimes one just gets homesick for Haskell and wants to implement
   the Functor hierarchy. You'll find this in the higher-cat crate. It's not 
   really very suited for writing good Rust code, but it makes Haskell 
   programmers feel happy and it has a lot of funny words.
https://docs.rs/higher/latest/higher/

A proposal for an addition to Rust, to get generic monads and (Haskell-like) do-notation for them:

https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in...


GP is referring to a Rust language feature called “traits” that is a quirky subset of a Haskell language feature called “type classes”.

Type classes are based on firmer theoretical footing (I think the original paper is called “Making Ad-Hoc Polymorphism Less Ad-Hoc”) and therefore run into fewer weird corner cases.

That’s not to say that Rust traits are “bad”, they’re useful and arguably cleaner than the C++ version of the idea (“concepts”), but a Haskell hacker writing Rust is liable to grumble now and again at the weird edge cases.


That link is very insightful and those reasons are why I stopped haskelling in my spare time.

Unfortunately pure FPs without typeclasses like Elm seem to be too boilerplatey for me.

F# may get around it by offering imperative and OO capabilities?

Overall I wanted to love pure FPs but I really appreciate Typescript and C# these days even though I tried with Haskell.

With Haskell you want to use a web library there are loads of programming language concepts that framework uses that you need to grok. With C# etc. you learn the language much quicker and libraries are way more “uniform” with nothing too fancy going on.


> for a critic that is never expressed

critique?


Thanks, corrected.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: