I think his two-week setup time is due to choosing to use libraries and architecture he didn’t understand or worked with before (rebase, fused-effects). I make webapps in Haskell and it takes me 5-10 minutes to setup a project, since I already know what to do.

- “The ‘monad’ abstraction is excellent for dealing with code with a lot of failure conditions (ie. parsing) and avoids ‘pyramid of doom’ type code. Haskell worked out really well in this key area.”

- “Another strong positive for writing Deadpendency was testing. Haskell has a lesser-known style of testing libraries that do ‘property based testing’ (PBT).”

- “Haskell is very safe to refactor thanks to the type safety the compiler brings, which is probably the most important thing.”

- “My core Haskell had very few logic bugs. This is because Haskell is very safe by default and I had opted into strict types that help catch edge cases”

- “At this point I think it is actually pretty stable. I consider the project a big success. A huge part of this has been due to Haskell and its excellent ecosystem.”

It doesn't take 2 weeks to set up an app in a language with a big community of developers, well maintained libraries and at least decent documentation. It probably takes a day or 2. Maybe a bit more if you are venturing into a new ecosystem like switching from Java backends to a node.js backend.

I loved learning Haskell in university. It's an interesting language. I came into intro CS class thinking I could already program & the class would just be about sharpening my axe. Then my intro CS class started with Haskell which threw my brain for a loop and made me think about programming completely differently. That was a great intellectual experience and good for my long term thinking.

Haskell also seems like an incredibly impractical choice for a production language that only a stubborn purist would make. Of course the last bit is purely opinion, your experience may vary.

If you don't know the language and tools it definitely takes quite some time to setup Java, Maven, etc. All the issues with class paths, manifests, and so on, that are just completely alien and opaque coming from any other language make the experience very frustrating.

This. I think a lot of people who use mainstream languages forget what it's like starting from scratch in those languages. Getting a projects setup in Java, C++, C, Rust, etc are all quite difficult.

Getting a web application started in Ruby is easy because it does so much for you out of the box.

There are frameworks that make similar choices for you in Haskell as well: IHP, Yesod, etc.

I think taking two weeks to "set up" a Haskell project is a bit long but I read it as the author taking two weeks to learn enough Haskell to make two rather advanced libraries work together... which means they had to make all the little micro decisions that frameworks make for you, etc. With more experience that could've been done in less time.

If they had started with IHP I think it would've been your usual day or two.

Thanks for mentioning IHP. I've only read its landing page, but if what is has to say about itself is all true and from what is apparent looking at code samples, it definitely deserves to be on folks' radar!

It's enough to make Haskell really seem like a reasonable choice to "jump in with" without fear of never reaching some mundane goal.

Starting a very good starter project in Java/Kotlin is literally next->next->next while selecting what you want (frameworks, maven/gradle, jvm version, etc) in IntelliJ. And if you do not use IntelliJ you can use https://start.spring.io/ or other starter projects.

Starting a Haskell project with IntelliJ Idea is the same next->next->next [1]

[1] https://youtu.be/F0E0aV85GeQ?t=165s

Well, Haskell is too niche to have this...

And if I was new to Java, I wouldn't know which frameworks I wanted...

Javascript: webpack, gulp, sass, react, node, npm/yarn. The whole frontend ecosystem is consolidating but I would not consider this trivial. Experienced programmers coming into Javascript still stumble over these tools.

I think the first 5 minute experience is really good in React at this point.

  npx create-react-app foo-app
  cd foo-app
  yarn start

In ~2 minutes (10 if you had to install node/npm/npx), you have a hot-reloading live site to play with.

That doesn’t make React great nor solve all of the issues that lie between minute 1 and v0.1 in production, but the startup is smooth and painless (for me who comes from C/C++/C#/SQL, and my javascript is at a level where beginners can still help me).

The first 2-minute experience with a Haskell web service:

  curl -L https://nixos.org/nix/install | sh
  
  cat > ./script.sh <<EOF
  #! /usr/bin/env nix-shell
  #! nix-shell <nixpkgs> -i runghc -p "ghc.withPackages (x: [ x.yesod ])"
  {-# LANGUAGE ExtendedDefaultRules #-}
  {-# LANGUAGE OverloadedStrings    #-}
  {-# LANGUAGE QuasiQuotes          #-}
  {-# LANGUAGE TemplateHaskell      #-}
  {-# LANGUAGE TypeFamilies         #-}
  import Yesod
  
  data App = App
  
  mkYesod "App" [parseRoutes|
    / HomeR GET
  |]
  
  instance Yesod App
  
  getHomeR = return $ object ["msg" .= "Hello!"]
  port     = 3000
  
  main = warp port App
  EOF
  
  chmod +x ./script.sh
  
  ./script.sh

What intro cs class uses Haskell as its first language!

Imperial College London: http://wp.doc.ic.ac.uk/ajf/the-haskell-programming-course/

And several others listed here: https://wiki.haskell.org/Haskell_in_education

The first programming course at Edinburgh is the Haskell course, taught in the first year in the first semester.

Reed College

One of my favorite qualities of the Haskell community is how honest they are about the weaknesses of the ecosystem (we often discuss issues like these, e.g., on r/haskell or in mailing lists). These are legitimate concerns, but the fact that the author is happy with their decision despite these drawbacks is a testament to the language itself.

Good point, that's actually also what I sometimes notice. People complain about something, but still use it. I then think: I have to check it out!

Or as Bjarne Stroustrup worded it, "There are only two kinds of languages: the ones people complain about and the ones nobody uses"

And in fact very detailed criticism can be a good indication that the person is not some beginner frustrated with "that bad feature" but a developer who cares a lot about the technology but is also realistic about the things that aren't as good as they could be.

It has some truth but it brushes away any attempt at criticizing the C++ language and completely ignore that different languages have different level of satisfaction.

> BUT, if I want to build an actual app and try to earn money from it

Not the author, but my reading of his motivations was that the "challenging to learn, but extremely fun to write" part is way more important to them than the "best general purpose language". If your main motivation is to make as much money is as little time as possible then JS or Rails might get you off the ground sooner (although Haskell might catch up in the long run when the type system really starts paying off).

If you enjoy programming in Haskell and are looking to have a good time while building your startup, more power to you for using the language you like.

This is true. I really love Haskell but I can still get some prototype or small script up and running faster in Python.

But that speed flips once you have a larger system and need to maintain it.

With enough experience the speed flips around again. I often use Haskell to prototype things now instead of JS or Python because I don't have to deal with run-time type errors or undefined and the like. I can just write out the types, add some instances, compose things together and get feedback from the compiler if I'm on the right track. For me it's a much faster feedback loop than JS or Python.

It's not really about productivity in the language itself. It's more about the library ecosystem. Numpy and scipy are just so good and nothing really compares. I'm not skittish on writing the algorithm I need myself in Haskell. But when I'm prototyping and quickly trying stuff it's just so much faster if I can call a function and be done with it.

I still wonder about this. I'm competent enough at Haskell to have made several additions to GHC itself, though I readily admit I'm no SPJ. I also believe that for a general purpose program, Haskell _should_ be a good choice. But in practice I make mostly web apps and no amount of "write down the types then fill in the gaps and compose it all together" can replace the amount of scaffolding that things like Rails give me.

> - It is hard to get additional devs

Hey you just threw that in yourself. That's cheating! I think it's actually easy to get Haskell devs. I'm capable and I apply to every Haskell job. I never get hired so I imagine companies have no trouble finding other even more capable Haskell devs.

Sounds like the difference between the language vs the ecosystem.

Compare and contrast how happy are users of Java the language vs JVM the ecosystem (Clojure, Scala, Kotlin, etc).

With records, multi-line strings, and upcoming pattern matching + virtual threads, I hardly see any need to switch languages. I really enjoy working with Java and JVM ecosystem which is very vibrant and has a plethora of tools/libraries.

I'm happy when I'm productive and ship stuff. I'm unhappy when I have to struggle with obscure/undocumented libraries/tools.

I would totally pick Kotlin for my next project if we haven't invested into F# / .Net so much AND if we were not happy.

Actually Java the language is pretty ok nowadays. And taking into account mature ecosystem, libraries, jvm and IntelliJ IDE, Java is enjoyable to work with.

> But it is still somehow "the best general purpose language"?

Yes.

Yes.

We let some features and monads go and picked F# instead of Haskell.

>> It is an accomplishment if you get your basic project setupped in 2 weeks

More like two hours if you absolutely cluless.

- It is very hard to make popular libraries work together

Not an issue.

- 1/3 of the popular libraries are not well maintained, there are no docs and maintainers do not reply to PRs

Not an issue.

- It is hard to use latest GHC versions because of the previous problem

Not an issue.

- It is hard to get additional devs

Same. Few F# devs out there.

- Compile times are ok-ayish but can be a pain

Not an issue.

- There is no good IDE and refactoring

Not an issue (VS, VS Code, and a few dozen others)

I know it is not as strict as Haskell but we have really a good time so far.

I've definitely also found that getting a project nicely setup can be a challenge in Haskell. That said, I don't see that as a huge weakness from a "pick an ecosystem for writing a production app" point of view. 2 weeks is peanuts in the grand scheme of things and it's a task that you will likely be doing exactly once, so optimising for it has very diminishing returns.

That is only true if you know you're going to be working on something for a long time. But if you're taking the lean/fail fast approach, it isn't something you can know ahead of time.

I'm not sure where you got the second point from, certainly in my experience it hasn't been a bit issue with Haskell.

The third point is the same with just about every ecosystem in my experience, there are libraries written by big open source contributing companies which are completely dead as far as maintenance. I've even been bitten _this week_ by a JS library which is dead in the water.

For someone new to the language, pretty good I would say.