Hacker News Reader

Comment by didroe | Hacker News Reader

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.

View on HN

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?

The |> operator I miss, but rust have a near similar feel with iterators:

    let a= [1, 2];
    a.iter().filter(|x|..).map(|x|...)

I think I'm more functional in a lot of areas where in F# can't (or don't know how). One reason?:

https://doc.rust-lang.org/std/convert/trait.Into.html

This is THE feature I wish other langs copy. Combined with serde:

https://github.com/serde-rs/serde

Is possible to cut a lot of boilerplate related to data transformation (that is the main task in my case).

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

LLVM should optimize tailcalls and sibcalls. But tail call optimization has unexpected interactions with the extended RAII that Rust uses because stuff has to be dropped at the end of its lifetime, so the code that's running in "tail" position is sometimes not what you expect.

As a beginner to Rust I'm surprised by this. Given the Rust compiler is able to figure out the lifetimes in the recursive case, you'd think the lifetimes within the tail-optimized loop would be same. Doesn't the lexical scoping of the loop's body have the equivalent lifecycle of a recursive call (drop at the end of the loop vs the end of the function)?

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.

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.

That's actually why I'm asking about that since the OP is transitioning backend logic from F# to Rust. So either Rust can cover a lot of the language features or he has a use case that really warrants that performance (and F# on .NET is not exactly non-performant).

Near. Exist some fancy features that are not present, but the practical side is covered...

Interesting post ! From what i've understood you had only one instance of NodeJS, while i agree that Rust is more performant generally, couldn't have you just added more instance ?

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 ;-)

Reply on news.ycombinator.com