As you might have guessed from the version number, http4k isn't actually that new - we've been using it in production with significant traffic (in the top 1000 globally according to alexa.com) since March so it's thoroughly battletested in the wild.
How long did it take to create this?
More seriously, we had a pretty good idea of how we wanted the main interfaces to look - the current HttpHandler and Filter file (https://github.com/http4k/http4k/blob/master/http4k-core/src...) file is only 19 lines long - so the actual implementation was pretty quick! :)
Previous to that, we started out with a 40 line Kotlin script which wrapped the API of an awesome Java framework called UtterlyIdle. However we soon wanted to begin using pure, idiomatic Kotlin, so eventually decided to start again and port what we needed. The simple routing API was also pretty easy, although the ability to infinitely nest routes in concert with the Filter system came later.
Timewise, we've been in prod with http4k since about March - here's the github contribution graph (https://github.com/http4k/http4k/graphs/contributors). A lot of the effort since has been for adding the various modules as we needed them - AWS request signing was interesting, as was adding Multipart support (ported from a Java implementation by @tiestvilee who you can witness being sarcastic further down this thread :).
Personally, the most complicated (ie. time-spent) bit to get right was probably the Lens API- there were several iterations of that until it was as clean, and we learned a lot about the language at the same time - for instance, that you can define extension methods on a Kotlin Object and then import them from that instance - thus allowing you to have different versions of the same extension method happily coexisting.
type AsyncHttpHandler = Request -> Future Response
type AsyncHttpHandler = Request -> (Response -> ())
or use green threads
There are various things I'd like to add - simple plugin modules for metrics (dropwizard or prometheus), security (probably pac4j) and typesafe session support (via lenses) are in there. A sane websocket api seems to be a popular request so we'll also probably look at that.
Async would probably be via coroutines as that seems to be the nicest option API-wise. If it did work out well then we could probably backport it and piggyback the sync api on top.
The serverless stuff is interesting as well, although that's more around the deployment tooling at the moment - we'll see what happens if Google and MS get involved, or how the tooling develops for things like terraform.
Other than that - we'll happily accept suggestions! :)