
Rust required to build Gecko - jandem
https://groups.google.com/d/msg/mozilla.dev.platform/Gzwh1IbxvHE/qs49_VAdAwAJ
======
AndrewDucker
Previous discussion:
[https://news.ycombinator.com/item?id=13191129](https://news.ycombinator.com/item?id=13191129)

------
halfdan
Here's a good talk about the history of Rust and how it was developed by
Mozilla to solve problems they had with Gecko:
[https://www.youtube.com/watch?v=79PSagCD_AY](https://www.youtube.com/watch?v=79PSagCD_AY)

~~~
baking
It's a fine talk, but all he ever really says about Gecko is that it was 4.5
million lines of C++.

------
k__
I talked to a guy at Mozilla once and he said they got a pretty instable
build. Some tests take a few runs before you know they are really okay and
don't fail because something is wrong.

Hope Rust will get this problem solved :)

~~~
gcp
The build itself is stable. The testsuites, not so much. The problem is that
written testcases sometimes unwillingly rely on timing or races. When you have
thousands and thousands of tests, as Firefox has, there's a reasonably
likelyhood at least one of them will trigger.

The tests are mostly written in JavaScript, the language Firefox needs to run,
so not much Rust can do there.

~~~
jgraham
To understand the constrains we have here, a ballpark figure is that we run a
million tests per commit across all platforms (this is based on counting test
files, so doesn't account for the fact that some files can contain thousands
of separate test functions, but also doesn't account for the fact that we
don't run every test job on every push). On average we see around 10 test
failures per push due to test instability. So "on average" tests fail about
one time in one hundred thousand. Of course, in reality there are some tests
that fail much more often than this (one time in a hundred, say) and many that
~never fail.

Whilst test raciness is perhaps the most common problem, we also see
intermittent failures due to race conditions in the browser code itself as
well as through infrastructure instability. However it's unclear that moving
to Rust will make much difference anyhow; Servo still sees intermittent tests
so merely eliminating data races in safe code is insufficient to fix this
problem.

~~~
chelmertz
This is a really interesting problem area. Tests that fails sometimes are
really annoying because of the "broken windows" analogy. Are you using the
most unstable tests as input of what to redesign next? Is it kind of a "deal
with it" situation, where you need to retry the test suite a couple of times
per commit, until it becomes green?

~~~
db48x
The test suite doesn't get retried, we just wait for another commit to come
in; it's not generally a long wait. See
[https://treeherder.mozilla.org/#/jobs?repo=mozilla-
inbound](https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound)

Another problem is that running the tests takes ages.

------
westmeal
I always see Rust this and Rust that everywhere. Do people mostly think it's a
trend or does it have it's merits?

~~~
sametmax
IMO, Rust is the most promising technology of the decade.

We had C and C++ for a long time, and never managed to replace them. We
created higher level languages (Haskell, Go, Java) as a mitigation but they
never really succeeded in that domain.

Instead, they found they own favorite tasks, and are used for it. We now have
better tools for other tasks, but C and C++ are still untouched.

Then arrived Rust. Something really low level. Something that is compatible
with C, can do what C does, but better, safer, easier to write. Something with
a terrific community improving the language at an amazing pace.

But what surprise me the most is the professional attitude of rust designers.
They are pragmatic, but promote best practices. They don't get in the heat of
the moment, but are passionate. They listen to the community and yet maintain
a coherent design. They are working meticulously and are very productive.

Those are usually opposite qualities, you only see them joined in attitude of
masters of some sort.

That is amazing to witness.

P.S: I think you need to know at least one very high level language, one very
low, and one specialized in some task if you want to have versatility in your
tool-belt.

I used to recommend Python, C, and one among Go/Erlang/JS/Java/Swift depending
of your tasks.

I think it's time to recommend beginners to learn rust before C (although I
recommend Python before rust). I hope that C will become to the new
generation, what assembly is to us.

~~~
timlyo
>recommend beginners to learn rust before C

This is one thing I've been musing over. Would a beginner see the benefits of
rust without first understanding the drawbacks of C?

In my opinion they'd just see it as "this annoying borrow checker thing" and
find it frustrating.

~~~
pjmlp
> Would a beginner see the benefits of rust without first understanding the
> drawbacks of C?

Better, it would make him aware of C's shortcomings when the time comes to
learn C, instead of getting the wrong idea C is the only path to systems
programming.

I learned systems programming back in the 80's via Assembly, Turbo Basic,
quickly followed by Turbo Pascal.

When the time came to learn C, I was already on Turbo Pascal 6.0, and the
frustrating part was being aware that there was already a better way of
talking to the machine.

Also another point, was that C pointers were never confusing to me, because I
learned the best practices in those languages.

~~~
cd_cd
pj I always detect a degree of "disdain" for C in your comments. Back in the
80s everything was system programming if you wanted performant software. C
replaced Pascal during the 80s because it was a better language - simple as.
Today I code almost entirely in C and rarely need to use Assembly. C started
to be used beyond Unix during the 80s (AmigaOS was written in C except for
third party IO library written in BCPL) because it is a small and very concise
language; Pascal had just too much abstraction - for example how it dealt with
bitwise operations. This meant C compilers could do better jobs in terms of
optimisation. This is reflected in C replacing Pascal in PC game programming
in the late 1980s and early 1990s. Also a lot of Amiga games were also written
in C (Cinemaware games) and Megadrive games too (Sonic Spinball, Ecco etc.).
In short C is just the best HLL out there when it comes to programming systems
with meager resources. As for Rust - like Go - its supporters will eventually
throw in the towel. C is king of system programming.

------
the8472
(2016)

~~~
gcp
I believe the difference is that you can no longer build without Rust. The
original post in that thread talks about requiring it being the default -
those are not the same.

~~~
mkesper
Indeed: If you're maintaining Firefox on a tier-3 platform which doesn't have
good rust support, please be aware that Firefox 53 will be the last upstream
release where rust is optional.

