
When an implementation monoculture might be the right thing - jsnell
https://blog.mozilla.org/nfroyd/2018/05/29/when-implementation-monoculture-right-thing/
======
zokier
> Whereas Firefox engineering is the only “consumer” of the compiler(s), and
> so we should optimize for that single consumer

Seems really shortsighted view. What about distro package maintainers?
Downstream derivatives? Porters to obscure platforms? Random
developers/potential contributors?

~~~
classichasclass
It would, in effect, make gcc (and MSVC) into "obscure platforms," or at least
non-tier-1.

I remember when Mozilla had trouble when they ran out of virtual memory space
in the linker (see
[https://bugzilla.mozilla.org/show_bug.cgi?id=709193](https://bugzilla.mozilla.org/show_bug.cgi?id=709193)
, but this wasn't the first time that happened) and caused serious churn for
the Windows build because Visual Studio was their only option. To be sure,
this was exacerbated because VS was and is a proprietary product, but if
you're going to bet that clang doesn't suffer some similar critical failure in
the future, maybe you shouldn't bet every single tier-1 build of your core
product.

~~~
rebelwebmaster
In fact, Firefox currently can't build with the latest Visual Studio 2017
release due to internal compiler errors.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1458247](https://bugzilla.mozilla.org/show_bug.cgi?id=1458247)

------
stcredzero
What often happens with standards, is that politics rears its ugly head and
they become technically compromised. Some of them become absolutely toothless!
C++ is sufficiently complicated, to the point where the abstractions will leak
and devils will creep in with the few details of the myriads that sneak past,
despite the best efforts of standard writers. Smalltalk is small enough to be
succinctly describable, but politics saddled it with a completely toothless
standard that basically allowed anything.

What's needed are clear, succinct, moderately opinionated standards on clear,
succinct, minimalist technologies.

~~~
blub
C++ was first standardized in 1998, but it was created in 85. The standard is
still changing, today in 2018.

It's easy enough to say what's needed, but is it even possible to have that
for languages with a potential life span of half a century or more?

~~~
reacweb
The Ada95 standard was covering a language far more rich than C++98 (it
included all multitasking and did not rely on C standard). Its level of
clarity and concision is incredible compared to C++98. Both languages were
comparable at that time (same age, same usage).

------
bla2
It's weird how gcc and msvc end up in the same basket here. Mozilla say
they're all about openness. gcc is a free and open source compiler, while msvc
is proprietary and closed source. I can see the case for keeping gcc
supported, but if you don't have to support msvc, why would Mozilla give it
more attention than for example icc?

------
taeric
Monocultures like this interest me. We spent a ton of time in grade school
learning about how monocultures were terrible long term strategies. And yet,
it seems they are actively pursued everywhere. It is easy to see why this is a
problem for biological things. Just look at how close we are to losing the
current bananas most in the US know. I'm pretty sure avocados are the same.

In technology, though, we seem to embrace the monoculture for things.
Languages, implementations, everything. They all seem to converge to a single
one.

I think I understand why this happens in many cases, but I can't help but
shake a feeling that it is off. Indeed, I agree with this blog post, but I
still feel that something is off. Am I alone in that?

~~~
jack9
> Monocultures like this interest me.

Just because they call it a monoculture, doesn't mean it has anything to do
with social behavior per se. It's a technical choice. Might as well ask why
every function isn't implemented in X languages or X styles. Using a singular
tool in a build is the default. It's a surprise to me, that they still were
trying to support a bunch of disparate compilers. Let someone else handle
that, while you run the race of feature implementation, which is hard enough.

~~~
taeric
Your first sentence is confusing to me. Monoculture is not, necessarily, a
social thing. Hence why I mentioned bananas and avocados. :)

That said, I think I agree with your overall point. With the amusing counter
that most new languages do go way the hell out of their way to start
implementing everything. In large to keep you in that language. Even in the
web services world, it amuses me to see so many folks try and cram everything
into a single service where they can.

The flip side, of course, is you do have a finite budge of energy to make
things happen. It makes little sense to spend that budget solving problems you
don't have. Worse, you could rathole into solving technical challenges that
you may never actually have a need to solve. All the while leaving your
customers dry.

So, yes, there is a tradeoff. I fully agree with that. Which is why this topic
is interesting to me. All of the incentives seem to be to embrace monoculture
thinking in most that you do. I can't help but think that is off in the long
view, though. :(

------
whoisthemachine
Glad that decisions such as this get questioned, even if they seem like the
inevitably correct decision. Sometimes engineering choices require uneasy
decisions; ideally you can move forward with those decisions while keeping the
code base cross compiler safe enough to switch to another compiler if needed
in the future.

------
camgunz
I think multiple implementations is more or less a C/C++ thing. If you look at
other platforms (Ruby, Python, PHP, Haskell, Java, Go, Rust, Scala, Lua, Perl)
there's basically _the_ version and maybe some ancillary implementations.

In fairness, it's hard enough to build a language people use that solves real
problems. Asking someone to do it more than once, or to do it once but create
specific enough documentation and tests so someone else can also do it -- and
then get someone else to do it -- is practically impossible.

~~~
mepian
Common Lisp has at least four high-quality implementations (Allegro,
Lispworks, SBCL, Clozure), and this is a fairly large language (thousand
something pages of the ANSI specification + two chapters of AMOP) that is
about as popular as Haskell if not less.

~~~
didibus
Do they all have a differentiator?

~~~
mepian
Allegro and Lispworks are proprietary with product support provided by the
vendors, SBCL and Clozure are opensource. Allegro and Lispworks have their own
IDEs and some proprietary libraries bundled in (e.g. CAPI which is probably
the best option for cross-platform GUI for this language), while SBCL and
Clozure both rely on SLIME and Quicklisp. SBCL produces fastest x86-64 machine
code, as far as I know. Clozure has superior macOS support, as it used to be
owned by Apple before they spun it off and was generally Mac-centric
throughout its history.

------
mwcampbell
Is Mozilla thinking about also using the same C++ standard library (libc++) on
all platforms? Is it even feasible to use libc++ on Windows yet? IIRC, clang-
cl uses the VC++ libraries.

------
JdeBP
I wonder what their thoughts about OpenWatcom C++ and DigitalMars C++ were.

* [https://digitalmars.com/](https://digitalmars.com/)

* [http://openwatcom.org/](http://openwatcom.org/)

------
xvilka
While Clang is definitely good, GCC is quickly developing last years. Since
they want to move everything into Rust, why they care about C++ parts right
now?

~~~
ash_gti
I don't think they will stop using c++ anytime soon.

------
foxhop
It's 2033 and a Mozilla Engineer is writing the same blog post but this time
talking about Firefox adopting webkit...

: |

~~~
sanxiyn
You know what? A Mozilla Engineer did write a blog post talking about Firefox
adopting WebKit... in 2007.

[https://robert.ocallahan.org/2018/01/ancient-browser-wars-
hi...](https://robert.ocallahan.org/2018/01/ancient-browser-wars-history-
md5-hashed.html)

