
Rust in Production (2018) - mromanuk
https://www.figma.com/blog/rust-in-production-at-figma/
======
leshow
Things that have changed:

\- NLL (non lexical lifetimes) are now in stable, so working with lifetimes
and references is a bit easier

\- stack traces: failure is still around, it's got a fairly large group using
it, it seems. I prefer the std error handling route most times.

\- async is hard: it's still pretty hard

~~~
WhatIsDukkha
Unfortunately failure and errorchain appear to not be cool anymore (ie I've
noticed quite a few people are migrating away from failure just like they did
from errorchain) and there doesn't appear to be any push from the Rust team as
of yet.

I think it's a serious problem as your code base grows and I wish we had some
more work on the RFC front.

~~~
leshow
Given the vanilla error handling is my favorite of the lot, I don't really
consider it a bad thing that people are moving away from it.

There are some downsides, like the lack of stack traces, but it's a nice
pattern. Does it have to be 'one size fits all'?

------
baq
quite smart approach of having a nodejs frontend doing what it's good at
(async) calling the backend via simple subprocess/stdio communication. they
could almost say they invented CGI :)

~~~
MuffinFlavored
> calling the backend via simple subprocess/stdio communication

why is this faster/better than the frontend calling the backend through say,
nginx proxy_pass or REST HTTP calls?

~~~
nevi-me
I did this recently, where I compared going through FFI from Java to Rust, vs
through gRPC. gRPC wasn't that much slower than FFI, and its benefit would be
that I could have 2 services in the network.

FFI had overhead, but its performance profile was consistent, very little
fluctuation in runtime.

~~~
MuffinFlavored
Did you also test HTTP? Did you publish these results anywhere?

------
faitswulff
Anyone know if the first con listed has improved with the introduction of non-
lexical lifetimes?

~~~
glennpratt
I would say it has improved quite a bit, but they are still there. It varies
quite a bit on what you are doing. At work we have a modest sized project,
converted from C, being used and updated for about a year. I don't think it
has had any significant lifetime battles; I don't think there are even
explicit lifetimes in the source.

Data structures exercises will be a different story.

------
youeseh
Rust seems like the right answer for a lot of things except writing servers.
For that, Elixir with its Erlang VM seems like a better answer.

~~~
adamnemecek
Are you aware of actix? What do you think of it?

~~~
youeseh
I'm not aware, to be honest. I'm only now learning Elixir for a few weeks now
and plan on taking up Rust next after building a small Elixir project.

What I found was: \- Elixir, has awesome support for concurrency and zero-
downtime deployments. Runs on Erlang VM. Inspired by Ruby.

\- Rust - replacement C/C++ as the low-level programming language of the
future for people who want to write pretty code.

~~~
adamnemecek
> has awesome support for concurrency

so does rust.

> Rust - replacement C/C++ as the low-level programming language of the future
> for people who want to write pretty code.

It's not just that, it also replaces say python or ruby on the serverside.

> write pretty code.

Yeah, no, it's for people who want to be productive in a low level language.

~~~
dnautics
The erlang vm is explicitly designed for concurrency. I wrote the raft
protocol in elixir in about 300 lines of code.

Rust is great, but it's pretty hard to argue that any language has more
awesome support for concurrency than the beam languages.

~~~
adamnemecek
Ok let's talk concrete implementation.

Rust: [https://github.com/pingcap/raft-rs](https://github.com/pingcap/raft-rs)
LOC: 15417

Erlang: [https://github.com/rabbitmq/ra](https://github.com/rabbitmq/ra) LOC:
18012

Lines of code is not the only metric. I'm actually really curious about Erlang
and Elixir but to be honest I do like type systems a lot. I also like the idea
of idk...having one language for my os, db, front-end.

~~~
dnautics
Unfortunately I can't show you my code since it's closed. Just looking at the
two codebases, about half of the erlang implementation is static typechecking
hints, and I don't know if GitHub counts the documentation HTML as LOC.

As an example of convenient concurrency, in Erlang vm gives you process node
id translation. What that means is that if you're sending a message between
threads in two instances in a cluster of VMs, you can send your the mailbox
address of your local thread and have it converted on transmit to the
equivalent remote thread address on the remote machine. Literally one less
thing you don't have to worry about, and clustering is a first class citizen
in the language, no libraries necessary.

Basically, the dev process was, I wrote my raft implementation, tested it
locally and extensively (including property tests) using multiple local
threads, and did almost nothing (three lines of code to provide a mailbox
Oracle) and had a solution that worked across the network.

If you're curious about BEAM languages, I wouldn't worry about type systems.
If anything I think hypercorrectness in the languages leads to a false sense
of comfort about the quality of your code that can get in the way of building
resilient, designed to fail gracefully systems. Typechecking can catch errors
early and save you dev and debug time, but static typechecking is probably
enough for about 80% of those concerns.

Erlang languages come with static typechecking. It's kind of a pain in the
butt out of the box. I don't know about erlang, but if you code in vscode, the
elixir_ls plugin engages the static typechecking in such a transparent fashion
that I've forgotten to install the makes-static-typechecker-easier library and
it's caught code problems for my junior dev (who I haven't taught typechecking
yet). Despite it being optional in the language, the vscode plugin makes it
ever so ugly to not annotate types that my very minor obsessive tendencies
lead me to annotate everything.

