
Shipping forgettable microservices with Rust - wofo
https://precompile.com/2016/06/23/shipping-forgettable-microservices-with-rust.html
======
gue5t
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?

~~~
ukyrgf
I got an eery vibe that this was the equivalent of an /r/SubredditSimulator
post for Hacker News.

------
cm3
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.

~~~
the_mitsuhiko
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.

------
anfroid555
What web framework is this on?

~~~
killercup
Iron, apparently:
[https://github.com/dirk/metrics_distributor/blob/d29c897d156...](https://github.com/dirk/metrics_distributor/blob/d29c897d156d7aa335561deaf2ae90b15da4ca80/Cargo.toml)

~~~
IshKebab
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=...](https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext)

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

~~~
andrewflnr
When you see Rust being "slower than Ruby" it's usually because you forgot to
turn off debug mode.

~~~
frewsxcv
Looks like they use build with release mode:

[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Rust/iron/setup.sh)

~~~
steveklabnik
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.

------
vitalus
Why not Go? Checks the boxes of "performant" and "safe" while remaining
developer friendly compared to Rust

~~~
bluejekyll
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.

~~~
vitalus
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

