Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

171–180 of 322 posts

Re: Pain Points of Haskell

#171
post #80

One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution. (I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that re…

Haskellers just tend to like Nix and NixOS I think. It's the sort of thing that once you learn it, you never bother going backwards.

Re: Pain Points of Haskell

#172

It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."

That's because Rob Pike never learned Haskell. Expecting to just look at it and know it because you know other languages is quite frankly silly!

You don't need to be a mathematician though. Many Haskellers I've worked with either didn't go to university or went for something else. I only ever learned C before Haskell, for instance.

Re: Pain Points of Haskell

#173
The complaint about records is interesting because there aren't that many major languages that actually do records well. For a language of its age, it actually does records rather well. People sometimes forget that Haskell is older than Java and like Java it has a ton of baggage from its early days.

The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using docker and hosting your own package mirror (as you should be for a professional deployment) it's perfectly serviceable.

Re: Pain Points of Haskell

#174
post #138

Earlier quoted context omitted.

I think the unreadability is a consequence of libraries defining their own infix operators left and right. E.g. according to hoogle >* Maybe this makes sense once you are very familiar with a library (like for example if you are a library dev), but if you are trying to learn a new library it makes for pretty much unreadable code.

One thing that irks me as someone who has dabbled in Haskell is not knowing how I should pronounce infix operators like or as I'm reading a line to myself.

I never read operators in my head, so the answer is "no pronunciation at all"

I'd say learning Haskell caused me to read code without using words.

Re: Pain Points of Haskell

#175

I personally don't understand the hangup on the existence of an IDE. Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language serv…

> I personally don't understand the hangup on the existence of an IDE.

I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg checkbox to run a lint every save). Lack of tooling (erlang and lua's lack of a comprehensive package manager comes to mind) stunts language maturity. It's a pain point.

Re: Pain Points of Haskell

#176

The complaint about records is interesting because there aren't that many major languages that actually do records well. For a language of its age, it actually does records rather well. People sometimes forget that Haskell is older than Java and like Java it has a ton of baggage from its early days. The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using dock…

And records will be a lot friendlier with RecordDotSyntax! :D

https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

Re: Pain Points of Haskell

#177

The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.

Incremental compiles in ghci are as fast or faster than my average incremental Go build turnaround. Once you include tests (which you need to run much more in Go than Haskell IME), Haskell begins to win even.

Re: Pain Points of Haskell

#178
post #102

Earlier quoted context omitted.

A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? Is it worthwhile to jump into Haskell now, or perhaps one should look into Idris or Agda? Any companies using Haskell where it has proven a distinct advantage? Ocaml and SML (the former being sadly quite unpopular these days) are an order of magnitude simpler than Haskell. They are easy to master. I have been quite…

I'm the CTO at Mercury ( https://mercury.com/ ) and we have 100% of our backend written in Haskell. It's gone really well so far. Answering another commenter's question, I would say the "secret weapons" are: 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. 2. Correc…

> 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup.

Although for engineers, supply-and-demand favoring employers typically means it disfavors employees: you may effectively be taking a pay cut to use Haskell compared to more popular languages.

Re: Pain Points of Haskell

#179
post #37

Earlier quoted context omitted.

I think Rust gives the symbols unique hashes for each crate version to avoid this. See this answer on Stack Overflow for more information: https://stackoverflow.com/a/51722134 - not sure if there is a better reference document though. You sometimes get weird errors like expected `A` but found `A` in the unusual event that you actually run into this, but this is probably something that could be fixed.

Thank you for the link, that clarified it for me. It seems that it requires compiler support to do it in the same way as Rust does it, but I like that approach better than complicating the package definitions with two types of dependencies. Reading that post also reminded me of the Unison language [1] which would even allow the same type from different versions of a library to be identified as the same if it wasn't a…

What's interesting is that GHC absolutely supports this already. If you manually link your projects you can use multiple versions of the same library in your project. Cabal doesn't support multiple versions of the same library.

Re: Pain Points of Haskell

#180
post #135
post #102

Earlier quoted context omitted.

A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? Is it worthwhile to jump into Haskell now, or perhaps one should look into Idris or Agda? Any companies using Haskell where it has proven a distinct advantage? Ocaml and SML (the former being sadly quite unpopular these days) are an order of magnitude simpler than Haskell. They are easy to master. I have been quite…

To answer your questions literally without much nuance: Yes, Haskell is viable for production. There are caveats, as with any other language. Haskell has more caveats that most other languages you would be familiar, but it's nonetheless perfectly suitable in the right environment. No, don't use Agda or Idris in production, they're totally unfit. Agda is not intended to be. Idris may be but it will take 5 or 10 years.…

Idris 2 is a big step towards a production grade FP language
Post reply on HN