What exactly does "response time" measure, here? The diagram of the system makes it look like this program is essentially just a scan over a data stream, so each iteration should be minimally computationally intensive--certainly not in the tens of milliseconds.
Is this counting time to query the left-hand-side? Or is it time from receiving a message from the LHS to forwarding it rightward?
I don't know what a "HTTP log drain front-end" is: is this software an HTTP client, or an HTTP server? If making HTTP requests across some network is costing you up to 10ms, what network is that, and why not simply run this code on the host that generates the data you're currently sending over HTTP?
40 requests/second does sound somewhat low, but that may just be the average rate at which whatever they're aggregating generates log entries, rather than a limit enforced by resource exhaustion.
EDIT: Reading the responses, I should clarify: The question is if a microservice needs to be be fast to respond to be considered a microservice, or if both types are called micro based solely on the fact that they are limited-purpose small services, together building a greater construct. I would say kinda-synchronous fast responding services are just as micro as very-asynchronous slow responding but still limited API services are.
I had better luck with nickel.rs because it has an examples/ folder with quick recipes of most things you'd want to do.
Unfortunately it seems to be a common trend that Rust projects only provide API docs. While that can be useful I find more 'high level' docs much more helpful especially when you're new to the language and/or framework.
EDIT: Oh, and I've wanted a good way for Cargo to produce additional, non-API docs through a top-level "docs" directory, but haven't found the time to properly implement it yet :/
Some packages like Serde for example do provide higher level docs located with the API docs which can work fine.
I'm not sure why this is - I've Googled to no avail - but it is rather worrying.
That said, I don't think that missing out on --release was the issue here, as far as I know, it has always been on.
But since you asked about Go, here are the 3 reasons that I would not pick Go:
1) no generics means less code reuse, which mean more testing of more code (potential runtime issues)
2) allowance of Null, means potential NPE/seg-faults (runtime issue)
3) non-type safe, inconsistent error handling (another runtime issue)
Go is a fine language, like many others, but it's not the same as Rust, and doesn't offer the same features (like no runtime/GC), which means it's not as flexible in its usage. But, I will grant you that Go is "easier" to write code in.
Anyway, there will be and are many great programs written in Go, as there have been in C, C++, Java, Perl, Python, Ruby, Erlang, Haskell, Ocaml, Ruby, JS, etc. To each there own. Mine is Rust today, was Java before that, C++ before that, C before that, and Basic before that.
Thanks for your mention of additional runtime safety, it isn't something I had considered
Go is a small language but it's a language with roots in C that many people (myself included) don't understand that well. It's deceptively easy, kind of like picking up Elixir because Ruby without understanding Erlang. Lots of paper cuts.