stack VS yesod-persistent

Compare stack vs yesod-persistent and see what are their differences.

stack

The Haskell Tool Stack (by commercialhaskell)

yesod-persistent

A RESTful Haskell web framework built on WAI. (by yesodweb)
Our great sponsors
  • Nanos - Run Linux Software Faster and Safer than Linux with Unikernels
  • Scout APM - A developer's best friend. Try free for 14-days
  • SaaSHub - Software Alternatives and Reviews
stack yesod-persistent
16 2
3,634 2,411
0.7% 0.3%
7.7 7.4
25 days ago 19 days ago
Haskell Haskell
BSD 3-clause "New" or "Revised" License MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

stack

Posts with mentions or reviews of stack. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-26.

yesod-persistent

Posts with mentions or reviews of yesod-persistent. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-03-24.
  • The Importance of Humility in Software Development
    1 project | news.ycombinator.com | 12 May 2021
    > Every language phasing the web is stringly typed

    Heh, not even close. Off the top of my head I can think of Ur/Web as an extreme example ( http://www.impredicative.com/ur ), and slightly more mainstream systems like Yesod ( https://www.yesodweb.com ). I've worked professionally with Haskell, although not for Web stuff. These days I mostly work with Scala, which has a similar typing mindset to ML/Haskell, but unfortunately inherits a lot of stringly typed legacy from Java. We use an in-house library that provides zero-cost newtypes to distinguish between different semantically-distinct data types, many of which just-so-happen to be representable as subsets of String (e.g. GET parameter names, GET parameter values, POST bodies, etc.). This makes it a type error to try and e.g. concatenate different sorts of data together.

    W.r.t. "escaping", I tend to avoid it entirely since it's inherently unsafe:

    - "Escaping" doesn't distinguish between its input and output types; they're both just "String", and we have to make assumptions about the contents of each (i.e. it's unsafe)

    - Having the same input and output types makes it possible to "double-escape" by accident. This discourages the use of escaping, just-in-case it happens to be done elsewhere; hence it's very common to end up without any escaping taking place.

    - Having the same input and output types makes escaping functionally unnecessary: anything we do to an escaped string could also be done to an unescaped string, so it's up to us to remember that it's needed (i.e. it's unsafe).

    The whole idea of "escaping a string" betrays a flawed approach to the problem. Instead of throwing everything into the same representation, then manually trying to figure out whether or not a value comes from a particular subset of that representation or not, it's much easier and safer to avoid lumping them all together in the first place. If our inputs have a certain type (e.g. HTTP.Get.Val) and we can only output certain other types (e.g. JSON, Map[HTTP.Header.Key, HTTP.Header.Val], etc.), then the processing which turns input into output is forced to specify any necessary conversions. Whilst such conversions may involve escape sequences, having them associated to particular types is more akin to serialisation.

    Heck, at my first PHP job we largely solved this problem not by 'filtering and escaping', but by modifying the PHP interpreter to distinguish between 'clean' and 'dirty' strings (with literals being clean, and $_GET, etc. being dirty). Operations like concatenation would propagate 'dirtiness', and output functions like 'echo' would crash if given a dirty string. Traditional 'escaping' functions would convert dirty strings to clean ones, and crash when given a clean string. Having this be dynamic was more annoying than ahead-of-time compile errors, but it still did a pretty good job.

    There's pretty much no excuse for stringly typed languages/libraries/etc. when such such trivial solutions exist, other than the historical inertia of legacy systems.

  • Starting a project that depends on a module with a custom Prelude: mixins, cabal, and yesod-bin
    3 projects | reddit.com/r/haskellquestions | 24 Mar 2021
    The project is going to make use of Warp. To smoothen the development process I set up yesod-bin according to their template for non-yesod projects. This worked fine initially, giving me hot reloading on file changes, but after adding the private package as described above it's giving the following error:

What are some alternatives?

When comparing stack and yesod-persistent you can also consider the following projects:

Cabal - Official upstream development repository for Cabal and cabal-install

swagger-petstore - swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.

graphql - Haskell GraphQL implementation

ghcid - Very low feature GHCi based IDE

castle - A tool to manage shared cabal-install sandboxes.

bisect-binary - Tool to determine relevant parts of binary data

swagger2 - Swagger 2.0 data model.

implicit-hie - Auto generate a stack or cabal multi component hie.yaml file

profiterole - GHC prof manipulation script

fields-json

bumper - Haskell tool to automatically bump package versions transitively.

yesod-routes-typescript