Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our Use of Haskell and Elm

sanityinc.com

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Our Use of Haskell and Elm

#31

Post by Tehnix »

scottcorgan wrote: post #22
salimmadjd wrote: post #6

Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…

You can follow along on the #elm-dev slack channel to know everything that's happening with the development with Elm. What 0.19 is going to include has been documented and made available to anyone that wants to know. A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :)

> A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :)

Instead you'll get a very big batch of breaking changes, that means the community will properly take a very long time to migrate to 0.19. Long release cycles are NOT a good thing.

Python 3 is the canonical example, but there are plenty of other times where too big a release brings about splits in communities.

Re: Our Use of Haskell and Elm

#33

Post by nine_k »

megaman22 wrote: post #16
antouank wrote: post #10

Earlier quoted context omitted.

Why is the pace of releases an important metric for using a programming language? Focus on code quality, and maintenance simplicity. If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality. Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example https://w…

The shiny is wearing off... But I agree, ideally, a tool isn't going to need a new version released every six weeks, if it is high quality and feature complete. But expectations are completely upside down in the web development world, so that rather than things becoming mature and stable, they are seen as stale and abandoned.

If there are no important outstanding bugs, are there any sorely missing features?

Does anything rot in the codebase as the JS in browsers (the target compilation platform) is constantly updated?

Re: Our Use of Haskell and Elm

#34

Post by eindiran »

Arubis wrote: post #18

I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.

From the article: "Both the Haskell and Elm code-bases are worked upon by multiple developers simultaneously."

Re: Our Use of Haskell and Elm

#35

Post by xtian »

antouank wrote: post #29
aeorgnoieang wrote: post #26

Earlier quoted context omitted.

If releases are the primary means by which bug fixes are distributed then a slow release pace means a slow pace at which bugs are fixed. Otherwise, I too enjoy the stability of using working tools that don't necessitate a lot of fast-paced changes.

Agreed. But the main thing to check first is : are there many bugs? Struggling to find any. On the other hand in js... I suppose it's more of a perception thing. We are used in js-based projects to have a lot of bugs as a given, so plenty of updates is a good thing.

Yes, there are bugs in Elm. Anyone who's worked on a production app will have run into issues with the compiler and/or first-party libraries, all of which are maintained by one person (as well as all of the official documentation, the package repo, CLI tooling, etc, etc). I'm a big fan of Elm in general, but I couldn't recommend it to someone unequivocally.

Re: Our Use of Haskell and Elm

#36

Post by scottcorgan »

Tehnix wrote: post #31
scottcorgan wrote: post #22

Earlier quoted context omitted.

You can follow along on the #elm-dev slack channel to know everything that's happening with the development with Elm. What 0.19 is going to include has been documented and made available to anyone that wants to know. A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :)

> A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :) Instead you'll get a very big batch of breaking changes, that means the community will properly take a very long time to migrate to 0.19. Long release cycles are NOT a good thing. Python 3 is the canonical example, but there are plenty of other times where too big a release brings about splits in communities.

Fair point. I think the Elm devs knew that, so they created https://github.com/avh4/elm-upgrade for the 0.17 to 0.18 upgrade. It's fixes _almost_ everything.

It will be updated for 0.19 as well!

Re: Our Use of Haskell and Elm

#37

Post by xtian »

nine_k wrote: post #33
megaman22 wrote: post #16

Earlier quoted context omitted.

The shiny is wearing off... But I agree, ideally, a tool isn't going to need a new version released every six weeks, if it is high quality and feature complete. But expectations are completely upside down in the web development world, so that rather than things becoming mature and stable, they are seen as stale and abandoned.

If there are no important outstanding bugs, are there any sorely missing features? Does anything rot in the codebase as the JS in browsers (the target compilation platform) is constantly updated?

There are both long outstanding bugs and sorely missing features in the currently released version.

Re: Our Use of Haskell and Elm

#38

Post by christophilus »

platz wrote: post #32

So, what does HN think of PureScript these days?

Can't speak for HN, but I really liked tinkering with it. If I remember correctly, its data structures were just basic JS data structures under the hood (e.g. JS arrays, objects, etc), which meant it didn't show the same perf benefits of a language that uses persistent data structures under the hood (e.g. Clojure, OCaml/Reason). I wonder if that has changed since I took a look.

Re: Our Use of Haskell and Elm

#39

Post by kepano »

platz wrote: post #32

So, what does HN think of PureScript these days?

We're active users of PureScript at Lumi (W15). We started experimenting with Haskell on the backend about two years ago and it was a huge success for many of the same reasons stated by the OP. We've now completely moved from Node to Haskell for our API. Since then we've continued to double down on type-driven development and bringing it to the frontend with PureScript made sense. It helps that Phil Freeman, its creator, is on our team :)

We've been dipping our toes into open-sourcing more PureScript libraries, such as our React bindings: https://github.com/lumihq

Re: Our Use of Haskell and Elm

#40

Post by platz »

christophilus wrote: post #38
platz wrote: post #32

So, what does HN think of PureScript these days?

Can't speak for HN, but I really liked tinkering with it. If I remember correctly, its data structures were just basic JS data structures under the hood (e.g. JS arrays, objects, etc), which meant it didn't show the same perf benefits of a language that uses persistent data structures under the hood (e.g. Clojure, OCaml/Reason). I wonder if that has changed since I took a look.

Cool you liked it - I recently had a similar experience replacing from JQuery froms with it.

It does by default it provide access to native JS data structures, but you don't have to use them e.g. there are persistent structures as well. https://pursuit.purescript.org/packages/purescript-ordered-c... though I don't quite understand the comment that persistent data structures are "slower" than native structures; I thought usually, it's the other way around.

Post reply on HN