Really doesn't matter, the target audience will either use Hackage (Haskell's package database) or will prefix Haskell to their search term.

Or Resth, (unless somebody in the lisp community bagged that one already)

Makes you realize that any possible name for a REST framework for Go is inherently an oxymoron...

Man, I should have thought of this, ( 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"

With that name you can get a mascot, too:

http://en.bab.la/dictionary/danish-english/hest

No reason they can't use that mascot regardless!

Hahahaha

I 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.

You could have named it Shwing, though that name is a bit exclusionary.

Or 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.

I'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.

There'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`.

> 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-'.

I think broad names like that are always contentious, but if the packages which own them are genuinely good packages then it's a net win. I'm personally not hugely opposed to `lens` or `rest`, tbh.

You guys just better earn your keep on that name ;)