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

51–60 of 68 posts

Re: Our Use of Haskell and Elm

#51

Post by skybrian »

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…

I think not using it is the right recommendation for people unwilling to pay code migration costs. Take Elm's pre-1.0 release version seriously and wait until it's ready.

However, as a lurker who likes to look at Elm development occasionally, I do it by looking for status updates on the developer mailing list:

https://groups.google.com/forum/m/#!forum/elm-dev

Re: Our Use of Haskell and Elm

#52

Post by hellofunk »

seanmcdirmid wrote: post #28
hellofunk wrote: post #12

Earlier quoted context omitted.

> any advantages Elm might have had initially, is coming to parity with other solutions. Absolutely. Elm filled a particular void in front-end development for a while, but much more mature, well-maintained, growing communities are now sprouting up that offer powerful statically-typed functional programming that transpiles to Javascript, all valid alternatives to Elm with far fewer risks. ReasonML probably being at th…

TypeScript is at the top of the list if you include unsound approaches.

Only problem there is that TS is still JS, with a lot of JS warts that bother many devs.

Other JS transpiling languages have entirely different semantics from JS altogether, which also make them attractive.

Re: Our Use of Haskell and Elm

#53

Post by Skinney »

salimmadjd wrote: post #14
Skinney wrote: post #7

Earlier quoted context omitted.

Why does it matter when the next release is coming, as long as the project is actively maintained?

That's a valid point. In this case, two reasons: 1 - active development is relevant. Is it being updated once a year, once a month. Is it going to take 1 year, 2 or 3 years. 2 - Above is not a deal breaker along. But, the new release is going to break stuff. you need to have ability to plan around things, especially as the new release will have paradigm shift (from what I'm gathering). You don't want to write lines a…

Every single version of Elm has had breaking changes. However, 0.17 -> 0.18 had an update tool that automatically fixed most of those changes, and a tool for that will be available for 0.19 as well.

NoRedInk (where Feldman works) are already updating a bunch of code to 0.19, according to Luke's talk at Elm Europe 2018, so they seem pretty sure of where things are going. Evan doesn't like announcing things until they are done though.

Re: Our Use of Haskell and Elm

#54

Post by Skinney »

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.

You'll get a small batch of breaking changes, most of them will be automatically fixed by the elm-upgrade tool. The community will probably migrate to 0.19 faster than 0.18 or 0.17, which both had much more breaking changes than 0.19.

Re: Our Use of Haskell and Elm

#55

Post by amarshall »

mebassett wrote: post #44
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…

my startup uses elm in production. There are plenty bugs with the current featureset in the elm compiler. The next version is going to break many things. This puts users of the platform in an awkward position where they have to put up with bugs for an indefinite amount of time, and when a release does come it is going to break a lot of code. this isn't something I'd expect in a "production ready" language. frequent p…

Regardless of whether it claims to adhere to SemVer, Elm hasn’t had a 1.0.0 release yet, and, as such, the following SemVer clause applies:

> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

That said, it’s reasonable to think that Elm should have had a 1.0.0 release by now.

Re: Our Use of Haskell and Elm

#56

Post by seanmcdirmid »

hellofunk wrote: post #52
seanmcdirmid wrote: post #28

Earlier quoted context omitted.

TypeScript is at the top of the list if you include unsound approaches.

Only problem there is that TS is still JS, with a lot of JS warts that bother many devs. Other JS transpiling languages have entirely different semantics from JS altogether, which also make them attractive.

That TS is basically JS with types is what makes it so popular.

Re: Our Use of Haskell and Elm

#57

Post by danharaj »

paidleaf wrote: post #17
specializeded wrote: post #3

They mention plentiful motivated job applications, how is the market from the perspective of a developer looking to focus on Haskell?

> They mention plentiful motivated job applications I'd take anything from an advocacy article with a grain of salt. > how is the market from the perspective of a developer looking to focus on Haskell? Considering the only response you got points you to a subreddit, I'm guessing it isn't so great. At best, it is a niche market ( though that could be lucrative ). I wouldn't put all my eggs in one basket. I'd make sure…

> Considering the only response you got points you to a subreddit

Funnily enough, a job posting was made on r/haskell since that comment was posted. It's not a bad space to watch for jobs.

Re: Our Use of Haskell and Elm

#58

Post by mebassett »

amarshall wrote: post #55
mebassett wrote: post #44

Earlier quoted context omitted.

my startup uses elm in production. There are plenty bugs with the current featureset in the elm compiler. The next version is going to break many things. This puts users of the platform in an awkward position where they have to put up with bugs for an indefinite amount of time, and when a release does come it is going to break a lot of code. this isn't something I'd expect in a "production ready" language. frequent p…

Regardless of whether it claims to adhere to SemVer, Elm hasn’t had a 1.0.0 release yet, and, as such, the following SemVer clause applies: > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. That said, it’s reasonable to think that Elm should have had a 1.0.0 release by now.

Apologies, I should have been more clear. I don’t know if elm /claims/ to adhere or not. I only know that in practice it doesn’t.

But thank you, that is an important point; elm’s own version numbers suggest it isn’t ready for production. Use at your own peril.

Re: Our Use of Haskell and Elm

#59

Post by latexr »

pyrale wrote: post #47
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.

We do the same in several teams of 5+ people, in a company having 3k employees. I don't understand what lets you come to your conclusion.

On the “About this site”, on the right, it says:

> Hi, I'm Steve Purcell - Sanity, Inc. is my one-man consultancy and software house.

Re: Our Use of Haskell and Elm

#60

Post by senorsmile »

haskman wrote: post #13
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…

If you want something that's (really) easy to get started with, and yet won't artificially constrain you from using your functional programming tricks as you evolve, I recommend trying out Concur [Haskell version]( https://github.com/ajnsit/concur ) or [Purescript version]( https://github.com/ajnsit/purescript-concur ). I wrote an initial introduction which also compares it with elm - https://github.com/ajnsit/concur…

This looks interesting. I will check out your project.
Post reply on HN