When an implementation monoculture might be the right thing
blog.mozilla.org
blog.mozilla.org
Seems really shortsighted view. What about distro package maintainers? Downstream derivatives? Porters to obscure platforms? Random developers/potential contributors?
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 , 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.
If your plan for MSVC causing issues is to let it be broken with MSVC –– then MSVC is already not a tier-one platform.
And if you're going to avoid failures caused by issues in MSVC, the existence of other compiler options doesn't change the work you have to do to achieve that.
What's needed are clear, succinct, moderately opinionated standards on clear, succinct, minimalist technologies.
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?
Back in the early 2000's Camp Smalltalk folks actually came up with a way to have a "toothy" Smalltalk standard, by using homomorphisms. The idea was that to be an official Smalltalk, you didn't have to have exactly X, Y, and Z, but you needed to have something that could map 1-to-1 to X, Y, and Z. The intention was that "standard" Smalltalks would be able to be automatically translated between one another.
One of factors why such an exercise was plausible, is the extremely minimalist nature of Smalltalk. C++ is huge. The surface area for standard-breaking problems is partly decided by the size of the language, as well as its age and the number of "vendors." We cannot stop time. It's not certain that limiting "vendors" is all good. We can also choose to minimize the size of the language.
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?
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.
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. :(
Currently, Firefox works in a compiler oligopoly. It seems they would prefer a LLVM monopoly for better efficiency.
Btw the Linux kernel only supports GCC, so Mozilla is not alone.
The kernel is an interesting case. It specifically used the free compiler. More, it specifically does not target running on platforms that historically required another compiler.
Though, again, going back to the original point. It is cheaper to build the monoculture. To that point, the risks associated with doing so are not the same as a biological case. Well, they somewhat are, but there is also the risk of development being too expensive not to do this. It all comes back to tradeoffs and this being a decision to make.
I would say there's a pretty straightfoward explanation for that: monocultures are, in general, far easier. Usually (unlike the instant case, where it wasn't an option in the first place), it's even the path of least resistance.
The alternative, diversity, true dirversity, diversity of thought is very difficult. Since it, presumably inevitably, results in conflicting viewpoints, which leads to.. conflict. There doesn't seem to be a good way of handling conflict in collaboritve environments.
Consider the (rhetorical?) question, "Can't we all just get along?"
That is, even though having a monoculture may feel vaguely off, for most people, conflict feels much more intensely off.
In essence, arguing for monocultures is often synonymous with arguing for conflict avoidance or "just getting along".
Are you asserting this is the majority of it? Or just a large portion? Other reasons I could see: a) It is easier to try and reimplement something than to try and build a bridge between old and new. b) Personal preference convinces people their choice in an implementation detail matters. (I mean, it definitely matters at a personal level. But to the end customer? Do they even know?) c) tooling is often very monoculture focused. (Though, this really just goes back to difficulty.)
I'm not necessarily saying that such a thought process would factor in, if it's never consciously brought up.
> a) It is easier to try and reimplement something than to try and build a bridge between old and new.
I've heard this described as "more fun" rather than "easier", though usually that's because the assertion is being used as a criticism.
Still, what do you mean here, by "easier"? If the difficulty in the bridge-building is largely (or entirely) due to a inexpertness, discomfort, or (less charitably) laziness with dealing with different/diverse/old thought, my point still stands.
That said, I agree your point still stands. I was not trying to disprove it, but give it some complimentary points. That is, to help myself understand the point in the fine print, not just at the broad level. That make sense?
I'm not sure I follow what you mean here, though I admit I'm quite inexpert in this area.
My primary exposure/interest (especially in reference to the original topic) is that of a sysadmin who's done building and porting of mostly open source software on diverse Unix platforms and some of the integration of build tools (including compilers) into existing processes... long long ago.
> That make sense?
It does. I don't think we're really disagreeing, either, just exploring the ideas around this.
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.
I don't think this is even remotely true.
On Windows in the 90's we had Borland, Watcom, Microsoft compilers. Today there is at least MSVC and icc.
On Mac there was Think C, Metrowerks Code Warrior, and others.
For embedded systems there are multiple commercial compiler vendors, as well as the open source tools.
I don't know too much about the history of Mac compilers. You may be right.
Back in the days, it was easier to make a competitive C compiler, because the accretion of advantages to the dominant compilers was not so large. Today, the moat is too wide and too deep. There's also no reason to build a new compiler, because nobody is going to pay you for it unless it's substantially better than the free ones, which by this point are pretty damn good.
VLC's windows binaries are also built with mingw-w64 gcc last I checked, that is likely used even more widely than numpy.
Wasn't Apple using their own MPW C compiler?
We extol the virtues of multiple implementations because it makes the ecosystem healthier, but is that even really true? Is Python's ecosystem unhealthy because theres no full alternative to CPython? Is Java's? Is serverside JS?
I generally think we haven't thought through the implications of the virtues of multiple implementations -- mostly I think the opportunity costs are bananas. Platforms that at all approach C/C++'s progress on this issue have longstanding standards committees and corporate-backed engineering teams. It's simply infeasible and a hugely bad decision to build multiple implementations if you don't have that, which, it turns out, almost no language devs do.
> We have a Tech Evangelism bugzilla component for outreach to sites who use techniques that don’t translate across browsers. When new sites appear that deliberately block Firefox (whether because the launch team took the time to test with Firefox and determine the user experience wouldn’t be acceptable, or because cross-browser compatibility was an explicit non-goal), Firefox engineers go find the performance cliffs and fix them. Mozilla has a long-history of promoting the benefits of multiple implementations of the web platform; some of the old guard might remember “Works best in all browsers” campaigns and the like. If you squint properly, you can even see this promotion in the manifesto (principles 2, 5, 6, 7, and 9, by my reckoning).
I think it ends up that sites happen to mostly work in most JS engines because most sites don't do a lot of difficult stuff, and if they do they're using libraries that work pretty hard on cross-browser compatibility. I definitely don't think significant effort is spent targeting Chakra, for example. I think most FEs would laugh at the mere mention. Most I know push back against even considering Firefox compatibility.
Ruby has the Ruby MRI, JRuby, among others. [0] Additionally it spawned a lot of Ruby-like languages on different platforms.
Python has the standard Python (Pick 2 or 3), PyPy, MicroPython, unladen_swallow, Stackless Python, IronPython, Jython, among others [1].
PHP has had the reference implementation, Zend Engine, HipHop and HHVM (Both from Facebook), among others [2].
As another comment mentioned, Javascript has V8, SpiderMonkey, Chakra, and JavascriptCore, all with their own quirks. [3]
[0] https://github.com/cogitator/ruby-implementations/wiki/List-... [1] https://wiki.python.org/moin/PythonImplementations [2] https://en.wikipedia.org/wiki/PHP#Implementations [3] https://en.wikipedia.org/wiki/JavaScript_engine#JavaScript_e...
Or if you want an even better example, look at JS benchmarks for different kinds of loops. Every engine is different. How completely bananas is that. Differences like these are a whole other universe compared to differences in the major C++ compilers.
> A fair amount of work has been done to deal with peculiar bugs in all three compilers: you can go search the source code and/or Bugzilla to find hacks that were needed for one reason or another.
So go search the source code and/or Bugzilla. Treasures await!
The issues that are still open [2] are practically all either a dev didn't test with GCC and got away with things they shouldn't have in clang, or dealing with Apple's ancient version of GCC.
I think this "monoculture" thing is really about MSVC being not that great, which I sympathize with, and which everyone who's ever used MSVC for C or C++ has discovered. But that shouldn't be an excuse to stop using GCC, which is an excellent compiler and has been for generations.
[1] https://bugzilla.mozilla.org/buglist.cgi?short_desc=gcc&reso...
[2] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=gcc
* https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcin...
Now, Clang tries to implement the various GNU extensions, but there are some relatively significant differences. For example, GCC has no problem with a (conditional) goto to a label pointer even if you never took the address of a label anywhere in that function, while Clang treats that as an error, which can be a problem when using macros. Clang also treats _Pragma in macro arguments as you'd expect, while GCC puts all the pragmas before the rest of the code in the macro argument.
Those are just differences I persinally have struggled with, I'm sure there are more.
Compare this with trying to support MSVC, which supports none of the extensions and has a poor track record of getting even the standard stuff straight (especially in the C, not C++, compiler).
By dropping MSVC, you gain a lot of useful language extensions that work with Clang and GCC. For example you get portable SIMD, atomic operations and cache prefetching and a lot of other __builtin features which are unambiguously useful.
The alternative is to support MSVC but then have to maintain some kind of middleware layer to work around compiler incompatibilities. Since the platforms supported by MSVC are already covered by other compilers, you don't gain a lot.
: |
https://robert.ocallahan.org/2018/01/ancient-browser-wars-hi...