Stack 0.1 – A new build tool for Haskell(fpcomplete.com)
fpcomplete.com
Stack 0.1 – A new build tool for Haskell
https://www.fpcomplete.com/blog/2015/06/stack-0-1-release
55 comments
> I totally see how this language and it's ecosystem are going to be the next big thing in programming.
I agree and it seems like 2015 has seen a substantial increase in interest in Haskell. The NY Haskell meetup group has seen a steadily increasing number of group joins this year. Both of the last two months have had a record number of new signups and have been more than double the median. I don't know what is causing the increased interest, but it's clearly not an isolated spike.
I agree and it seems like 2015 has seen a substantial increase in interest in Haskell. The NY Haskell meetup group has seen a steadily increasing number of group joins this year. Both of the last two months have had a record number of new signups and have been more than double the median. I don't know what is causing the increased interest, but it's clearly not an isolated spike.
We've seen big growth and interest in the Chicago Haskell group as well.
We've seen big growth and interest in the Chicago Haskell group as well.
I'll support Luke's claim. We've had over 30 people for the last two meetups (in March and May). There's a lot of interest in the next Meetup (July or August, depending on speaker availability).
I'm also planning to do a beginner Haskell class (assuming programming experience, but no Haskell experience) in Chicago around November over a couple of weekends. I'm writing a summer class that my company will use, and I'm planning to convert that to a weekend workshop (probably 2 weekends, realistically) in the fall.
I'll support Luke's claim. We've had over 30 people for the last two meetups (in March and May). There's a lot of interest in the next Meetup (July or August, depending on speaker availability).
I'm also planning to do a beginner Haskell class (assuming programming experience, but no Haskell experience) in Chicago around November over a couple of weekends. I'm writing a summer class that my company will use, and I'm planning to convert that to a weekend workshop (probably 2 weekends, realistically) in the fall.
Very much thanks to your efforts, Michael!
Also the http://reddit.com/r/haskell increased a lot over the last few years.
Could you explain this a little more? What new build tooling has been developed for Haskell recently (other than the parent link)?
One of the things that keeps me from revisiting Haskell was the aforementioned subpar build tooling. That's one of the reasons I'm enjoying Golang so much.
One of the things that keeps me from revisiting Haskell was the aforementioned subpar build tooling. That's one of the reasons I'm enjoying Golang so much.
Sure...
Stackage: curated sets of packages that are known to work together.
LTS Haskell: Stackage + pinning to a GHC version + seperating non-breaking upgrades (minor LTS version increases) from breaking ones (major increases).
SSL downloading.
Stack: also downloading/building of GHC if it does not exists, understands mega-repo's (many packages in one git repo), eases working with shared local pools of packages, eases working with dependencies that are not in Stackage/LTS, and more that I probably forget.
A more detailed explanation of the merits of Stack can be found in this video: http://begriffs.com/posts/2015-06-22-haskell-stack-build-too...
Stackage: curated sets of packages that are known to work together.
LTS Haskell: Stackage + pinning to a GHC version + seperating non-breaking upgrades (minor LTS version increases) from breaking ones (major increases).
SSL downloading.
Stack: also downloading/building of GHC if it does not exists, understands mega-repo's (many packages in one git repo), eases working with shared local pools of packages, eases working with dependencies that are not in Stackage/LTS, and more that I probably forget.
A more detailed explanation of the merits of Stack can be found in this video: http://begriffs.com/posts/2015-06-22-haskell-stack-build-too...
So basically everything that's been available on the JVM for more than ten years.
I understand your excitement to finally have that if you didn't beforehand, but this is pretty old stuff.
I understand your excitement to finally have that if you didn't beforehand, but this is pretty old stuff.
What about that has the JVM had for years?
Isn't that all basic stuff SBT did for years already?
What is SBT?
But yes, these are all table stakes that Haskell has been lagging on, in part because Haskell library versions break compatibility very frequently, and Haskell has a very non-local/modular way of building source.
But yes, these are all table stakes that Haskell has been lagging on, in part because Haskell library versions break compatibility very frequently, and Haskell has a very non-local/modular way of building source.
SBT is the Scala build tool (hence the name, I guess) if I recall correctly.
'cabal sandbox' came out like, a year ago? That was a huge improvement for my Haskell development experience, allowing local isolated environments like you get from npm or virtualenv.
> It is a hell of a secret weapon for startups.
So secret that hardly any startups use it and hardly anyone has open positions for Haskell jobs...
You have your work cut out for you :-)
So secret that hardly any startups use it and hardly anyone has open positions for Haskell jobs...
You have your work cut out for you :-)
JP Morgan [1], Standard Chartered [2], Skedge.me [3], Soostone [4], and Facebook [5] have all advertised open Haskell positions recently. And those are just the ones that come to mind immediately.
[1] https://mail.haskell.org/pipermail/haskell-cafe/2015-June/12...
[2] https://donsbot.wordpress.com/2015/06/10/haskell-dev-role-in...
[3] http://www.reddit.com/r/haskell/comments/32ydm7/haskell_jobs...
[4] https://news.ycombinator.com/item?id=9473292
[5] http://www.reddit.com/r/haskell/comments/2useoq/haskell_oppo...
[1] https://mail.haskell.org/pipermail/haskell-cafe/2015-June/12...
[2] https://donsbot.wordpress.com/2015/06/10/haskell-dev-role-in...
[3] http://www.reddit.com/r/haskell/comments/32ydm7/haskell_jobs...
[4] https://news.ycombinator.com/item?id=9473292
[5] http://www.reddit.com/r/haskell/comments/2useoq/haskell_oppo...
This is exciting news but the company you mentioned do not really qualify as "startups" though.
A couple of them mentioned here just for the Bay: http://www.wagonhq.com/blog/bayhac . Hope we still qualify as a startup!
Damn, this blog is so cool. Also, I share your excitement for the post cabal-install world :-)
Thank you for sharing!
Thank you for sharing!
JanRain, Silk, Wagon, Better, Bump, Fynder, Hasura, and more.
https://wiki.haskell.org/Haskell_in_industry
I expect some may keep it a secret, as it might give them some competitive advantage.
https://wiki.haskell.org/Haskell_in_industry
I expect some may keep it a secret, as it might give them some competitive advantage.
I didn't say "no one". Any company big enough will have open positions for pretty much any imaginable language or technology out there.
But picking Haskell as a start up is suicidal.
But picking Haskell as a start up is suicidal.
> But picking Haskell as a start up is suicidal.
Can you please list a few of the biggest reasons why?
In addition, aren't you aware there have been quite a few Haskell based startups?
Additionally, do you actually know Haskell and have you used it any substantial project/capacity?
Can you please list a few of the biggest reasons why?
In addition, aren't you aware there have been quite a few Haskell based startups?
Additionally, do you actually know Haskell and have you used it any substantial project/capacity?
> Can you please list a few of the biggest reasons why?
The main problem is the difficulty to hire Haskell programmers. Recruiting is crucial to a startup's success.
Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal) and moving very slowly (interfacing to NoSQL or AWS, etc...).
Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community.
The main problem is the difficulty to hire Haskell programmers. Recruiting is crucial to a startup's success.
Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal) and moving very slowly (interfacing to NoSQL or AWS, etc...).
Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community.
"The main problem is the difficulty to hire Haskell programmers."
That does not match my experience. I posted a Haskell position, promising to pay substantially below market rate with no hope of equity, and had a dozen or so applicants that seemed worthwhile (and a handful that really stood out, one of which turned into the hire).
"Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal)"
IME, pip is worse and Python seems a go-to choice for startups.
"Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community."
Something like 99.9999% of the developer community isn't going to be working at your startup regardless.
That does not match my experience. I posted a Haskell position, promising to pay substantially below market rate with no hope of equity, and had a dozen or so applicants that seemed worthwhile (and a handful that really stood out, one of which turned into the hire).
"Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal)"
IME, pip is worse and Python seems a go-to choice for startups.
"Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community."
Something like 99.9999% of the developer community isn't going to be working at your startup regardless.
The main problem is the difficulty to hire Haskell programmers. Recruiting is crucial to a startup's success.
"We were pleased to get a total of 42 applications, of which 19 merited serious consideration, and we eventually settled on a shortlist of 7 to interview. " [0]
Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal) and moving very slowly (interfacing to NoSQL or AWS, etc...).
> looking at you cabal
See this link for a solution: https://news.ycombinator.com/item?id=9766943
> interfacing to NoSQL
I recently used the Haskell riak[3] binding in my day job for an application. The mongoDB[4] package was uploaded "Tue Jan 19 06:04:06 UTC 2010"[5]
> AWS
There has been an AWS binding since 2011[1][2].
> etc
cassandra[6][7][8]
couchdb[9]
> Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community.
A 10 year old can do it[9], so I'm sure more than 5% of the developer community can as well!
I wouldn't say I'm a spectacular programmer and I have both learned Haskell and used it in the real world easily enough. I will admit in the past there was a learning issue, but actions to make Haskell easier to learn have (and continue) to happen.[11][12][13][14]
I'm looking forward to any rebuttals you may have to these! :)
0: http://www.well-typed.com/blog/2010/08/on-hiring-haskell-peo...
1: http://hackage.haskell.org/package/aws-0.0.1
2: http://hackage.haskell.org/package/aws
3: http://hackage.haskell.org/package/riak
4: http://hackage.haskell.org/package/mongoDB
5: http://hackage.haskell.org/package/mongoDB-0.1
6: http://hackage.haskell.org/package/cassandra-thrift
7: http://hackage.haskell.org/package/hscassandra
8: http://hackage.haskell.org/package/cassy
9: http://hackage.haskell.org/packages/search?terms=couchdb
10: https://superginbaby.wordpress.com/2015/04/08/teaching-haske...
11: https://github.com/bitemyapp/learnhaskell
12: http://haskellbook.com/
13: http://www.amazon.com/Beginning-Haskell-A-Project-Based-Appr...
14: https://en.m.wikibooks.org/wiki/Haskell
"We were pleased to get a total of 42 applications, of which 19 merited serious consideration, and we eventually settled on a shortlist of 7 to interview. " [0]
Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal) and moving very slowly (interfacing to NoSQL or AWS, etc...).
> looking at you cabal
See this link for a solution: https://news.ycombinator.com/item?id=9766943
> interfacing to NoSQL
I recently used the Haskell riak[3] binding in my day job for an application. The mongoDB[4] package was uploaded "Tue Jan 19 06:04:06 UTC 2010"[5]
> AWS
There has been an AWS binding since 2011[1][2].
> etc
cassandra[6][7][8]
couchdb[9]
> Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community.
A 10 year old can do it[9], so I'm sure more than 5% of the developer community can as well!
I wouldn't say I'm a spectacular programmer and I have both learned Haskell and used it in the real world easily enough. I will admit in the past there was a learning issue, but actions to make Haskell easier to learn have (and continue) to happen.[11][12][13][14]
I'm looking forward to any rebuttals you may have to these! :)
0: http://www.well-typed.com/blog/2010/08/on-hiring-haskell-peo...
1: http://hackage.haskell.org/package/aws-0.0.1
2: http://hackage.haskell.org/package/aws
3: http://hackage.haskell.org/package/riak
4: http://hackage.haskell.org/package/mongoDB
5: http://hackage.haskell.org/package/mongoDB-0.1
6: http://hackage.haskell.org/package/cassandra-thrift
7: http://hackage.haskell.org/package/hscassandra
8: http://hackage.haskell.org/package/cassy
9: http://hackage.haskell.org/packages/search?terms=couchdb
10: https://superginbaby.wordpress.com/2015/04/08/teaching-haske...
11: https://github.com/bitemyapp/learnhaskell
12: http://haskellbook.com/
13: http://www.amazon.com/Beginning-Haskell-A-Project-Based-Appr...
14: https://en.m.wikibooks.org/wiki/Haskell
Are there really that many cases of startups saying "oh man, had we only picked tool x instead of tool y, we wouldn't have been dead by now" ?
I've seen startups killed by New Guy CTO Who Really Likes Java.
It's rarely a tool that kills a company, though. It's an attitude. It's not the tool's fault. If you use some Java (perhaps you need to be on the JVM, because you're doing Android development or because an external client wants Jars) but allow the better engineers to work in Clojure or Scala, you'll be fine. If you hire the New Guy CTO Who Really Likes Java and people are punished for using high-productivity languages, then you're fucked. (<whine>"How are we going to hire Clojure engineers?"</whine> "Train internal talent up to it, dumbass.") But you'd probably be fucked if you had that same guy and he was fixated on a different platform or language. It isn't Java's fault.
It's similar to the debate about Agile/Scrotum, in which defenders of these methodologies blame imperfect people for the messes that these processes often create. The Agile Manifesto is pretty reasonable, all considered. But the sorts of people who will impose Agile from the top down, as a justification for aggressive micromanagement and age discrimination (cf. the terminal juniority of a culture where even senior engineers submit to time tracking)... are also the sorts of people who will destroy your company if they ever get to make decisions that actually affect other people.
As for Haskell... I've never met anyone who regretted using it. Of about 20 cases where people put it into production, I've never heard of anyone regretting it. (I have heard regret stories about Scala, especially regarding the build chain circa 2011-13, though it may have improved.) There is one case where that company moved to F#, but it wasn't Haskell's fault so much as a standardization around the Microsoft stack.
It's rarely a tool that kills a company, though. It's an attitude. It's not the tool's fault. If you use some Java (perhaps you need to be on the JVM, because you're doing Android development or because an external client wants Jars) but allow the better engineers to work in Clojure or Scala, you'll be fine. If you hire the New Guy CTO Who Really Likes Java and people are punished for using high-productivity languages, then you're fucked. (<whine>"How are we going to hire Clojure engineers?"</whine> "Train internal talent up to it, dumbass.") But you'd probably be fucked if you had that same guy and he was fixated on a different platform or language. It isn't Java's fault.
It's similar to the debate about Agile/Scrotum, in which defenders of these methodologies blame imperfect people for the messes that these processes often create. The Agile Manifesto is pretty reasonable, all considered. But the sorts of people who will impose Agile from the top down, as a justification for aggressive micromanagement and age discrimination (cf. the terminal juniority of a culture where even senior engineers submit to time tracking)... are also the sorts of people who will destroy your company if they ever get to make decisions that actually affect other people.
As for Haskell... I've never met anyone who regretted using it. Of about 20 cases where people put it into production, I've never heard of anyone regretting it. (I have heard regret stories about Scala, especially regarding the build chain circa 2011-13, though it may have improved.) There is one case where that company moved to F#, but it wasn't Haskell's fault so much as a standardization around the Microsoft stack.
>> Train internal talent up to it, dumbass.
Train an X programmer on Y, and you'll most likely get Y written as X for quiet some time, until they gain experience, if ever.
The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete. Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue. I'd use SML if I could.
Train an X programmer on Y, and you'll most likely get Y written as X for quiet some time, until they gain experience, if ever.
The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete. Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue. I'd use SML if I could.
Train an X programmer on Y, and you'll most likely get Y written as X for quiet some time, until they gain experience, if ever.
Most companies are run by short-sighted mediocrities who don't look more than 3 months into the future. I think longer term. In the long term, the transition is worth it. The benefits of moving from Java to Haskell or Clojure, say, are worth a few months of struggling and first-time code. If you have half-decent programmers and a culture that allows people to take time to learn how to do things right, that pays itself off within the year.
The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete.
That's not really true. If you need strictness, you can force evaluation and you don't need to use monads. I'm writing a Haskell class and I cover `seq` before I tackle monads in all their glory (i.e. beyond "here's how you do some basic I/O").
Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue.
That's a fair point. Yeah, do-notation is a way to write imperative-looking code in a functional way. The truth is that for small programs, imperative code is often much more readable. That's how recipes are written, for example. Five lines of imperative code never killed anyone. It's when a function gets to 4,000 lines (often with multiple authors) that imperative programming completely shits the bed.
Monads, in short, are... a way to abstract around the concept of computational context so we can define what "stateful effects" are. `IO` has access to anything the machine can do. `ST` is single-threaded but stateful. `STM` can update some state (`TVars`) but has to follow the transactional rules. `State s` is a pure monad that looks stateful because it uses explicit state. Then we get to the monad transformer stacks, which are... potentially very complicated. (Phil Freeman's work with row types and the `Eff` monad in PureScript may replace the MT stacks one day.)
The point, in short is: imperative code is not evil, we're not trying to do away with it. We want to segregate it into functions that are preferably easy to read so we can reason about what stateful effects do happen. In Haskell, the monad system allows us to enforce this at the type level. You can look at the type signature and get an upper bound (unless "cheat functions" like `unsafePerformIO` are used; and they generally shouldn't be) on the space of stateful effects that can occur.
Most companies are run by short-sighted mediocrities who don't look more than 3 months into the future. I think longer term. In the long term, the transition is worth it. The benefits of moving from Java to Haskell or Clojure, say, are worth a few months of struggling and first-time code. If you have half-decent programmers and a culture that allows people to take time to learn how to do things right, that pays itself off within the year.
The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete.
That's not really true. If you need strictness, you can force evaluation and you don't need to use monads. I'm writing a Haskell class and I cover `seq` before I tackle monads in all their glory (i.e. beyond "here's how you do some basic I/O").
Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue.
That's a fair point. Yeah, do-notation is a way to write imperative-looking code in a functional way. The truth is that for small programs, imperative code is often much more readable. That's how recipes are written, for example. Five lines of imperative code never killed anyone. It's when a function gets to 4,000 lines (often with multiple authors) that imperative programming completely shits the bed.
Monads, in short, are... a way to abstract around the concept of computational context so we can define what "stateful effects" are. `IO` has access to anything the machine can do. `ST` is single-threaded but stateful. `STM` can update some state (`TVars`) but has to follow the transactional rules. `State s` is a pure monad that looks stateful because it uses explicit state. Then we get to the monad transformer stacks, which are... potentially very complicated. (Phil Freeman's work with row types and the `Eff` monad in PureScript may replace the MT stacks one day.)
The point, in short is: imperative code is not evil, we're not trying to do away with it. We want to segregate it into functions that are preferably easy to read so we can reason about what stateful effects do happen. In Haskell, the monad system allows us to enforce this at the type level. You can look at the type signature and get an upper bound (unless "cheat functions" like `unsafePerformIO` are used; and they generally shouldn't be) on the space of stateful effects that can occur.
> I've seen startups killed by New Guy CTO Who Really Likes Java.
Of course, that's simple statistics. Java is the dominant language out there so it's going to be the most used language by startups that fail. That's a pretty silly argument.
And it works both ways: most of the startups that succeeded are based on Java (and other dominant languages). Hardly any of those based their product on Haskell. And again, I'm sure you can find a handful of those, but we're talking about statistical anomalies here.
Of course, that's simple statistics. Java is the dominant language out there so it's going to be the most used language by startups that fail. That's a pretty silly argument.
And it works both ways: most of the startups that succeeded are based on Java (and other dominant languages). Hardly any of those based their product on Haskell. And again, I'm sure you can find a handful of those, but we're talking about statistical anomalies here.
> But picking Haskell as a start up is suicidal.
That's not the experience Skedge.me had. Rewriting their app in Haskell gave them an 80% code reduction, fixed all their major bugs that had been significantly impacting customer satisfaction, and the performance increases dramatically reduced their hosting costs. Their experience is described in more detail here:
https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207
That's not the experience Skedge.me had. Rewriting their app in Haskell gave them an 80% code reduction, fixed all their major bugs that had been significantly impacting customer satisfaction, and the performance increases dramatically reduced their hosting costs. Their experience is described in more detail here:
https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207
> Rewriting their app in Haskell gave them an 80% code reduction,
Surely you don't think that's how you measure a startup's success, right?
Surely you don't think that's how you measure a startup's success, right?
Agility matters, and code size pushes against that.
That said, the other bits are clearly more important: improved customer satisfaction and lower costs have much to do with startup success/failure.
That said, the other bits are clearly more important: improved customer satisfaction and lower costs have much to do with startup success/failure.
That's not what you said though. You said picking Haskell was "suicidal". Clearly it's not.
But picking Haskell as a start up is suicidal.
Unsubstantiated FUD.
Unsubstantiated FUD.
Indeed. See how the FUD spreader bends itself in all kinds of curves in order to not drown in comments...
> hardly anyone has open positions for Haskell jobs
They do exist (many but not all are mainly Haskell positions):
http://jobsearch.monster.com/search/programmer_5?q=haskell
http://careers.stackoverflow.com/jobs?searchTerm=haskell
They do exist (many but not all are mainly Haskell positions):
http://jobsearch.monster.com/search/programmer_5?q=haskell
http://careers.stackoverflow.com/jobs?searchTerm=haskell
Trumps all build tooling? Can I take any GNU Make project and replace the build tool with Stack?
No, but you might with Shake: http://shakebuild.com/
I notice now I cut some corners. I meant language specific tooling for resolving/downloading dependencies, building and installing.
Sorry for the confusion.
Sorry for the confusion.
Stack is freaking awesome (brings compile times down dramatically, prevents cabal hell) but I'm sad that it doesn't seem to work with emacs haskell-mode and yesod-bin yet (because those tools depend on a .cabal dir). Stack support for those tools can't come soon enough!
I assume this is too green to work with cross-compilation (to arm built from x86, for example), but does anyone know if that support is planned?
I did some haskell work with iphone in the past, and it was a pain to go from testing locally to testing on device. Everything (including dependencies) had to be rebuilt. This would solve my multipackage woes, but only if it could separate platforms.
I did some haskell work with iphone in the past, and it was a pain to go from testing locally to testing on device. Everything (including dependencies) had to be rebuilt. This would solve my multipackage woes, but only if it could separate platforms.
URL appears to have changed to https://www.fpcomplete.com/blog/2015/06/announcing-first-pub...
Page does not exist.
Works for me even though archive.is (https://archive.is/GZLs2) doesn't see it.
here's the announcement text: http://pastebin.com/aPLq5ySG
here's the announcement text: http://pastebin.com/aPLq5ySG
Didn't work the first time either. But visiting the site a second time revealed the article.
is this supposed to replace Cabal?
It's basically a drop in replacement for `cabal-install`, while leveraging off Cabal the library, which means package description files don't need to be rewritten, i.e. your old cabal package will still work.
It's a huge departure from using cabal-install. Faster project setup time, and not having to worry about managing sandboxes, compiling a new sandbox, or getting stuck in cabal hell.
So, yes, you could look at it as a cabal-install rewrite.
It's a huge departure from using cabal-install. Faster project setup time, and not having to worry about managing sandboxes, compiling a new sandbox, or getting stuck in cabal hell.
So, yes, you could look at it as a cabal-install rewrite.
It relies on cabal-the-library. It replaces cabal-the-tool.
For some use cases it might work as a replacement, but it doesn't have a dependency solver so I don't think you can really say it's a serious general-purpose cabal replacement. It's more like build porcelain for cases where you already have your package's whole dependency tree locked down.
This is false, see the `stack solver` and `stack init --solver` commands. Currently it's using cabal's dependency solver under the surface, but there is work in progress (by multiple parties) to implement a new SAT-based solver, see: https://github.com/commercialhaskell/stack/issues/116
Ahh, my mistake. Cabal's solver is in the cabal-install package and since stack doesn't depend on it I assumed it wasn't tackling that problem.
Since it's actually shelling out to the cabal executable for its solving needs it still pretty much fits the definition of porcelain.
Since it's actually shelling out to the cabal executable for its solving needs it still pretty much fits the definition of porcelain.
Works here also.
I totally see how this language and it's ecosystem are going to be the next big thing in programming. Ultra highlevel and very compact code that compiles to relatively fast native code. Purely functional and strong type system guarantees to help refactoring the most complex codebases.
It is a hell of a secret weapon for startups.