Mozilla Research is awesome. They punch way way way above their weight.
Google has been pretty influential in PL, especially in the PL/systems domain (MapReduce); just because they aren't designing so many mainstream languages doesn't mean people like Jeff Dean aren't putting their PL skillz to work. In fact, many of the heavy hitters at Google have PL backgrounds and do a lot of PL work, they are just pragmatic and realize that not all PL work involves overtly new languages.
And then there is what Holzle, Bak, Bracha, etc...are doing with Dart; and of course Pike with Go.
Chrome was started off of WebKit, which also has legacy from many years earlier. Both WebKit and Gecko have code that dates to before the year 2000 in fact.
This is pretty much expected for a huge multimillion line C++ codebases, like all web browsers currently are. All have crufty parts (not sure why GP thinks one browser has nicer code overall? That's not my opinion based on the code I've read.)
I love the idea. It will give Rust lots of feedback about real-world, practical problems that arise on large-scale software. I think it will make it all that much more likely that Rust will be an industrial strength systems language.
I think you are looking for an exact quote but the link is to slides of a talk :(
I also agree with the sentiment, but you Architecture Astronaut will no doubt disagree.
You really can't just take a design pattern and apply it blindly across languages. I spend far too much of my time on a C# application where I have to deconstruct anti-patterns and make them more amenable to change.
Runtime performance. This is mostly an LLVM versus GCC thing.
Runtime performance is far more important to us than compiler speed—a fast-to-compile Web browser is useless if it loses to existing engines in UX or benchmarks (every cycle counts!)—but we continue to spend time on compiler speed, because it's important for developers.
The C version is here: http://benchmarksgame.alioth.debian.org/u32/program.php?test... . It appears to be the fastest C verson on the site. The Rust version looks pretty gross (it's likely very old code), I'd like to try porting the C version to Rust (it's only 140 lines) and compare the results. Note also that I'm using a version of the compiler that's so new that it's not even in the official repo yet, containing optimizations for floating-point math.
I never liked Mozilla for a number of experiences:
Their transition from an open source project to an organization receiving millions from the Google search box.
The restrictions (based on security reasons) to install an extension from a site different than mozilla addons. For me this was a prequel of app stores.
Mozilla Thunderbird team had no respect for people who reported bugs: they closed important bug reports.
Lack of respect for extension developers breaking compatibility between versions and not clearly isolating extensions. I remember looking into the TabMix Plus extension and seeing ~40 IFs handling special cases with other extensions.
Lack of a good community (circa 2007) where complex questions were never answered.
>Their transition from an open source project to an organization receiving millions from the Google search box.
I have no problem with this as long as they use the funding to continue producing open source software. I don't think it would be possible for them to compete with Chrome as a pure open source project with no major funding. Mozilla's role since its founding of providing a viable alternative FOSS browser is just as valuable and appreciated now as it was in the IE days, imho.
>The restrictions (based on security reasons) to install an extension from a site different than mozilla addons. For me this was a prequel of app stores.
For a product aimed primarily at easily-duped non-tech lay people, I have no problem with this either. As long as the addons remain FOSS.
>Lack of respect for extension developers breaking compatibility between versions and not clearly isolating extensions.
As a FF user I can live with this, as long as the breaking changes move the browser forward technically, or get rid of some legacy cruft, or similar. It's definitely not in FF's interest either, as it incentivizes users to try other browsers, so I expect it's on their todo list, just maybe not as high a priority as other issues.
The issue is from the developer perspective but also (although invisible) from the user side. Extension developers make titanic work and users can loose some extensions in the way of compatibility. Obviously important brands will never be incompatible but less known extensions will.
I work for Mozilla, but speak for myself. If you think it was about control, then you don't know how Mozilla works. We fight larger players with one arm tied behind our back because of our commitment to making things open and interoperable. We do it gladly, because we know that sometimes our reference implementation won't be the best implementation, and even if we fail, we want the tech to live on. Every day I have or overhear a discussion about making certain what we build doesn't privilege our own solutions over others. Are we perfect at this? No. Sometimes security of our users trumps a completely level playing field. But every time we have to slightly close a technology, know that it's done extremely begrudgingly.