
Facebook picked Rust to implement Libra - tosh
https://www.reddit.com/r/rust/comments/c20aed/facebook_just_picked_rust_to_implement_their_new/erhsz9q/
======
xvilka
And WindRiver just sent their first pull request[1] to support VxWorks as a
target.

Shameless plug - I made a proposal[2] to create Business Applications Working
Group to help promote Rust in enterprise software, quant and "normal"
finances, taxes, and governance, the areas now completely dominated by COBOL
and Java. Rust is a perfect fit for such applications, offering more safety
and security, speed and higher levels of abstraction. Hopefully, formal
verification will arrive soon as well.

[1] [https://github.com/rust-lang/rust/pull/61946](https://github.com/rust-
lang/rust/pull/61946)

[2] [https://internals.rust-lang.org/t/proposal-business-
applicat...](https://internals.rust-lang.org/t/proposal-business-applications-
working-group/10400/2)

~~~
hello_moto
Please don't take this personally.

I think it's great that you wanted to push Rust to the area where Java
flourished (by Java I'm guessing Enterprise?). I respect your passion.

Personally, I never like a language that has esoteric syntax utilizing various
non-alphabetical characters. Perhaps this particular aspect is what drew me to
languages like Java/JavaScript. I don't mind writing "public static void"
because writing code is like 10-20% (the rest is code-review, meeting
stakeholders/Product Owner/PM, come up with plans, write documentations, etc)
of my activity throughout a decade of my career as a Dev.

There are some caveats (or rather ... personal dislike) with Java and
JavaScript for example: I don't like the Closure syntax in Java and I don't
like the fact that JavaScript lacks cohesiveness => People who write ES5 code
do have to implement patterns specific to JS in order to re-create some of the
OOP constructs. ES6 with Class/constructor/static syntax help but then they
added generator via '*' (asterisk, but why? why don't use the keyword 'gen' or
'generator' just like async/await keywords?).

The other thing I realized lately is that I prefer GC platform/ecosystem so
that I can focus less on the platform itself.

~~~
sbov
I'm curious what esoteric syntax utilizing various non-alphabetical characters
you're talking about in Rust? I recently started learning it and nothing jumps
out to me as particularly egregious.

~~~
steveklabnik
There are three ways this objection is usually expressed:

1\. Long ago, Rust had some interesting built in syntax for different kinds of
pointers, and so people checked out Rust then, and didn't realize we got rid
of it. This objection has happened less and less since that was ~5 years ago
(wow time flies), but sometimes it still comes up.

2\. The lifetime syntax uses a single apostrophe, like 'a. We took this syntax
from OCaml (though slightly re-purposed), but if you haven't used OCaml, and
many have not, it can feel very weird.

3\. Not everyone prefers the "curly braces and semicolons" style of systems
languages, and so they feel the <>s and ::s and {}s and ;s are noisy. We kept
this style to be familiar to systems programmers.

In general, Rust doesn't have a lot of unique syntax, but it does draw from
two generally disparate areas: functional languages and systems languages. If
you haven't used both before, some of it can feel strange. It happens.

~~~
asdkhadsj
> 3\. Not everyone prefers the "curly braces and semicolons" style of systems
> languages, and so they feel the <>s and ::s and {}s and ;s are noisy. We
> kept this style to be familiar to systems programmers.

Oh boy do I agree about the noise. I absolutely love Rust, and I definitely
don't think it's noisy _(in normal examples)_ but before I first learned Rust
generic code feat like syntax soup. It seemed bizarrely messy and convoluted.

Mind you, I _love Rust now_. This is not a criticism towards Rust. It's simply
a reflection on how a non-Rust programmer, largely non-Systems programmer saw
Rust's flavor of syntaxes for Generics and Lifetimes.

How time flies. Now I push Rust at work where it makes sense and use it for
everything in my personal _(code)_ life.

My favorite part? Likely how it feels imperative while still offering
functional features. Iterators, for example, are my favorite thing in the
world. This is partially due to system shock I'm sure; the idea of iterators
to this old Go programmer feels like magic haha, it was quite the change
coming from Go.

~~~
0815test
> Oh boy do I agree about the noise. I absolutely love Rust, and I definitely
> don't think it's noisy (in normal examples) but before I first learned Rust
> generic code feat like syntax soup.

What's the alternative? Text-based syntax ala Pascal/Ada is actually _noisier_
than symbol- and short-keyword-based, because you don't ever get to file the
"syntax" parts away as you become familiar with them; you _have_ to process
them visually every time you read that code. There may be a case for that sort
of overly-verbose syntax as a form of literate programming - an introduction
meant for users who are as of yet unfamiliar with any given system; but as an
everyday practice it's quite painful!

~~~
dual_basis
Significant whitespace a la Python.

When I first started learning Python I hated the idea of significant
whitespace, now I think it is the best thing ever.

~~~
0815test
Using rustfmt consistently will get you basically 90% of the way towards the
"Pythonic" benefits of significant whitespace. On the other side, having
lexical block nesting be controlled by an explicit pair of characters { } is a
pretty significant advantage, particularly so for Rust where placing a bit of
code in its own block can have rather significant implications of its own!

------
jackgavigan
Someone has created a Rust crate called libra, which claims to be a "Simple
fantasty Adventure MUD" (sic). It's currently just a "Hello, world!" program.

What are the chances it's a placeholder for malicious/trojan code intended to
steal Libra coins? (c.f. the event-stream backdoor[2])

[1] [https://crates.io/crates/libra](https://crates.io/crates/libra)

[2]
[https://news.ycombinator.com/item?id=18534392](https://news.ycombinator.com/item?id=18534392)

~~~
hombre_fatal
Global unqualified namespace is a classic mistake. Causes all sorts of silly
"squatting" and drama issues.

Should really be:

    
    
        https://crates.io/crates/someorg/libra
        https://crates.io/crates/facebook/libra
    

People like unqualified names because it's slightly cute, though.

~~~
jopsen
The argument I saw was that a global namespace ensured:

A) Packages can change owners without changing names (and breaking
downstreamers)

B) It encourages creative names, rather can calling something myusername/http,
you have to give the package a real name like hyper, express, curl, etc.

~~~
Can_Not
But A) you could still implement giving ownership to another user without
giving the other user your whole namespace and B) why would you even want B?

~~~
jopsen
If you give ownership without changing the organization that owns the package
it then signals trust..

Usually, orgs won't be comfortable with this..

(B) is brilliant... We all know what EC2 and S3 is... If Amazon had just
called these services for: compute and storage, there wouldn't be any brand.

Branding makes things easier to search for and to talk about.

All this said, these downsides might be worth it

~~~
Can_Not
npm install @aws/s3 works for me.

npm install burrito doesn't.

------
steveklabnik
Note that Facebook has also been previously using Rust for
[https://github.com/facebookexperimental/mononoke;](https://github.com/facebookexperimental/mononoke;)
as well as for some smaller things. They've been sponsoring Rust conferences
too.

I am not personally interested in cryptocurrency, but it's always great to see
more big companies using Rust!

~~~
thih9
URL isn't clickable because of a semicolon. This should work:
[https://github.com/facebookexperimental/mononoke](https://github.com/facebookexperimental/mononoke)
.

~~~
steveklabnik
Ugh, thank you.

This is the second time this has happened to me today, you'd think I would
have learned. Sigh.

~~~
kreetx
But it's great that it is in your muscle memory, no linting errors at least :p

------
est31
> We'll need to work together on challenges like tooling

If you wonder what is meant by that, I think I know of an example. They have
done this (quite unusual) choice to not include a Cargo.lock into their
project because it gives a bad developer experience on merge conflicts [1].
They'd love to have a merge tool for the purpose, see more in [2].

[1]:
[https://github.com/libra/libra/issues/52](https://github.com/libra/libra/issues/52)

[2]: [https://github.com/rust-lang/cargo/issues/1818](https://github.com/rust-
lang/cargo/issues/1818)

~~~
qznc
Can cargo report the test coverage yet?

~~~
Arnavion
[https://github.com/mozilla/grcov](https://github.com/mozilla/grcov) though it
requires a nightly rustc for now since it uses some unstable RUSTFLAGS.

~~~
qznc
That is an improvement since the last time I looked. Thanks!

My ideal would be "cargo test --coverage=report/".

------
langitbiru
Bitcoin (Bitcoin Core) is implemented in C++. At that time, Go and Rust
weren't born yet.

The most popular Ethereum implementation (Geth) is written in Go. The second
most popular Ethereum implementation (Parity) is written in Rust.

Now, Libra is written in Rust.

So I guess the moral of the story is, if you want to write a greenfield high
performance application, Go or Rust should be your choice compared to C++.

~~~
saagarjha
> So I guess the moral of the story is, if you want to write a greenfield high
> performance application, Go or Rust should be your choice compared to C++.

I don't see how this generalization follows from the three examples you've
cited?

~~~
ncmncm
Wishful thinking would be my guess.

Rust in production use tends to be found in circumstances where there is no
need for mature tooling, and no expectation of a need to hire experienced
coders. Of course there are exceptions.

~~~
damnyou
It is not that hard for C++ developers to pick up Rust. The borrow checker
makes explicit safety requirements that exist in C++.

The tooling does need to be more mature but for many projects the pioneer tax
paid to improve the tooling may be worth it. Besides, it's not as if C++
dependency management is very mature either — most people build custom tooling
for that anyway.

------
azangru
Surprised it's not OCaml; they've invested highly in OCaml.

~~~
vijaybritto
The primary reason they stated is memory safety as this is gonna be really
critical stuff dealing with money. Also no GC.

~~~
tomp
OCaml is more memory safe than Rust (as the "unsafe" parts are harder to
access). But it does have GC, so GC is likely the primary reason.

~~~
gfs
I wouldn't label Rust as being less safe than OCaml. You have to explicitly
opt-in to any unsafe operations. More often than not, the unsafe blocks are
needed because the compiler can not check all of the invariant cases.

~~~
saagarjha
Does OCaml even have a way of shedding memory safety?

~~~
tomp
Yes, the `Unsafe` module (well, at least used to have it... fairly
undocumented... maybe it's been removed?).

~~~
tomp
Oops, I misremembered the name. @pcwalton is right, it's called `Obj`.

------
novalis78
And Cardano is already working closely with the Haskell community..

------
geodel
Great. I think this is the kind of booster Rust sorely needed.

~~~
ncmncm
When security holes in Libra implementations surface, that will reflect badly
on Rust.

There will of course be explanations why the holes are really not Rust's
fault, and that bugs and security failings are possible in any language, but
it will force a more realistic assessment of Rust's strengths.

~~~
JoshTriplett
There have already been such assessments. For instance, in
[https://hacks.mozilla.org/2019/02/rewriting-a-browser-
compon...](https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-
rust/) , Mozilla estimated that writing a given browser component
(specifically the CSS engine) in Rust, 51 of its 69 security bugs (73.9%)
wouldn't have happened. The other 18 weren't things that the implementation
language doesn't inherently help with.

~~~
blub
The problem with Mozilla's C++ code is that it was developed in a time where
memory-safety was an afterthought and they're still paying for that. Rewriting
it in anything will offer a great opportunity of improving it.

For example, the real fix for their vulnerable code example is using automatic
bounds checking, just as Rust does. Replacing [] with at, eliminates the
vulnerability. Most C++ programmers are allergic to at, so Mozilla could have
created some container wrappers that do this by default. GCC and I think also
clang have a macro which adds automatic bounds-checking to the STL containers.

~~~
JoshTriplett
> Replacing [] with at, eliminates the vulnerability.

And for decades of C and C++ programmers, [] is still the most obvious way to
index an array. And the most obvious way creates potential security
vulnerabilities.

See Rusty Russell's classic "easy to use versus hard to misuse" posts:
[http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html](http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html)
and
[https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html](https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html)
.

~~~
blub
Historically, C and C++ programmers didn't care much about safety, especially
if they had to give up performance to reach it. This is changing in the newest
C++ standards and tooling (e.g. clang's -Wlifetimes).

Bounds checking is slower, so that's the main reason why it's shunned. Rust
made it mandatory, but from what I've seen there are people disabling that to
squeeze some drops of performance nevertheless. Luckily, I think Rust also has
an option of replacing indexing with iteration, thereby avoiding the
performance hit. I think it currently does this a bit better than C++, but I
might be wrong.

Anyway, my critique still stands, that blog post is really low effort and
doesn't prove much. I've looked at some of the fixes for Firefox security bugs
and the code reminds one of the typical older C++ projects with raw pointers
everywhere. Perhaps implementing a browser requires all sorts of unsafe access
patterns.

~~~
JoshTriplett
The Rust compiler can eliminate bounds checking anywhere it can prove that it
doesn't need it. And beyond that, you always have the option of writing an
unsafe block, and people sometimes do in carefully selected cases driven by
profiling. (That also encourages keeping such code carefully contained and
well-scrutinized.)

I'm not arguing that bounds-checking should be mandatory. I'm arguing that
bounds-checking should be the _default_ , and you should have to knowingly
bypass it, rather than the other way around.

------
jvanderbot
Tangential:

Is there an easy way to map all links of form www.reddit.com/* to
old.reddit.com/* on all my devices? (I assume /etc/hosts would work for
linux?)

~~~
est31
[https://addons.mozilla.org/en-US/firefox/addon/old-reddit-
re...](https://addons.mozilla.org/en-US/firefox/addon/old-reddit-redirect/)

[https://chrome.google.com/webstore/detail/old-reddit-
redirec...](https://chrome.google.com/webstore/detail/old-reddit-
redirect/dneaehbmnbhcippjikoajpoabadpodje)

In order to redirect it on all your devices, install Firefox. It can install
extensions on Android, too. Should solve it for everything except smart TVs
(Firefox for Amazon TV can't install extensions) and iOS.

~~~
jvanderbot
Well that's perfect. Thank you.

------
eggy
I wonder if they even considered Ada/SPARK 2014, or are program languages like
fashion trends, and Rust has the runway right now. I like Rust, but I would
think the amount of work that has been put into Ada/SPARK 2014 would make it
the better choice for the problem set.

~~~
steveklabnik
I would imagine that Rust’s advantage over Ada here is in the second
paragraph. I don’t know if they directly considered it or not.

~~~
eggy
Steve, I would agree; you are a large part for that momentum. Community is
important, and the SPARK 2014/Ada community has proven itself to be very
helpful, and has a long history behind it. I know big business decisions are
sometimes made by advocates or evangelists, but you would hope somebody did
their pros/cons matrix on top of that one criteria. SPARK 2014 has really
surprised me in terms of what it brings to the table aside from Ada's legacy,
which is also still evolving.

------
_def
off-topic: do you think it's safe to assume consent of a site's cookie policy
by clicking/scrolling like on [https://libra.org/](https://libra.org/) ? I
actually like it because these banners are just annoying, but I'd be afraid to
do something like this (The first time I checked out that site I only noticed
that something disappeared).

------
adamnemecek
The language of Libre "Move" is inspired by logic. It makes sense that they
would pick a language that is also inspired by linear logic.

------
jammygit
Libra I thought?

------
deltron3030
They want to be t _rust_ ed.

------
seomis
Bruh. It's Li𝘣𝘳𝘢.

------
not_a_cop75
I hate Facebook, but Rust is probably the best possible choice.

