The basic premise is that all our business actions can either be run "for real" through Yesod, or within a State-based framework that's part of our standard testing scaffold.
The end result is that it's trivial to write tests that arrange for the database, clock, sockets, and so forth to be in precisely the state we want them to be for the test, and to sense everything afterward.
Running these tests as pure State actions has additional benefits:
Since State operates by making successive state copies for each "mutation", test fixtures are easily effected by performing some actions and saving the produced state. Individual tests can start from this state as many times as desired. The state is immutable, so test interference is impossible.
Additionally, tests run without access to IO. This means that the compiler rejects any test which could forseeably intermittently fail.
Any particular reason why Yesod isn't a good fit there? Is the team large enough where it makes more sense for you to roll your own and not deal with making it super generic?
Yesod provides a ton of functionality related to the larger problem of building a website with Haskell, but we're only using Haskell for JSON services.
All those extra bells and whistles are wasted on us. :)
A recent HN post was claiming JEE to be a "startup's secret weapon" (SSW), and I commented that the article did not much to actually backup that statement.
This article explains nicely why Haskell _could_ be an SSW, and specifically in what cases it might is more likely to be. It nicely walks through the strengths and the weaknesses, and compares to the previous experiences with clojure/ruby.
> Build times, especially once the whole constellation of Yesod and Persistent packages are brought into the mix, are not insignificant. It still takes a good 5-10 min to build our larger web application on our beefiest machines. There are optimizations that can be made in this space which we haven't adopted yet, such as caching already build object files to avoid having to re-compile them every time, so I'm confident this will be a non-issue in the nearby future, but it's still worth being aware of. GHC works hard, you need to provide it with enough juice or time to let it do its job.
You hint at the solution to this problem when you mention caching, but I would encourage you to look into the Nix package manager. It's platform and language independent, and is excellent at dramatically speeding up builds by only building anything once. It's gaining popularity in the Haskell community.
Cool! Do you happen to have links to good "how to get started" guides for nix+haskell? Right now it looks like it's a battle between halcyon, stackage-cli and this. I don't quite know yet what fits our use-cases better.
I don't use Nix with Haskell myself yet, because I haven't been doing much Haskelling recently. But I do use it with Python and it's really excellent to use once you start to "get it." Skimming this guide, it seems to do a nice job of explaining Nix as applied to Haskell development[0]. And I'm sure there are many other resources, since it seems to have some traction in that community. I don't know much about the other options you mentioned, but one of the really nice things about Nix is that it's language-independent, which makes it just as easy to express Haskell package dependencies as it is to express any arbitrary dependency (e.g. a foreign library you're linking against).
Haven't found it yet. Nobody else is hitting this either apparently. Manually limiting the # of cores on GHC pretty much removed the issue for us, although it doesn't give me the sense of closure I was hoping for.
I'm vaguely suspecting some sort of resource contention issue. A good way to figure that out would be to run a profiled build with that many cores, assuming that's at all possible.
I am curious if anybody has experience using Haskell and clojure/core.typed and could comment on the two. In the article the author states "You're writing fewer bugs, you're reusing more code, new developers are causing less damage, and you have more room to deal with technical debt before it bites you.", I wonder if the same could be said of projects with core.typed.
I haven't used Haskell in a production environment, but I ended up removing core.typed from my Clojure core since it often fell apart/became prohibitively verbose when dealing with nontrivial functions and higher kinded types.
It could be really good if it's inference engine was improved, I can see a LOT of potential. But it just isn't there yet.
I would imagine adding some types with core.typed would provide benefits, but there is such a vast difference between incrementally adding types with core.typed and haskell, I fear there may be more differences than similarities here?
Is be curious to know how big a problem laziness is in real applications. Is it mostly a non-issue because in a web app things tend to be short requests or do you end up having to use seq and force strictness in many places?
By and large you can ignore laziness without issue. Multi-threading is, ironically, one of the first places you might see an issue as you must guarantee where evaluation occurs and how far.
Other than that the major risk is of a space leak. In a web service model you generally won't write the sever or the database connection and therefore will be masked from long-running memory hog computations.
Haven't run into issues with laziness yet, but, as you guys pointed out, our use-case is very short-lived. We can likely get away with some sloppiness here and there because of it. I'm sure I'll still get burned by this at some point, but at least I'll be expecting it to some extent.
It depends on what you're doing. I've been doing Haskell full-time for the last five years and the vast majority of the time I haven't had to think about laziness. But there have been a handful of places where I did need to think about it. It's certainly possible that those situations will be much more common in some types of work. But I think if you average over the whole software industry you probably won't need to think about it very often.
We[1] used to think that you do not need to worry about lazyness, too - but ran into massive issues with large memory usage and massive GC pauses. We introduced a policy that all fields of a data type must be strict (no Lists, no Maybe, no Either, ..., all custom strict types). That solved the issue for us.
At IMVU, we built up a bit of scaffolding along these lines: https://gist.github.com/andyfriesen/43d886ce60927c69b3d1
The basic premise is that all our business actions can either be run "for real" through Yesod, or within a State-based framework that's part of our standard testing scaffold.
The end result is that it's trivial to write tests that arrange for the database, clock, sockets, and so forth to be in precisely the state we want them to be for the test, and to sense everything afterward.
Running these tests as pure State actions has additional benefits:
Since State operates by making successive state copies for each "mutation", test fixtures are easily effected by performing some actions and saving the produced state. Individual tests can start from this state as many times as desired. The state is immutable, so test interference is impossible.
Additionally, tests run without access to IO. This means that the compiler rejects any test which could forseeably intermittently fail.