Our Use of Haskell and Elm(sanityinc.com)
sanityinc.com
Our Use of Haskell and Elm
https://www.sanityinc.com/articles/why-we-use-haskell-and-elm/
67 comments
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.
Author here - thanks very much. That was what I was going for.
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.
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.
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.
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 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.
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.
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.
> 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.
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.
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.
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.
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.
No one claimed it's perfect and bug free.
But let's compare it to any js stack with thousands of libraries in the project's `node_modules` directory, written by thousands different contributors.
That's what Elm is replacing.
You did claim that you were “struggling to find any” bugs in Elm. There are definitely a lot of bugs in the JS ecosystem, but one should also compare the avenues for remediating bugs in that ecosystem versus Elm (easier to fork/patch buggy code, more frequent bugfixes, more alternatives, etc).
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.
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?
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.
You keep claiming that without providing any links.
Care to post links to bugs/features you miss?
My best reference for links would be the Slack logs from the job where I was using Elm full-time, but I'm not at that job anymore. If you're interested I would recommend trawling the issue trackers for the elm and elm-lang GitHub orgs as well as checking out the Elm subreddit and Discourse. Threads which discuss the limitations of the way the project currently operates or native JS workarounds to issues are often locked or moderated on those forums, however.
Off the top of my head, a couple of the compiler issues we worked around were case statements on a tuple causing non-linear increases in compilation time and the compiler hanging indefinitely when trying to infer certain types from our GraphQL library (which is an awesome lib; check out dillonkearns/graphqelm if you want to see Elm at its most useful). We also ran into a case rendering live-updating graphs where Elm would stack overflow after a certain number of internal messages.
As far as features, only a small portion of browser functionality is available in Elm and many of the integrations that do exist are not as complete as you might expect coming from another ecosystem. For instance the only way to do SPA navigation is to add explicit click event bindings and message handlers for every link. The port-based JS interop functionality is great for many use-cases, but we found it pretty awkward for others. A couple of these cases were blob file uploads and calling + reacting to `window.confirm`. The JS code additions to enable these features within Elm are very simple, but third-party libs can't include JS and it's unlikely to get a PR acknowledged much less accepted to anything first-party, so people end up hacking together their own fixes for lots of little issues in isolation. And the ability to do JS workarounds is apparently being curtailed even further in the upcoming release.
Some of the issues we had will be fixed with the release of 0.19 (namely, the compilation time issues and the SPA nav), but those fixes come along with a slew of breaking changes and after nearly two years since the last release. Information about the contents and development of that version has only started coming out in a meaningful way in the last couple of months. Up until that point it was basically rumor and hearsay, and we spent a lot of time wondering how we would justify to the rest of the company having made a big commitment to a seemingly abandoned language.
Overall I have fairly nuanced feelings about Elm which are difficult to communicate in this context. It's one of my favorite languages and I often feel very productive using it. I think it's an great achievement as a piece of technology and I agree with almost all of the design tradeoffs it makes. But I think if the project is meant to be used in serious contexts — a question which I should not even have to wonder about — then it has grown beyond the scope that one person can manage on their own. Evan has actively resisted enlisting and empowering the community to help realize his vision for the project and solve their own problems, and I think there is plenty of evidence that that is a worthwhile and feasible goal. Elixir is my go-to example for a project that does a great job at this and has benefited significantly from it.
Off the top of my head, a couple of the compiler issues we worked around were case statements on a tuple causing non-linear increases in compilation time and the compiler hanging indefinitely when trying to infer certain types from our GraphQL library (which is an awesome lib; check out dillonkearns/graphqelm if you want to see Elm at its most useful). We also ran into a case rendering live-updating graphs where Elm would stack overflow after a certain number of internal messages.
As far as features, only a small portion of browser functionality is available in Elm and many of the integrations that do exist are not as complete as you might expect coming from another ecosystem. For instance the only way to do SPA navigation is to add explicit click event bindings and message handlers for every link. The port-based JS interop functionality is great for many use-cases, but we found it pretty awkward for others. A couple of these cases were blob file uploads and calling + reacting to `window.confirm`. The JS code additions to enable these features within Elm are very simple, but third-party libs can't include JS and it's unlikely to get a PR acknowledged much less accepted to anything first-party, so people end up hacking together their own fixes for lots of little issues in isolation. And the ability to do JS workarounds is apparently being curtailed even further in the upcoming release.
Some of the issues we had will be fixed with the release of 0.19 (namely, the compilation time issues and the SPA nav), but those fixes come along with a slew of breaking changes and after nearly two years since the last release. Information about the contents and development of that version has only started coming out in a meaningful way in the last couple of months. Up until that point it was basically rumor and hearsay, and we spent a lot of time wondering how we would justify to the rest of the company having made a big commitment to a seemingly abandoned language.
Overall I have fairly nuanced feelings about Elm which are difficult to communicate in this context. It's one of my favorite languages and I often feel very productive using it. I think it's an great achievement as a piece of technology and I agree with almost all of the design tradeoffs it makes. But I think if the project is meant to be used in serious contexts — a question which I should not even have to wonder about — then it has grown beyond the scope that one person can manage on their own. Evan has actively resisted enlisting and empowering the community to help realize his vision for the project and solve their own problems, and I think there is plenty of evidence that that is a worthwhile and feasible goal. Elixir is my go-to example for a project that does a great job at this and has benefited significantly from it.
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.
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.
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
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
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 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.
[0] https://www.manning.com/books/elm-in-action
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.
[0] https://www.manning.com/books/elm-in-action
I bought that book 2 years ago, I've since stopped using Elm. It's pretty bad that it still hasn't been released yet.
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.
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.
Because Elm is still a young language that hasn't found a solid footing that operates as a core philosophy, and usability issues and other concerns go unanswered or ignored for years at a time. When a language is very opinionated, and those opinions change, it creates a stability issue, and active releases and engagement with users help mitigate loss of confidence.
It matters for planning. If I knew when the new release is coming, and which features it brings, then I can decide whether I use the current stable version, and upgrade later if required, or just use the beta version during the development knowing it will go live in time for my go live.
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.
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.
Elm doesn't need to be merely maintained, it needs to grow and evolve.
Good point. Spare a thought for anyone who's gone through the various releases of Angular in the last 18 months. The other points may be valid though...
> 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.
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.
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.
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.
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-documentation/blob/master/R....
This looks interesting. I will check out your project.
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! :)
> 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.
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.
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!
It will be updated for 0.19 as well!
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.
I'm guessing he's working with other people; a "team" perhaps. Consultants are, sometimes, hired to work for or with companies; even for long periods!
Author here. The blog is for my personal brand, because I often work independently, but I was employed full-time as lead architect for this venture.
He seems to do contract work with teams. The bio might be old.
From the article: "Both the Haskell and Elm code-bases are worked upon by multiple developers simultaneously."
the use of "our" threw me off a bunch, unless they're referring to clients
Check out Miso [1] a frontend framework built in Haskell.
[1] - https://haskell-miso.org/
[1] - https://haskell-miso.org/
I look at the opening stanza of the first example:
https://github.com/dmjio/miso/blob/master/examples/todo-mvc/...
"We're not in Kansas anymore"
https://github.com/dmjio/miso/blob/master/examples/todo-mvc/...
"We're not in Kansas anymore"
RecordWildCards and DeriveGeneric are clearly used but fairly basic. OverloadedStrings seems to be used for MisoString.
The other extensions don't seem to be used so it probably isn't as bad as it looks.
The other extensions don't seem to be used so it probably isn't as bad as it looks.
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.
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.
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
We've been dipping our toes into open-sourcing more PureScript libraries, such as our React bindings: https://github.com/lumihq
They mention plentiful motivated job applications, how is the market from the perspective of a developer looking to focus on Haskell?
There are more and more jobs coming up, some remote and some not.
A lot of them get posted on https://www.reddit.com/r/haskell/, which is fairly active, worth keeping an eye on it.
A lot of them get posted on https://www.reddit.com/r/haskell/, which is fairly active, worth keeping an eye on it.
Just as some anecdata, I know of a single developer who works with Haskell; they do fluid dynamics programming for ExxonMobil in Houston.
> 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 ).
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 ).
There are two sides to the coin. It is a LOT easier to hire for a Haskell developer, because the pool of jobs is so small compared to the amount of people that would like to work with Haskell in their daily life.
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.
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.
Why are they not using ghcjs? Wouldn't that work nicely with their existing infrastucture and codebase?
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] :)
[0] https://webghc.github.io/roadmap
[1] https://github.com/tweag/asterius
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
Author here. I answered this and other questions in discussions on Reddit: https://www.reddit.com/r/haskell/comments/8ye1h0/explaining_...
> "Haskell has excellent libraries for integrating with databases and web services, and for building API services."
I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
What libraries did you use, and which problems did you encounter ?
[deleted]