6 ms·
Rest – A Haskell REST framework
- gberger 12y agoKind of a colliding name, huh?
- dons 12y agoThis would become "haskell-rest" in most package systems.
- lukasm 12y agoGooglabilty of the name is really bad. Rename it to something else e.g. HRest
- PMan74 12y agoOr Resth, (unless somebody in the lisp community bagged that one already)
- lynndylanhurley 12y agoHahahaha
- btown 12y agoMakes you realize that any possible name for a REST framework for Go is inherently an oxymoron...
- anaphor 12y agoNobody thought of Hest? I admit it does sound kind of silly though, but it's got the 'H' at least, and it doesn't sound like Rest.
- bergmark 12y agoMan, I should have thought of this, ( http://kausti.com/blogg/uploadedimages/snelhest.jpg http://kausti.com/blogg/uploadedimages/snelhest.jpg ). But like PBH says "The name is the most important part of a project, and once you have a name there's NO GOING BACK"
- Dewie 12y agoWith that name you can get a mascot, too: http://en.bab.la/dictionary/danish-english/hest http://en.bab.la/dictionary/danish-english/hest
- dllthomas 12y agoNo reason they can't use that mascot regardless!
- sfvisser 12y agoReally doesn't matter, the target audience will either use Hackage (Haskell's package database) or will prefix Haskell to their search term.
- deleted 12y ago[deleted]
- jamesbritt 12y agoOr Rhest. (But even then it makes it hard to actually talk about in person.) What motivates people to name projects after simple, common words? Strikes me as a conceptual land-grab.
- stdbrouw 12y agoI'm more often annoyed by projects named after mythological creatures, vegetables or puns. They're fun for a while, but when I import something into a project, it helps if it's at least a little bit self-documenting – `import Rest` rather than `import Bazooka`, say.
- deleted 12y ago[deleted]
- tel 12y agoThere's a little bit of that in Haskell right now. It's kind of OK with, say, `profunctors` which probably has everything anyone could ever imagine about profunctors in Haskell. Furthermore, as a mathematical concept there is not a lot of possible variability in that library. Similarly, `lens` right now has pretty much everything under the sun about lenses, though some prefer the simpler lens packages like `lens-family`. I kind of feel less confident about the choice around `rest` since there are many interpretations and implementation choices which may lead to a desire for competition here. But I'll reserve actual judgement until I use it. I wouldn't at all mind a comprehensive, provably correct webmachine-like implementation of REST called `rest`.
- sfvisser 12y ago> I kind of feel less confident about the choice around `rest` since there are many interpretations and implementation choices which may lead to a desire for competition here. I feel the same about lens :) Note that we didn't even upload a package called 'rest'. We uploaded a family of packages starting with 'rest-'.
- 12y ago
- danidiaz 12y agoI once wrote a Haskell library for Java Swing application automation. I thought of calling it HSwing, but to my surprise (and, eventually, horror) the domain was already taken.
- codygman 12y agoYou could have named it Shwing, though that name is a bit exclusionary.
- lclarkmichalek 12y agoInteresting that they are using hs-src-exts, can the job not be done by Template Haskell?
- sfvisser 12y agoIt could, but would be extremely messy. We think hs-src-exts is really the right tool for the job here.
- peaton 12y agoI know this was just released, but are there any open source projects that currently use this?
- bergmark 12y agoI haven't seen any projects except for rest-example https://github.com/silkapp/rest/tree/master/rest-example https://github.com/silkapp/rest/tree/master/rest-example But on the bright side we have been using this in production for a long time :-)
- MaxGabriel 12y agoDo you guys integrate this with Happstack/Wai/Snap at work, or do you use pure rest or something?
- bergmark 12y agoWe use both the rest-happstack and rest-snap backends, rest-wai is brand new so we haven't gotten around to using that one. You need to pick one of the backends to run an api, rest doesn't contain a web server.
- thathonkey 12y ago"We've decided to call our REST framework - wait for it - Rest."
- lelf 12y agoThis thread's queue for useless bikeshedders is full, sorry.
- thathonkey 12y agoI disagree that the name for something like this is a trivial decision. Especially when considering the name for a framework which will need to be discoverable on Google to gain popularity. And even more especially when you choose to name the framework for working with a technological concept in one specific programming language the same thing (albeit different casing) as that technological concept itself. How is that not a really important decision that should be considered practically? If I want to query Google for REST vs. Rest, or even converse with people about it, you don't think that will quickly become (needlessly) confusing assuming the framework becomes popular? And if you aren't expecting the framework to become popular, does that make it OK to choose such a lazy name? But, hey, at least you got to namedrop the term "bikeshedding" along with your highly specious argument.
- andrus 12y agoGoogle "haskell rest". Done. See @sfvisser's comment: https://news.ycombinator.com/item?id=7965468 https://news.ycombinator.com/item?id=7965468
- thathonkey 12y agoI fail to see how that solves the problem for anyone other than people who already know that they're looking for a Haskell REST framework that might be called Rest.
- pstop 12y agoConsidering the key for any new user, when encountering problems when unfamiliar with the material, is to use a unique term to find answers on the web. Calling your framework after the technology is arrogant, foolish, and wholly unimaginitive.
- dpeck 12y agoIsn't writing out to the network a side effect? Edit: Haskell folks are a bit touchy :) Just a joke, I use Xmonad, I'm cool with y'all.
- arbsn 12y agoYes. Haskell provides excellent facilities for cleanly managing side-effectful code, like the IO monad.
- dave809 12y agoManaging side effects is one of Haskell's biggest selling points
- dllthomas 12y agoGenerally, it is the desired effect. In Haskell, it will be reified in an IO action, will appear in type signatures, and - as a value - can be manipulated and combined with similar values. It will only be a side effect if called with unsafePerformIO or similar, and the Haskell community will rightly condemn you for doing so (outside debugging) without a proof for why it's both okay and necessary in this circumstance - relying on side effects means you lose all kinds of guarantees that the type system usually affords you.
- pestaa 12y agoIt may have been an innocent question, but it implied too much and it implied myths.
- niix 12y agoVery cool. I'm just getting into Haskell. Coming from the JS world, it's nice to be able to start to learn similar things that I do as a JS developer. My mind only thinks in the way of the web currently, so this helps my transition. :)
- gambogi 12y agoI don't have the expertise to dissect this code, so I will choose instead to criticize the name of the project. My opinion is valuable, relevant, and provokes further discussion.
- autodidakto 12y agoInstead of addressing the linked article, your post is insightful self-parody, with much sarcasm -- a style more suited to reddit than hn. Please remove it at once, preferably falling on your sword afterwards.
- collyw 12y agoWhere are the HN rules? I always see comments referencing the style of comments that are encouraged / discouraged, without any actual reference.
- seanmcdirmid 12y agoThere is a trend of minimalism in software system naming. I personally like it, SEO is overrated.
- shawkinaw 12y agoI was just thinking they missed a great opportunity to call it 'raskell'.
- pepijndevos 12y agoNice! I worked with this project when it was not yet public, and it's good. A lot easier to use than what the monads might lead you to think. The generated API clients are great too. Of course the Haskell client uses the same types as the server, so you get type errors in the client if the API changed.
- ilyagr 12y agoI always thought that what makes Haskell particularly readable are the types: to understand what a function does, it is often enough, and always helpful, to understand what type it takes to what types. So, when the first type I see in a Tutorial is Resource IO (ReaderT Title IO) Title () Void I am confused. When, in addition, the functions are named mkResourceReader :: ??? -> Resource IO (ReaderT Title IO) Title () Void I lose hope that I'll ever understand what's going on. Granted, it was only recently that I understood what 'ReaderT Title IO' alone means. I wonder, is there a simple explanation for what's going on, or is the problem at hand really so complicated that this is the easiest way to explain it? For example, maybe there should be a shorter and clearer name for the type 'Resource a (ReaderT b a) b () Void'? What does one do with resources -- I can only see them plugged into the 'route' function. At this point I started cursing that I can't find the Haddock documentation anywhere, and I'm too lazy to search through github. I'm sorry if this comes across as unfriendly to the author of the library, but I hope it's helpful to see what a person who tries to understand what it does might go through. The more I look at it, the more I think that everything could be fixed with a better tutorial. EDIT It's late at night, and I'm rambling, but perhaps it would be enough to explain in the tutorial what the composition route . mkResourceReader does, and what its type is? It seems like that might be tractable.
- sfvisser 12y agoI think your comments are valid and I mostly agree very much with this sentiment. Thank you for sharing. But let's look at it differently. This framework has been developed and shaped over a few years in a corporate environment by a small team of relatively experienced Haskell programmers. The code has been shaped and tweaked to specifically tailor all the needs we had at Silk for a effortless development of a very consistent REST API for our core product. The code solves a lot of problems at once. We never developed this framework as a minimal library for public use. But, because it solves and actual problem for us and is very general purpose we felt obliged to open source it. This might be very useful for other as well. One of incentives for a company to open source an internally used framework is to get community feedback that might end up shaping the software to be simpler, more generally applicable and more battle tested. That's why your critique is useful and exactly one of the reasons to opens source. To go more in the why the types for a Resource are what they are right now: - In a real world example your API probably doesn't run in IO, but in some monadic context that allows acces to you database, configuration settings, log server, S3 buckets etc. - Resources contain a schema type that statically enforce the invariant that no routes will ever overlap in the server. - A single resource, or multiple resources, can be identified by multiple identifiers (e.g. a user by uuid, e-mail, or last name). We require a total mapping from identifier to resource action. - While stepping deeper into an API (path segment by path segment) we can learn more about our context and pass information down to sub-resources. We do this by extending the context, in the simplest case with a reader. - The `route` function builds up an existential. So it looks like the type of the Resource is irrelevant and could be one simple type synonym, but it isn't. It's different every time and carries a lot of static information about the resource used at runtime, and for code and documentation generation. We'd love to hear how we can simplify this.
- mark_l_watson 12y agoI have a Haskell project that exposes some NLP experiments in a Yesod web app. I would also like to provide a REST interface, so this looks good. That said, I found nothing in the documentation for using this with Yesod and the developers seem to best support happstack. I am a newbie at using Haskell for web apps, so I need to dig into the possibility of mixing happstack and Yesod in one app.
- mark_l_watson 12y agoWhile this looks like a cool project, since I have already started using (and like) Yesod, I am probably better off using Yesod's REST support (http://www.yesodweb.com/book/restful-content http://www.yesodweb.com/book/restful-content)