back
29 comments
I don't think I have enough context to understand this article.

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?

I got an eery vibe that this was the equivalent of an /r/SubredditSimulator post for Hacker News.
"Log drain" appears to be a Heroku term of art for something that can receive shipped log data from their infrastructure, so an "HTTP log drain front-end" would be a client; if that or something like it is in play here, it would explain why they don't host the aggregator in the same place as whatever's generating the log entries it ingests.

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.

I may be getting this wrong, but I was under the impression that microservices are about having many small services as in a service bus architecture. I don't know how the author came to believe it's about short response times.

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.

Microservices are SOA and there are two ways in which that typically happens: slow offline processing with many different workers. That's not really an issue and something that is a well understood problem. The second however is offloading work to different processes while something is waiting for a result and it wants it quick (a web request). In the latter case it's absolutely important that your services reply quickly.
(I assume) it is not about short response times, but short response times are necessary if you split your work in many (assumed partially serial) requests to small services and still want acceptable overall response time.
Nor do I. Micro services are built around being able to be scaled and manipulated without having those changes break your entire application.
I'll return answer to your question in a week. Hope you will be still interested to hear it.
What web framework is this on?
Iron, apparently: https://github.com/dirk/metrics_distributor/blob/d29c897d156...
I'm surprised people can use Iron at all. I tried really really hard to use it and found the complete lack of documentation (or, worse, outdated blog posts) made it impossible. Is there some magic necronomicon I'm missing?

I had better luck with nickel.rs because it has an examples/ folder with quick recipes of most things you'd want to do.

My experience exactly. Nickel.rs has a fairly good set of clear examples on its website and then some more on Github.

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.

We are in the early stages of having an official docs team; one of the things we want to do is figure out how to encourage better ecosystem docs. Towards that end, right now is the first "doc days": https://facility9.com/2016/06/announcing-rust-doc-days/ we'll be focusing on the rust-lang-nursery crates this time, but will focus on the ecosystem ones in the future!

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 :/

Better tooling will definitely help but I think it will mainly come to focus and priority.

Some packages like Serde for example do provide higher level docs located with the API docs which can work fine.

Which has very disappointing benchmarks at the moment - even slower than some Python and Ruby stacks:

https://www.techempower.com/benchmarks/#section=data-r12&hw=...

I'm not sure why this is - I've Googled to no avail - but it is rather worrying.

I've been doing some work on these benchmarks. They appear really slow to me as well; I found the environment really hard to set up, though, so I haven't quite figured out how to identify why they're this way.
When you see Rust being "slower than Ruby" it's usually because you forgot to turn off debug mode.
Looks like they use build with release mode:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

So it's important to not compare master to when the benchmark was posted; remember, they do them at a certain time, then work happens. So like, I sent a PR to update Rust from 1.0 to 1.6 at one point, for example.

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.

Why not Go? Checks the boxes of "performant" and "safe" while remaining developer friendly compared to Rust
You can just as easily ask, why not any other language, for the exact same reason.

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.

Sure, it just felt like a more natural fit than other languages given the criteria which is why I called it out specifically

Thanks for your mention of additional runtime safety, it isn't something I had considered

Oh connection pooling is handled automatically by the standard library ...jk not really, it leaks sometimes ... and ...down ...goes ...my ...production database. 2 weeks ago.
I'm not a fan of Go, but the connection pooling in the standard library doesn't leak. You're just not closing the Rows object if you encounter an error. It automatically closes if you fully iterate through it. But if you stop part way, you have to manually close it or the connection will not be returned to the pool.
Yeah I don't have the code or docs in front of me but I think it was calling db.Query().Scan(&thing) and forgetting to close the row returned by .Query(). I was also using some edgier parts of the sql package without fully understanding a lot it, so I exposed myself quite a bit.

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.

Lack of generics is extremely developer hostile.
The article helpfully answers that question for you. It's entirely about features unique to Rust.
I actually saw very few unique features of Rust mentioned in the article which is why I was looking to contrast it at a high level to another language which met the criteria the author laid out while avoiding a mentioned drawback...I would hardly consider "it compiles to native" and "measured and thoughtful standard library" to be features unique to the language, though no doubt important!
The sophisticated type checker, the borrow checker, and the LLVM backend were all cited in the article and are all things Rust has that Go doesn't.