Live data from Hacker News

How Rust Lets Us Monitor 30k API calls/min

blog.bearer.sh

41–50 of 81 posts

Re: How Rust Lets Us Monitor 30k API calls/min

#41
post #3

I'm one of the engineers that worked on this. It was the first Rust production app code I've written so it was a really fun project.

Looks like some of your screenshots are from NewRelic and the last one is from Datadog?

Yes we switched over from one to another because NewRelic doesn’t really support Rust and DD supports StatsD and there is no lock-in. Good spot ;-)

Re: How Rust Lets Us Monitor 30k API calls/min

#43

They didn't mention Java as a possible solution, even though its GC's are far better than anything else out there. I have nothing against Rust but if I was at a startup I would save my innovation points for where they're mandatory

They did mention Go that also has a modern GC, and does not need to run your app under a software VM. But ultimately, even Go is just another GC language. They had no real need for GC and the like so why use Go, let alone Java?

Go's GC is notoriously low tech. Its design dates back to papers published in the 70s. Java's Parallel collector is most similar to Go's GC and its deprecated for removal due to poor performance.

Go collects VERY frequently to keep average pause times low, which hurts throughput. It also has pathological worst-case pause times, which is what the author ran into.

My suggestion of Java is just because its been used for high performance REST for decades. Rust has Actix and a few other frameworks, in Java you have 20+ options. Its a lot easier to get something off the ground when you're 99% sure you won't have to build anything except some glue code. Yes, Rust is faster, but is 30% better performance worth treading the wilds while you're trying to keep a startup afloat, I don't think so personally.

Using Java with Shenandoah or ZGC collector would directly handle their GC issue with rather boring technology

Re: How Rust Lets Us Monitor 30k API calls/min

#44
post #31
post #6

Sorry, I must be missing something in this blog post because the requirements here sound incredibly minimal. You just needed an HTTP service (sitting behind an Envoy proxy) to process a mere 500 requests/second (up to 1MB payload) and pipe them to Kinesis? How much data preparation is happening in Rust? It sounds like all the permission/rate-limiting/etc happens between Envoy/Redis before it ever reaches Rust? I know…

Seriously, 500 qps was something we used to do in interpreted languages on the Pentium Pro. But this kind of blog post is a whole genre: How [ridiculous startup name] serves [trivial traffic] using only [obscenely wasteful infrastructure] in [trendy runtime framework that's a tiny niche or totally unknown in real industry].

> totally unknown in real industry

Microsoft, Apple, Amazon, Oxide, Mozilla, Dropbox and CloudFlare would like a word...

Re: How Rust Lets Us Monitor 30k API calls/min

#45
post #4

Earlier quoted context omitted.

One of the interesting effects of using rust is saving money! I also migrate a F#/.NET ecommerce backend and can run in less RAM/CPU that make my bills lower.

Can you share information about your experience? I'm currently working on a F# project, enjoying the functional approach, while having a lot of libraries available on the .Net platform. The |> operator is one I use all over the code, but Rust doesn't support custom operators. Is that annoying, or not at all? Is your code less functional and more imperative style due to Rust?

> Is your code less functional and more imperative style due to Rust?

I would imagine so. Rust doesn't support tail call optimization, and variables are immutable only by default.

Re: How Rust Lets Us Monitor 30k API calls/min

#46
post #44
post #31

Earlier quoted context omitted.

Seriously, 500 qps was something we used to do in interpreted languages on the Pentium Pro. But this kind of blog post is a whole genre: How [ridiculous startup name] serves [trivial traffic] using only [obscenely wasteful infrastructure] in [trendy runtime framework that's a tiny niche or totally unknown in real industry].

> totally unknown in real industry Microsoft, Apple, Amazon, Oxide, Mozilla, Dropbox and CloudFlare would like a word...

Engineering by press release? A fun fact for you: Rust is forbidden at Dropbox for new development.

Re: How Rust Lets Us Monitor 30k API calls/min

#47
post #4

Earlier quoted context omitted.

One of the interesting effects of using rust is saving money! I also migrate a F#/.NET ecommerce backend and can run in less RAM/CPU that make my bills lower.

Does Rust offer much of the same language features as F#?

Disclaimer: not a rust of .net dev, but my impression is they’re very different in what they’re trying to. It’d would be like comparing C to Python (as an example, not as an analogy).

Rust is closer to a super fancy C, compiles natively and was made with a heavily focus on certain types of memory safety.

F# has syntax more like Haskell/ML, and is compiled to a bytecode instead of an executable. It runs on .NET and everything that entails.

Re: How Rust Lets Us Monitor 30k API calls/min

#48
post #4
post #3

I'm one of the engineers that worked on this. It was the first Rust production app code I've written so it was a really fun project.

One of the interesting effects of using rust is saving money! I also migrate a F#/.NET ecommerce backend and can run in less RAM/CPU that make my bills lower.

This is a point that's really attractive to me as well. Faster language and runtime means I can run on fewer, cheaper servers which means when its time to scale 10 or 100x, it's not a massive cost increase.
Post reply on HN