What I liked about this article is that rather than being a complete sales pitch it mentions the cons about adopting a language that is not used at mass scale. The biggest one being the ability to find and hire talent. They get around this challenge by being willing to train, which is reasonable. And refreshing to not see that real challenge swept under the carpet.
I've always thought that hiring i.e. haskell developers would be easier than for more widely used languages like java and python as I've assumed that the talent-to-jobs ratio would be a lot higher. I actually have no idea though.
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 companies.
The last release of Elm was 1 year and 8 months ago. The new release is purported to break many things. However, this new release is unknown, it's really unknown when it's going to be released and aside from a few insiders and contributors no one else seem to know what to expect.
Elm applies some interesting principles (type safety, purity, etc.) that helps to reason about your code. But, it's direction is driven by one person. That in itself is not bad, however, there is very little communication coming out of him (the last blog update by him was 1.5 years ago). Because of that, I started looking at Reason and what FB and others are doing.
I think it makes no sense to invest months or years into something like Elm at this point and any advantages Elm might have had initially, is coming to parity with other solutions.
I still think if you want to get your hands dirty with functional programming, play around with Elm. The Pragmatic Studio Elm lesson is great starting point. But look elsewhere for any serious projects.
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://www.youtube.com/watch?v=uGlzRt-FYto )
He addresses that concern that some people have, and why it has the pace it has.
As I understand it, it's better to do things right and take as long as it needs, rather than hurry and ship fancy things just to ship them.
Elm is perfectly production ready as is, and beats any JS stack for me. Both in code quality and maintenance cost.
What I've heard from Evan and others, is that Elm's timetable is modelled on Python's, which would mean (my estimations here) that they expect almost a decade of obscurity to give them room to tweak and generalise the language, before really expecting any kind of popularity (which might lock them into certain approaches).
Note that doesn't necessarily mean a long period of instability -- I think one of the reasons why they're taking it so slow at the moment is to see how to match tools like "elm-update" to seamless allow language upgrades. But it does mean that they're still in the phase of, for instance, removing language features rather than monotonically adding them, and trying to avoid dependencies on Javascript and the current Javascript ecosystem.
I also think that the burst of excitement around TEA and using Elm as a front-end web application tool was seen as an indicator that they were heading in the right direction, rather than an absolute flag that they should try to achieve dominance in that sector, or concentrate on it exclusively.
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! :)
> 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 the top of that list.
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:
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.
I’m assuming that the author is describing his experience working as a consultant for a software company with a larger team. The article explicitly refers to multiple programmers working on the code base.
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
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.
> 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 you have some expertise in Java, C#, C++, Python, etc ( don't forget SQL ) where there is a large established market that isn't going anywhere soon. But even more important, get experience in specific technologies ( databases , web servers, IDEs, version control, etc ).
GHCJS is a beast to bring in, and brings lots of complications with it. The build tools and environment around it is also not great, and most development tools that work for GHC break down for GHCJS.
That's not to say it can't be used, in fact a lot do quite successfully, but it is a BIG increase in complexity.
I'm more hopeful for approaches such as WebGHC[0] or perhaps more promising, Tweags Asterius[1] :)
tchaffee|7 years ago
borge|7 years ago
sanityinc|7 years ago
salimmadjd|7 years ago
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 companies.
The last release of Elm was 1 year and 8 months ago. The new release is purported to break many things. However, this new release is unknown, it's really unknown when it's going to be released and aside from a few insiders and contributors no one else seem to know what to expect.
Elm applies some interesting principles (type safety, purity, etc.) that helps to reason about your code. But, it's direction is driven by one person. That in itself is not bad, however, there is very little communication coming out of him (the last blog update by him was 1.5 years ago). Because of that, I started looking at Reason and what FB and others are doing.
I think it makes no sense to invest months or years into something like Elm at this point and any advantages Elm might have had initially, is coming to parity with other solutions.
I still think if you want to get your hands dirty with functional programming, play around with Elm. The Pragmatic Studio Elm lesson is great starting point. But look elsewhere for any serious projects.
antouank|7 years ago
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://www.youtube.com/watch?v=uGlzRt-FYto ) He addresses that concern that some people have, and why it has the pace it has.
As I understand it, it's better to do things right and take as long as it needs, rather than hurry and ship fancy things just to ship them.
Elm is perfectly production ready as is, and beats any JS stack for me. Both in code quality and maintenance cost.
dannyobrien|7 years ago
Note that doesn't necessarily mean a long period of instability -- I think one of the reasons why they're taking it so slow at the moment is to see how to match tools like "elm-update" to seamless allow language upgrades. But it does mean that they're still in the phase of, for instance, removing language features rather than monotonically adding them, and trying to avoid dependencies on Javascript and the current Javascript ecosystem.
I also think that the burst of excitement around TEA and using Elm as a front-end web application tool was seen as an indicator that they were heading in the right direction, rather than an absolute flag that they should try to achieve dominance in that sector, or concentrate on it exclusively.
haskman|7 years ago
scottcorgan|7 years ago
A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :)
hellofunk|7 years ago
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 the top of that list.
skybrian|7 years ago
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
Skinney|7 years ago
Arubis|7 years ago
klmr|7 years ago
aeorgnoieang|7 years ago
sanityinc|7 years ago
smt88|7 years ago
pyrale|7 years ago
I don't understand what lets you come to your conclusion.
eindiran|7 years ago
castlegloom|7 years ago
deathtrader666|7 years ago
[1] - https://haskell-miso.org/
frou_dh|7 years ago
https://github.com/dmjio/miso/blob/master/examples/todo-mvc/...
"We're not in Kansas anymore"
platz|7 years ago
kepano|7 years ago
We've been dipping our toes into open-sourcing more PureScript libraries, such as our React bindings: https://github.com/lumihq
christophilus|7 years ago
specializeded|7 years ago
Tehnix|7 years ago
A lot of them get posted on https://www.reddit.com/r/haskell/, which is fairly active, worth keeping an eye on it.
pmulv|7 years ago
paidleaf|7 years ago
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 you have some expertise in Java, C#, C++, Python, etc ( don't forget SQL ) where there is a large established market that isn't going anywhere soon. But even more important, get experience in specific technologies ( databases , web servers, IDEs, version control, etc ).
xfer|7 years ago
Tehnix|7 years ago
That's not to say it can't be used, in fact a lot do quite successfully, but it is a BIG increase in complexity.
I'm more hopeful for approaches such as WebGHC[0] or perhaps more promising, Tweags Asterius[1] :)
[0] https://webghc.github.io/roadmap
[1] https://github.com/tweag/asterius
sanityinc|7 years ago
pushpankar|7 years ago
I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
pyrale|7 years ago
unknown|7 years ago
[deleted]