Hacker News Reader

Comment by _query | Hacker News Reader

Haskell is pretty nice for building web applications.

Thanks to it's type system you can build much more stable web apps in less time. Usually later in the application life cycle you have a hard time refactoring stuff when working with e.g. JS or rails. Without tests you will definitly break stuff. With haskell you can confidently refactor your code without worrying about breaking stuff, the compiler will tell you.

The way data structure are declared in haskell is also very nice for domain modeling. You don't have as much boilerplate as e.g. when using PHP with doctrine.

The performance is also pretty good compared to python or rails.

View on HN

Can you use it to write code that will be used (compiled) both server-side and client-side?

Because these days this is my bar for a language that is "nice for building web applications". I've gotten so much mileage out of Clojure+ClojureScript just because of this, it's not even funny.

You can, but it's... a bit messy unless you're using Nix as the build platform. Hopefully there will be a WASM backend for GHC... I mean, it's bound to happen right? :)

If you want statically checked types, I'd probably say that Scala is better at the server+client game (i.e. when you want to have both). Of course, Scala has its own drawbacks wrt. Haskell: lack of typed effects is a big one for me.

(Just for context: I work on a website+SPA written entirely in Scala which has been around for years and years. I also have quite a lot of experience in Haskell.)

> Scala has its own drawbacks wrt. Haskell: lack of typed effects is a big one for me.

There are libraries like ZIO, Cats Effect or Monix. Give them a try! Some people might even say that for example ZIO is even better than Haskell's IO.

Oh, I know about them. In fact, I'm trying to introduce ZIO in my Scala-mostly company. The problem is that a stray UUID.randomUUID() can destroy any and all guarantees. (We're already using Monix.)

That truly is the singular reason that I still prefer Haskell over Scala. I can get over syntax awkwardness, etc. etc. The impure-in-pure is... difficult when you can't just grep for unsafe*, etc.

EDIT: Fwiw, ZIO is definitely better than Haskell's IO. Better than RIO? Perhaps. Is it better than polysemy, tho? I don't think so. Btw, I know about polysemy's issues as well... hopefully lexi-lambda can get her GHC runtime changes merged so that we can have a true "free" effect system backed by a tailored runtime. Interestingly, Project Loom is also heading in a similar direction (first class continuations) on the JVM. Interesting times!

I'd pick elm for the frontend as it's kind of similiar to haskell syntax-wise but more optimized for the frontend context. Here's a great tutorial for this: https://driftercode.com/blog/ihp-with-elm/

I would like to humbly second this notion.

Especially since you can autogenerate Elm decoders based on Haskell types to reduce boilerplate and duplication between frontend and backend, while mostly retaining a strong sense of type safety.

You can also use Elm as an introduction language to new developers, without all of the complexity of haskell’s higher order abstractions, and then introduce them to haskell when they’re comfortable with elm.

(I did this with Servant as a backend, but IHP is wonderful as well!)

Yes, Haskell had ghcjs long before we even had wasm

For most web apps correctness is not the most important thing, this is why Python and PHP are/were so popular.

What is important is flexibility, Haskell's strict typing definitely impedes flexibility so I disagree with you that it's nice for building web apps.

The value of type safety is more that you're more productive because you can faster change things (as the compiler tells you what needs to be changed). This allows for faster iteration on your product.

Correctness is indeed not the most important thing, it's kind of a nice side effect.

Correctness is not the most important thing unless it is. Security bugs often stem from sloppiness and incorrectness. It depends on the use case.

You cannot create web applications without JavaScript these days. It does not matter what is your server side programming language, you need to send to the client JavaScript code to be executed in browser. And that in itself is a shitshow. End of story.

From another perspective you could say that JS is usually just a compile target these days, in many cases the source language is modern version of JS but in many other cases it's ClojureScript, TypeScript or something else.

Hmm. Time for a Haskell-to-Javascript compiler.

https://github.com/ghcjs/ghcjs

Empirically the evidence suggests all those languages without Haskells type system are doing fine considering that the vast majority of the software is not written in Haskell in its actually running.

Frankly hiring is just a way harder problem than building a Web app, and fixing JS, Java python or whatever engineers is significantly easier than finding reasonable Haskell engineers.

> the vast majority of the software is not written in Haskell in its actually running.

The vast majority of software has horrible domain and security bugs! I am not one of those people who complains about the bloated state of websites or app stores, but the vast majority of software is not “fine,” especially software written in Python or JavaScript.

Utter nonsense to imply that Haskell would suddenly fix bad security.

Haskell code can have security issues too hidden inside some too clever for it's on good language extension ridden Haskell code.

Too be honest I think there is likely only a handful of people like Ed Knett who actually grok and write effective Haskell code, and guess what he'd also write good C++ code as well.

I didn’t say Haskell would fix bad security! My point is that it’s nonsense to suggest that existing languages are “just fine.”

But many security bugs in C or C++ come down to sloppy types, sloppy pointers, or sloppy concurrency, all of which are almost impossible to do in Haskell. Haskell is not a replacement for C or C++ but its ideas are (and should be) influencing systems programmers.

I don’t actually like Haskell. But there is a reason why major organizations are considering Rust over C and C++: those languages are simply not sufficient for writing secure and robust software in the 21st century, and Rust has taken many of the “best parts” of Haskell to improve systems programming.

The vast majority of software is successful despite those bugs.

Reply on news.ycombinator.com