tokio-minihttp

Protocol implementation experimentations

Explore on GitHub Read Hacker News discussions

3Distinct people

3Mentions

0Explicit recommenders

465GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Protocol implementation experimentations

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month3 dated mentions

Observed mentions: 2016-08-11 16:33:39 UTC to 2018-03-27 16:27:26 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Aug 2016	2016-08-01 00:00:00 UTC	2016-09-01 00:00:00 UTC	1	1
Sep 2016	2016-09-01 00:00:00 UTC	2016-10-01 00:00:00 UTC	0	0
Oct 2016	2016-10-01 00:00:00 UTC	2016-11-01 00:00:00 UTC	0	0
Nov 2016	2016-11-01 00:00:00 UTC	2016-12-01 00:00:00 UTC	1	1
Dec 2016	2016-12-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
Jan 2017	2017-01-01 00:00:00 UTC	2017-02-01 00:00:00 UTC	0	0
Feb 2017	2017-02-01 00:00:00 UTC	2017-03-01 00:00:00 UTC	0	0
Mar 2017	2017-03-01 00:00:00 UTC	2017-04-01 00:00:00 UTC	0	0
Apr 2017	2017-04-01 00:00:00 UTC	2017-05-01 00:00:00 UTC	0	0
May 2017	2017-05-01 00:00:00 UTC	2017-06-01 00:00:00 UTC	0	0
Jun 2017	2017-06-01 00:00:00 UTC	2017-07-01 00:00:00 UTC	0	0
Jul 2017	2017-07-01 00:00:00 UTC	2017-08-01 00:00:00 UTC	0	0
Aug 2017	2017-08-01 00:00:00 UTC	2017-09-01 00:00:00 UTC	0	0
Sep 2017	2017-09-01 00:00:00 UTC	2017-10-01 00:00:00 UTC	0	0
Oct 2017	2017-10-01 00:00:00 UTC	2017-11-01 00:00:00 UTC	0	0
Nov 2017	2017-11-01 00:00:00 UTC	2017-12-01 00:00:00 UTC	0	0
Dec 2017	2017-12-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
Jan 2018	2018-01-01 00:00:00 UTC	2018-02-01 00:00:00 UTC	0	0
Feb 2018	2018-02-01 00:00:00 UTC	2018-03-01 00:00:00 UTC	0	0
Mar 2018	2018-03-01 00:00:00 UTC	2018-04-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

pcwalton·Mar 27, 2018

You can write an overcomplicated framework in any language. Some of those Java frameworks are pretty impenetrable too. Here's an example of some Rust code that's even faster and is short and sweet: https://github.com/tokio-rs/tokio-minihttp/blob/master/examp... (I don't think the TechEmpower benchmarks really mean much, incidentally. They're so simple that they're way too easy to game.)

In Fast, Safe, and Complete(ish) Web Service in Rust

riskable·Nov 8, 2016

I just want to add that I really like where Tokio is going. The architecture seems well-thought-out and exactly the sort of thing I'm looking for. There's only one problem though... It's still under construction! Every day something new breaks, haha. Whether it's tokio-middleware with the "what was I thinking?" patch: https://github.com/tokio-rs/tokio-middleware/commit/78210757... (seriously, click that link it's funny) ...or today's fun: https://github.com/tokio-rs/tokio-minihttp/issues/12 The good news though is that it is obviously being worked on--heavily. The Rust ecosystem is so new that it feels a bit like we're in the Wild West. Someone comes up with a decent way to do something and then after a bit of ecosystem evolution we're back to the drawing board since, "there's a better way." This is all very good because it means tha

Read the rest

t the Rust ecosystem is evolving rapidly. It also means that developers are productive enough in the language that entire frameworks can be re-written from scratch in a reasonably short amount of time. I think it's a good demonstration of how effective the language is overall at its goal of improving productivity (as far as systems programming languages go).

In Rust Actor Library: First Assorted Thoughts

tomdale·Aug 11, 2016

The recent flurry of activity around async IO in Rust has been really exciting; to me, it indicates that the core team's decision to stabilize the language was a smart bet that is paying off in rapid ecosystem growth. One quibble I have with this post is that it talks about futures as a zero-cost abstraction. That might be true (or close to true) from a performance perspective, but in my (admittedly inexperienced) opinion, it seems to have a significant ergonomic cost that is not accounted for. While futures help us deal with multi-threaded coordination of data from multiple sources, that overhead isn't necessary for situations where you're running in a single thread dedicated to doing IO operations. Dealing with futures in your code is not non-trivial. Browsing through the futures version of the HTTP server, I had a hard time following a

Read the rest

long: https://github.com/alexcrichton/futures-rs/blob/master/futur... And it requires a bunch of helper code to go with it: https://github.com/alexcrichton/futures-rs/blob/master/futur... The blog post mentions Tokio, another high-level abstraction on top of mio (by the same author). Because it doesn't require the futures abstraction from top-to-bottom, it offers similar (maybe even a little better) performance with what, to my eyes, is far simpler code: https://github.com/tokio-rs/tokio-minihttp/blob/master/src/l... I'm still learning Rust and spend most of my time in JavaScript. The analogy I'd use is: imagine if in the Node programming model, every API required you to use JS Promises, even at the very lowest level. Even if you could reduce the cost of creating new Promise objects, interacting with them over simple values could make the code you write more verbose. In Rust, that problem is exacerbated by the much stricter type system and the fact that you have to do cross-thread coordination. I'm a total beginner to systems programming, and a lot of this stuff is above my pay grade. However this shakes out in the community, I'm very happy to see Rust on the way to becoming the fastest, most productive way to write high-performance web services.

In Zero-cost futures in Rust