And I thought it might be related to this hyper: https://hyper.sh (which is also an OSS project)

While not quite ready for a 1.0.0, there has been some neat stuff going on in hyper: over the last week, the tokio branch added support for TLS, and from what I hear, is mostly waiting on tokio's initial release to be merged into master. Soon........

Does the parser support HTTP2 yet?

No, but it is marked for the 1.0 release: https://github.com/hyperium/hyper/issues/304

Waiting for this and the tokio branch to be available. For now we have solicit, which is ok but could have a better interface for async io.

At first glance I was thinking the same thing! Then I realized it was a JS terminal emulator... sigh

haha seems like there's so many hypers. When I saw this I thought about Python Hyper (HTTP2) https://hyper.readthedocs.io/en/latest/

I also came here hands shaking thinking "YES YES FINALLY". Was a slight disappointment. Well, take your time to get it stable. :)

Me too, even though I was a bit surprised by the announcement: with the undergoing work around async IO and Futures, I don't expect hyper to stabilize quite soon.

Typesafe HTTP implementation? Meh. I go back and forth on stringly typed vs strong typing. Just this weekend I wrote an app in Objective-C instead of Swift, and it's already close enough to 1.0 that I can start using it myself. I originally tried to do it in Swift but the IDE support is just way too lacking and buggy (still!) compared to ObjC. Point being, string-typing and dynamic typing aren't really all that terrible as I keep thinking they are. It gets the job done. Sure, something will always be better. But I've given up at aiming at perfectionism in programming. There's no such thing as The Perfect Language / Paradigm / Type System / etc.(TM). I'm too old and tired to keep chasing that rainbow. Pretty sure the pot of gold's in front of me all along and I keep just not noticing it and tripping over it.

> But I've given up at aiming at perfectionism in programming.

Optional typing is the sweet spot.

I agree, the next missing bit is runtime structural typing (not optional of course) that allows constructs like:

```

const whatIsFoo = match (foo) {

  case : nil : "nothing, really"

  case : string : "it's a string"

  case : number | boolean : "it's bool or number"

  case [ head, ...tail ] : string[] : `it's array of strings with head ${head} and tail ${tail.join(', ')}` 

  case { value } : { type: 'NodeFoo' } : `it's Node Foo with value ${value}`

  default: "well, something else."

}

```

If only there were a decades-old system that allowed that[1]

1: https://en.wikipedia.org/wiki/Common_Lisp_Object_System

It kind of already feels like that's what Objective-C is. You can use pretty-strong types, or you can just cast to id. Same with NSArray, elements can either be id (default) or a specific type. I just kind of feel like using better type systems hasn't actually helped me write better/cleaner/safer code. It's just added a very small amount of confidence and sometimes convoluted my code disproportionately.

Objective-C doesn't have algebraic data types.

Optional, structural algebraic type system with runtime support (mainly for `match ...` constructs) is IMHO the sweet spot.

It really makes a difference to have it. The analogy on top of my head is this: it's like a difference, when working on text processing code, to have regexp or do things by hand. Similar to regexps, above type system support, can cut necessary code by orders of magnitude and make it much more readable/reason about.

This seems to me to be a needlessly synchronic perspective. What you're not looking for anymore doesn't exist because we haven't built it yet. How many thousands of years did it take to invent most other modern tools? Why would you expect us to have perfection in such a short time after computers have been invented?

Quit looking for pots of gold and start panning for nuggets.