Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

131–140 of 322 posts

Re: Pain Points of Haskell

#131
post #111
post #34

I would say all this is improving, and while these are all pain points, they are much less a pain point than they were just couple years ago. My personal ergonomics improved when I ditched standard prelude for classy-prelude. Regarding Strings, I just use Text type.

What is classy-prelude? Last time I coded something in Haskell (ages ago :() I didn't hear of this.

The first hit on Google will tell you :)

Re: Pain Points of Haskell

#132

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."

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.

Re: Pain Points of Haskell

#133
post #110
post #90

Earlier quoted context omitted.

Could you share what you mean by that, or how you got that impression? I've used Nix once, four years ago, and I didn't really like it[1]. I've never used it since. The only thing in the Haskell ecosystem that requires Nix is GHCJS, I think, which is bleeding edge technology that few use. Cabal's new package management style is called "Nix-style" but otherwise has no connection to Nix whatsoever (I wish they'd use a…

I guess my experience is colored by my last gig as a Haskell developer, where our entire development and deployment process was nix-based. I understand that it is possible to use Haskell without using Nix. However, I do get the impression that a significant section of the community see nix as the best way to manage Haskell dependencies. The (insanely confusing) naming of the new cabal features seems to support that.

Well, I don't know the details of your personal experience, but I'm confident to declare that the vast majority of the Haskell community has never used Nix and has no particular intention to.

Re: Pain Points of Haskell

#134
post #131
post #111

Earlier quoted context omitted.

What is classy-prelude? Last time I coded something in Haskell (ages ago :() I didn't hear of this.

The first hit on Google will tell you :)

Hehe, such a classy way of telling me lmgtfy :P You're right of course, and I've found out what it is.

Re: Pain Points of Haskell

#135
post #102
post #42

Earlier quoted context omitted.

> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…

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.

The only members of the ML family that I'm aware of are Ocaml and the flavours of Standard ML. Only Ocaml is fit for production.

Re: Pain Points of Haskell

#136
post #125
post #107

Earlier quoted context omitted.

> A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? It's viable for production and there are businesses which use it, notably fintechs. Also Facebook for some things (Facebook employs Simon Marlow [1]). And I know this is an irrelevant anecdote, but I have a friend who has been working in several startups which use Haskell for the last few years. Like Paul Graham h…

> Haskell really is a "secret weapon" and people who use it for production tend to love it That's exactly my question. I'd be really interested in hearing about domains where Haskell is a secret weapon and how it compares to ML family languages and dependently-typed ones.

https://news.ycombinator.com/item?id=23367803

Re: Pain Points of Haskell

#137
post #102
post #42

Earlier quoted context omitted.

> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…

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’ve used it on multiple projects for clients over the last 5 years. These projects were large, made it to production, and were successful. I love it. Once you clear the initial learning curve it feels very productive, and gives you the feeling of always having something more to learn and master.

Re: Pain Points of Haskell

#138

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."

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.

Re: Pain Points of Haskell

#139
post #17

The new improvements to Cabal have been super nice of late, but one thing I _really_ wish Cabal would do is allow for multiple versions of a library to be used in the same project. Having to satisfy a single library version is incredibly frustrating, and the solver errors are incredibly confusing. This is especially confusing when it complains about a library deep in your dependency graph being in conflict. Ultimatel…

I agree that this is a pain point. I not familiar with Cargo and would like to know how this actually works. Don't you risk binary incompatibility issues because the same symbols are occupied by different versions of the same package? For example, what if my package depends on A(v1.0) and B, B depends on A(v2.0), and furthermore B exposes a type from A(v2.0) in its API? Does the package manager distinguish internal d…

You might be interested in package-qualified import, for overlapping types and symbols: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: Pain Points of Haskell

#140
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’ve used it on multiple projects for clients over the last 5 years. These projects were large, made it to production, and were successful. I love it. Once you clear the initial learning curve it feels very productive, and gives you the feeling of always having something more to learn and master.

What domains?
Post reply on HN