4 ms·

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

by jwr 6y ago

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.

jokethrowaway 6y ago
Yes, Haskell had ghcjs long before we even had wasm
Quekid5 6y ago
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.)
- sideeffffect 6y ago
  > 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.
  - Quekid5 6y ago
    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!
_query 6y ago
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/ https://driftercode.com/blog/ihp-with-elm/
- cannabis_sam 6y ago
  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!)

by jwr 6y ago

jokethrowaway 6y ago

Yes, Haskell had ghcjs long before we even had wasm

Quekid5 6y ago

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

sideeffffect 6y ago
> 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.
- Quekid5 6y ago
  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!

_query 6y ago

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/ https://driftercode.com/blog/ihp-with-elm/

cannabis_sam 6y ago
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!)