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.
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.
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 patch releases would be ideal. Though the version scheme of elm does not respect semantic versions. Which introduces another problem - unless you're "in the know" about elm, its difficult to even tell that the new release is going to break your code.
Otherwise, I too enjoy the stability of using working tools that don't necessitate a lot of fast-paced changes.
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.
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.
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.
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.
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:
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 and lines of code, then needing to rewrite it all.
I think what makes it even more unreliable, is lack of any communications. I think part of the problem is, Evan (the creator) probably is still not sure what this future looks like. He is very articulate, but not seeing any blog post update makes a reasonable person assume that this new release has not been fully conceived. So, everyone knows there will be a break change. But who knows what will break, when it will be released, etc.
On top of that, this new update has become a gatekeeper for bunch of pull requests and bugs on the existing system that is not being touched.
The people who sit next to Evan the author of Elm in Action and the biggest users of Elm (Richard Feldman) has pushed back the release of his book by one year. Basically the remaining part of his book, is all the SPA stuff that the version of Elm is supposed deal with. From what I've seen, it seems like even he doesn't know what to expect [0]
Put everything I mentioned together, it makes it hard to recommend Elm for anything your company will be depending on, especially when there are other solutions out there. Why take the risk.
Knowing just that there will be some changes, but having no information about he final scope or timeframe makes the decision much harder to take, and can just lead to leaving to the competing product / language / library / framework with more predictable timelines.
I don't understand what lets you come to your conclusion.
> Hi, I'm Steve Purcell - Sanity, Inc. is my one-man consultancy and software house.
https://github.com/dmjio/miso/blob/master/examples/todo-mvc/...
"We're not in Kansas anymore"
The other extensions don't seem to be used so it probably isn't as bad as it looks.
We've been dipping our toes into open-sourcing more PureScript libraries, such as our React bindings: https://github.com/lumihq
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.
A lot of them get posted on https://www.reddit.com/r/haskell/, which is fairly active, worth keeping an eye on it.
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 ).
That of course also means that the opposite is true for someone looking for a job—it's a lot harder to find something, so most trudge on, writing code in some language and then use Haskell in their spare time.
The last part usually also mean that the developers you find, as a company looking for someone, usually have a higher lower bar, by the very nature of having invested time into learning a niche language. Of course, that goes for most such cases as above, not that Haskellers are magically better programmers.
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.
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] :)
I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
