5 ms·
For Rust and Go, they're very new languages, so multiple implementations are going to be hard to come by. Although there is gccgo. Some of those you listed thou
by ppseafield 8y ago
For Rust and Go, they're very new languages, so multiple implementations are going to be hard to come by. Although there is gccgo. Some of those you listed though have a lot of different implementations.
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-of-Ruby-implementations https://github.com/cogitator/ruby-implementations/wiki/List-...
[1] https://wiki.python.org/moin/PythonImplementations https://wiki.python.org/moin/PythonImplementations
[2] https://en.wikipedia.org/wiki/PHP#Implementations https://en.wikipedia.org/wiki/PHP#Implementations
[3] https://en.wikipedia.org/wiki/JavaScript_engine#JavaScript_engines https://en.wikipedia.org/wiki/JavaScript_engine#JavaScript_e...
- camgunz 8y agoNone of these (maaaaaybe with the exception of the JS engines) are the same as clang vs. GCC (vs. MSVC), which are mostly equivalent. There are significant compatibility differences between, for example, JRuby and YARV, or Python and PyPy. You can argue compiler extensions and so on, but I think that's out of scope. As far as spec'd C/C++, it's hard to find significant incompatibilities... actually are there any?
- pietroglyph 8y agoThis article specifically references not having to deal with cross-compiler differences as a monoculture advantage. So there are _differences_, perhaps not incompatibilities.
- camgunz 8y agoOP is pretty light on details, but GCC and clang keep up with standards amazingly well (who knows about MSVC). I'm sure there are bugs, but what even are they? Is there a list? It's definitely not at all like the difference between Python and Jython, or even Python 2 and 3. 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.
- sanxiyn 8y agoThe post addresses this. To quote: > 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!
- camgunz 8y agoSo I searched [1] Bugzilla and found 51 issues, none of which are from the last 2 years. There really just isn't an issue with GCC/clang incompatibility with the standard. 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&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=INACTIVE&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&classification=Client%20Software&classification=Components&classification=Server%20Software&classification=Other&classification=Graveyard&query_format=advanced&bug_status=RESOLVED&bug_status=CLOSED&short_desc_type=allwordssubstr&component=Activity%20Streams%3A%20Application%20Servers&component=Activity%20Streams%3A%20General&component=Activity%20Streams%3A%20Newtab&component=Activity%20Streams%3A%20Server%20Operations&component=Activity%20Streams%3A%20Timeline&component=Address%20Bar&component=Bookmarks%20%26%20History&component=Build%20Config&component=Developer%20Tools&component=Developer%20Tools%3A%20about%3Adebugging&component=Developer%20Tools%3A%20Accessibility%20Tools&component=Developer%20Tools%3A%20Animation%20Inspector&component=Developer%20Tools%3A%20Application%20Panel&component=Developer%20Tools%3A%20Canvas%20Debugger&component=Developer%20Tools%3A%20Computed%20Styles%20Inspector&component=Developer%20Tools%3A%20Console&component=Developer%20Tools%3A%20CSS%20Rules%20Inspector&component=Developer%20Tools%3A%20Debugger&component=Developer%20Tools%3A%20DOM&component=Developer%20Tools%3A%20Font%20Inspector&component=Developer%20Tools%3A%20Framework&component=Developer%20Tools%3A%20Graphic%20Commandline%20and%20Toolbar&component=Developer%20Tools%3A%20Inspector&component=Developer%20Tools%3A%20JSON%20Viewer&component=Developer%20Tools%3A%20Layout%20Frame%20Inspector&component=Developer%20Tools%3A%20Measuring%20Tool&component=Developer%20Tools%3A%20Memory&component=Developer%20Tools%3A%20Netmonitor&component=Developer%20Tools%3A%20Object%20Inspector&component=Developer%20Tools%3A%20Performance%20Tools%20%28Profiler%2FTimeline%29&component=Developer%20Tools%3A%20Responsive%20Design%20Mode&component=Developer%20Tools%3A%20Scratchpad&component=Developer%20Tools%3A%20Shared%20Components&component=Developer%20Tools%3A%20Source%20Editor&component=Developer%20Tools%3A%20Storage%20Inspector&component=Developer%20Tools%3A%20Style%20Editor&component=Developer%20Tools%3A%20Web%20Audio%20Editor&component=Developer%20Tools%3A%20WebGL%20Shader%20Editor&component=Developer%20Tools%3A%20WebIDE&component=Device%20Permissions&component=Disability%20Access&component=Distributions&component=Downloads%20Panel&component=Enterprise%20Policies&component=Extension%20Compatibility&component=File%20Handling&component=Firefox%20Accounts&component=Foxfooding&component=General&component=Headless&component=Installer&component=Keyboard%20Navigation&component=Menus&component=Migration&component=New%20Tab%20Page&component=Normandy%20Client&component=Normandy%20Server&component=Page%20Info%20Window&component=PDF%20Viewer&component=Pocket&component=Preferences&component=Private%20Browsing&component=Remote%20Settings%20Client&component=RSS%20Discovery%20and%20Preview&component=Screen%20Sharing%20Whitelist&component=Screenshots&component=Search&component=Security&component=Security%3A%20Review%20Requests&component=Session%20Restore&component=Shell%20Integration&component=Site%20Identity%20and%20Permission%20Panels&component=SocialAPI&component=SocialAPI%3A%20Providers&component=Sync&component=Tabbed%20Browser&component=Theme&component=Toolbars%20and%20Customization&component=Tours&component=Tracking%20Protection&component=Translation&component=Untriaged&component=WebPayments%20UI&product=Firefox https://bugzilla.mozilla.org/buglist.cgi?short_desc=gcc&reso... [2] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=gcc https://bugzilla.mozilla.org/buglist.cgi?quicksearch=gcc
- mort96 8y agoClang and GCC will generally compile standard C/C++ code just fine, but they add their own extensions to the language. I'd bet a lot of C or C++ projects assume `void` has a size of 1 in pointer arithmetic, for example. Try compiling some projects with -Wpedantic. 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.
- exDM69 8y agoWhile there are differences between Clang and GCC language extensions, most of them are compatible or at least can be worked around with some relatively trivial hacks. 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.