12 ms·

Mozilla and Samsung Collaborate on Next Generation Web Browser Engine

368 points by dave1010uk 14y ago

dave1010uk 14y ago
While this mentions Android, I think the biggest winners in this could be Mozilla and Samsung's own mobile OS's: Firefox OS and Tizen respectively. I'm hoping that if they're collaborating on Servo then the 2 platforms will hopefully become fairly interoperable (in terms of app portability). Some further details about Servo and Rust can be found here: http://www.mozilla.org/en-US/research/projects/ http://www.mozilla.org/en-US/research/projects/
- vitno 14y ago
  what apps? :D The whole idea behind firefox OS is the "open web", all "apps" are standards-compliant javascript. App portability shouldn't be much of a problem.
  - MatthewPhillips 14y ago
    That's not true, both Firefox OS and Tizen use many not-yet-standard APIs. Luckily they are collaborating on many of these APIs and they will be interoperable.
    - vitno 14y ago
      Right, but they are all in the process of being standardized. The idea behind them is that they WILL be written using standardized APIs
      - MatthewPhillips 14y ago
        That doesn't help with portability though. Tizen apps and Firefox OS apps have to be constructed in such a way (by abstracting away the not-standard APIs) to make them portable. You don't get that for free.
        thelukester 14y ago
        Throughout its history, HTML has always been a disaster when it comes to cross browser interoperability. Apps have always been desinged for the vogue browser, which has changed from Netscape to IE to webkit now. The more you abstract, the more functionality you lose and the more generic your mobile apps will look. Facebook learned this lesson the hard way when they tried to make their mobile App in HTML5. CSS, javascript, and DOM are just kudge piled upon kludge. HTML5 trying to shoehorn poorly thought out technologies created for hyperlinked static text documents into dynamic applications. Until some disruptive technology completely replaces that massive HTML5 spec you speak of, the natives apps will always rule the mobile space and performance critical spaces.
        fpgeek 14y ago
        I suspect you get portability to Firefox for Android for (nearly) free. That's a decent start at the very least (and an important proof-of-concept for other Android browsers).
        vidarh 14y ago
        The point is the goal is to make all of these API's standardised. Of course you will always have portability issues if you use the newest possible API's as someone will always be first out with an implementation. By the time FirefoxOS has any traction, it is likely a lot of these API's will have additional implementations and/or suitable "polyfills". That'd already put it in a better position out of the gate than Android or iOS in terms of portability.
- ajross 14y ago
  A browser engine is an awfully portable thing. For a consumer, switching between them (e.g. from Firefox to Safari, whatever) is just a question of minor UI skinning. I don't see that it "benefits" any OS in particular. Assuming it's universally better, Android and Tizen would need to port from WebKit and Firefox from Gecko. If it confers a true competitive advantage, they'll all do it. If not, some probably won't. For myself, I'm skeptical. There's really nothing "wrong enough" with Gecko or WebKit that I can see another option really being that much better. Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused. But I'm willing to be proven wrong.
  - coldtea 14y ago
    >Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused. Actually your examples nullify your argument. Mozilla would be dead today without Gecko, ie with the old Netscape code piled. KHTML would have gone nowhere much if it wasn't for the Webkit rewrite. So in both cases, it was the rewrites that made those engines break out.
    - ZeroGravitas 14y ago
      And KHTML itself can be (and was, by many) regarded as a pointless rewrite of Gecko, which seems crazy now we're aware of its impact.
      - Samuel_Michon 14y ago
        Surely the impact of Webkit has been greater than that of Gecko? Webkit made decent mobile browsing possible, and until recently Gecko wasn't available in mobile browsers. Gecko did put a dent in desktop browser usage share early on (when Safari was Mac-only, and Safari for Windows has never caught on – for good reasons), but the desktop is quickly becoming the second screen. Nowadays, most sites are built for Webkit first.
MatthewPhillips 14y ago
This will be a big win for faster web apps. DOM performance is the biggest blocker to having a smooth experience in the browser nowadays, not JavaScript speed.
- neoeldex 14y ago
  IMO not the performance of DOM but the DOM itself is the biggest blocker to a good experience (user and dev)
  - coldtea 14y ago
    In what sense? And what do you propose replaces it?
    - lenkite 14y ago
      The DOM should have been a cursor based or perhaps a pull-based API. Everything being an in-memory tree was OK a decade ago but not today the node count in the millions across browser tabs. Dom funcions could have been generic ala C++ STL style for iteration restrictions
      - tantalor 14y ago
        Your comment surprises me. Maybe I don't undertand the DOM as well as you? I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement. You have to query it, right? Of course you can query for the same element multiple times, so it's not cursor-based. But the engine can generate the tree in response to user queries instead of storing the entire tree in memory. What do you mean by pull-based API?
        vinayan3 14y ago
        [quote]I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement.[/quote] Yes it is not a requirement. What browser have you heard of storing in the tree in something else than memory? Imagine if the browser used a the disk to store parts of the tree.
surrealize 14y ago
Servo is a "high-risk research project"[1], so I've been wondering what would happen if it doesn't pan out. Rust would still be interesting even without Servo, but would mozilla still invest in Rust if they stopped working on Servo? So it's nice to see some non-mozilla involvement and momentum in Rust/Servo. Maybe that means that an investment in learning/using Rust is that much less risky :) [1] http://www.mail-archive.com/dev-servo@lists.mozilla.org/msg00111.html http://www.mail-archive.com/dev-servo@lists.mozilla.org/msg0...
- the_mitsuhiko 14y ago
  Rust is interesting enough that I'm pretty sure it will do with or without Servo.
- nsmartt 14y ago
  I can't see Mozilla abandoning Rust. If nothing else, it's valuable as a learning experience for all involved.
  - saraid216 14y ago
    Being described as a "learning experience" usually indicates that a project was just scrapped.
    - nsmartt 14y ago
      I meant that it can be called a learning experience to justify further development. Besides, Rust is genuinely useful. I can't be the only one who is interested in (eventually) using it as my go-to language for my projects.
      - pnathan 14y ago
        You aren't. Personally, once Rust stabilizes as a language, I plan to write the bulk of my "low level" at-home code in Rust. After tooling support gets up there (providing things are still awesome), I plan to use it professionally.
paddy_m 14y ago
This is really exciting. I'm glad to see rust being used for serious apps. This is actually the first new browser engine that I know of being written in the past 10 years. Good for Mozilla for attempting hard problems in innovative ways.
- hobbyist 14y ago
  I am not well-versed in the browser designs, could you highlight what hard problems are you referring to?
  - kibwen 14y ago
    Check out the high-level overview of Servo's design: https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design The goal is extremely pervasive concurrency in aspects that no modern engine has yet begun to approach (and likely could not approach without enormous effort and/or a full-on rewrite).
    - jerf 14y ago
      You can drop the "likely". Retrofitting pervasive concurrency onto a sizable existing codebase is to a first approximation impossible. It makes merely trying to retrofit pervasive unit testing (hard, but "merely" a long mechanical slog) or correctness with string encoding a cake walk. "Impossible" here can be taken to read as "would require as much effort to do the retrofit as the rewrite would take".
    - shawn-butler 14y ago
      >> Because C++ is poorly suited to preventing these problems, It is really hard to take seriously any project that has this kind of nonsense in its introduction.
      - eruditely 14y ago
        This says more about you than the quality of the project.
pjmlp 14y ago
Nice to see Rust gaining traction. We need to have more safe alternatives for systems programming.
msutherl 14y ago
It's awesome that language design is being promoted as a significant part of this project. Good design from the ground up.
leeoniya 14y ago
Samsung is really making good use of the hacker community. They hired Cyanogenmod lead dev last year to collab on Android, too.
- smacktoward 14y ago
  It was back in 2011. And he's already moved on: http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-kondik-departs-samsung http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-kon...
  - leeoniya 14y ago
    wow, funny coincidence that news just broke a few days ago. good to know.
- g8oz 14y ago
  Also Rasterman from the Enlightenment project
  - fafner 14y ago
    Not only Rasterman. They seem to have hired a lot of Enlightenment developers.
- Avshalom 14y ago
  It's worht pointing out that in addition to any actual software Samsung might get from this, compared to a global advertising campaign this is a bargain in the form of dev goodwill->dev mindshare->general mindshare. I'm frequently reminded of the spokesperson for the old US Army game pointing out that the 40 million dev cost was ~ one 30 second spot during the superbowl.
_pmf_ 14y ago
What's in this madness for Samsung?
- dave1010uk 14y ago
  My guess is it may reduce their dependence on WebKit, which is mostly "controlled" (for want of a better word) by Apple and Google, their main competitors.
  - icambron 14y ago
    "Driven" would be my choice of words there.
    - leoc 14y ago
      'Controlled' is honestly pretty accurate. In principle anyone can fork WebKit; in practise it would take major investments on the three fronts of engineering effort, standards politics and mass user adoption to make a WebKit fork that "matters" - one that web designers would worry, and have to worry, about being compatible with. If you don't have both the resources and the desire to do that, then you have to play nice with Apple and Google - or with one of their two remaining competitors.
  - sanxiyn 14y ago
    I think this is the best guess.
  - Samuel_Michon 14y ago
    Quite right. Like Apple is trying to become less dependent on Samsung, Samsung is trying to become less dependent on Google.
- fudged71 14y ago
  Reduced dependence on Google browsers for their phones. They have been providing their own proprietary redundant solutions that overlap Google's software territory on mobile, for their own devices. This is just another step. And it gives them the opportunity to integrate with Mozilla to perhaps have a phone using their OS instead of Android in the far future.
ksec 14y ago
I am actually surprise this pieces was written by Brendan, given the way Mozilla has been moving lately with asm.js, PDF.js and Shumway which is like Flash.js; It wouldn't be surprise if their Next Goal were to built the Entire ( or Most of ) Browser with Javascript. I am surprised that Samsung decide to help. Which basically reads to me as relationship with Google is going pretty bad or they are simply hedging their bet. It was only earlier today I posted that Yahoo should also have a few engineers helping Mozilla to develop Servo. And i really really hope Servo is licensed like Rust, Dual MIT + Apache 2.0
- kibwen 14y ago
  Here's the ticket regarding Servo's license, be sure to weigh in if you feel strongly about it: https://github.com/mozilla/servo/issues/45 https://github.com/mozilla/servo/issues/45
- ConstantineXVI 14y ago
  Google pays Mozilla to push Google Search, not to develop a browser (which Google can do just fine on their own). It doesn't really mean much that they're teaming with Samsung for Servo, other than Samsung's taken an interest in using Servo for their own products. Note it's not mentioned exactly which division of Samsung they're working with; they may want Servo for Tizen, their Smart TVs, to ensure it plays nice with Exynos, or none of the above. [EDIT: the post explicitly mentions porting Rust and Servo to Android and ARM; which rather strongly suggests the mobile group. Interesting, as FirefoxOS and Tizen are more or less aimed at the same markets]
  - bsimpson 14y ago
    But it does say that Samsung is responsible for Servo for Android.
  - sanxiyn 14y ago
    I think it is "none of the above". Servo, right now, is cloudcuckooland stuff; this suggests it is a long bet research, not tied to any particular product division. Samsung probably has Tizen, Smart TV, Exynos in mind, so you could equall say "all of the above", but I think "none of the above" is more accurate description.
mtgx 14y ago
To people wondering why Samsung would join this, I think Samsung is a big believer in the HSA Foundation [1] for heterogeneous computing, and they were one of the first partners in this along with AMD and ARM. Samsung seems to believe in having the best performing devices and components, so it's not that surprising that they want to be at the forefront of the heterogeneous computing movement. They also probably see themselves as a competitor against Intel, with both the ARM ISA that they support and the foundry that they own. In the next few years there will be a battle between HSA and Intel's Phi co-processor idea, and I think Samsung is one of the many who wants HSA to succeed (using computing power from all sorts of processors vs using only CPU's for everything). http://hsafoundation.com http://hsafoundation.com
- sanxiyn 14y ago
  This is a great story, but probably not the case. I would be surprised if the part of Samsung responsible for HSA is even aware of Rust, let alone Samsung is working on Rust. The semiconductor division is pretty independent of other divisions.
  - hkmurakami 14y ago
    In particular the System LSI group. http://www.samsung.com/global/business/semiconductor/aboutus/business/overview http://www.samsung.com/global/business/semiconductor/aboutus...
cromwellian 14y ago
I'm no lover of C++, but I'm skeptical that it's really that much more difficult to achieve this design in C++. The parallelism shown is still fairly coarse grained and amenable to traditional techniques. It may be more convenient or less bug prone with Rust, but I read as more substantial, the redesign and rewrite from the ground up. If the redesign was using C/C++, they'd likely get the same benefits, just with uglier code. Isn't it more likely that lessons learned in Servo will simply be back-ported to C++ in Firefox?
- sanxiyn 14y ago
  Yes, I think that is more likely.
- smosher 14y ago
  You can write equivalent programs in C++, but if you learned Rust well I am not sure you'd want to. The parallelism shown is still fairly coarse grained and amenable to traditional techniques. [...] If the redesign was using C/C++, they'd likely get the same benefits, just with uglier code. I should hope so, Rust's parallelism is nothing new after all! (Okay, I know, you probably mean by writing programs using explicit mutexes and all that.) I really want to talk about the second part of the quote: what exactly are those benefits? I think you've excluded safety for some reason. If Servo offers competitive performance I think it's most likely the whole engine will simply replace Gecko. I mean why would you spend the time and money to go from the safer to the less-safe code when you can use what you've got?
  - cromwellian 14y ago
    There's obviously benefits in using better languages for safety and error checking, it's one of the reasons why I like Closure Annotations/GWT/Dart over raw Javascript because of my experience on large projects and relatively simplistic bugs silently propagating through. The traditional response to these kind of language imperfections is "better tests, better practices". Otherwise as, Unit Tests solve all problems. For C++, someone would say to use some set of abstractions or static analysis tools that confers additional safety that isn't available in the out-of-the-box language. Language level support tends to encourage more consistent usage of something than just depending on vigilance. My metapoint though, is that large code bases are hard to displace, especially if the enduser benefits can be achieved through iteration. Rewriting Gecko from scratch in Rust is a tall order, considering how long it took Gecko and WebKit to get to where they are now. It seems much more likely that WebKit/Gecko can be refactored to get most of the benefits in a much shorter period of time than a rewrite.
ChuckMcM 14y ago
This is a great announcement and adds some much needed support to Servo/Rust. I've been pretty impressed with Samsung too. Clearly they want to have their own seat at the table and they are executing quite well on that desire.
- fudged71 14y ago
  I'm not confident that Samsung is interested in developing the Android platform, though. They seem to be working on a proprietary ecosystem to separate themselves from the rest of the Android ecosystem. In fact, this is probably one of their motivations: to have control over a leading browser that isn't Chrome so that they can integrate it into their phones as default instead of Google's solution.
  - ChuckMcM 14y ago
    Actually if Samsung wants to be a player I really think they can't afford to be tied to Android long term. Too much control at Google and Google is another player and nominally an 'opponent' at some point. Of course their is "Android" and there is the stuff that Google puts around it. Watching the Chinese companies add value to the OS install has been instructive as well. What Android has done has shown the component manufacturers some ways to expand their markets outside "known" players. Part of the challenge of making a phone is getting the chip vendors willing to sign off on giving you software to run their chips (weird I know).
    - kragen 14y ago
      That sounds interesting — what kind of value are the Chinese companies adding?
      - meric 14y ago
        Check it out: http://en.miui.com http://en.miui.com
        14y ago
ancarda 14y ago
Any idea when Servo might make it into Firefox desktop builds?
- Ygg2 14y ago
  A rough guesstimate would be five to ten years. Don't hold your breath either way. Right now Rust is not very optimized and still in flux, while Servo is pretty much a black box for me.
jusben1369 14y ago
"X is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web." Probably says more about how long I've been around but I think I've read a mostly similar paragraph 5 to 6 times over the last decade.
- SoftwareMaven 14y ago
  And, in the past decade, we've seen the web browsers make significant leaps in security and capabilities. I'm happy to have more of the same.
- raldi 14y ago
  Mozilla, Firefox, Chrome, Safari, and I think one of the IE's too. And now this. So yeah, 5-6 is a good estimate. Edit: Also the original Netscape.
  - fzzzy 14y ago
    None of those were from the ground up. Mozilla was based on the netscape codebase, firefox was based on the mozilla codebase, safari was based on the khtml codebase, and chrome was based on the webkit codebase. IE I'm not sure about, but it seems unlikely that they started from the ground up, surely newer ie uses code from older releases.
    - lifthrasiir 14y ago
      Unless there are actually multiple layout engines developed by Microsoft. At least three (Trident, Tasman and some other used by Expression Web) of them are known, and it is entirely possible that they don't share the common codebase.
    - fpgeek 14y ago
      You're right. Internet Explorer was originally based on Spyglass Mosaic. [1] [1] http://en.wikipedia.org/wiki/History_of_Internet_Explorer http://en.wikipedia.org/wiki/History_of_Internet_Explorer
adamisen 14y ago
If Google is paying Apple $1B/yr to be the default search engine on iOS, it stands to reason that Samsung could negotiate similar per device rates. That seems like enough potential upside for this to be a no-brainer to me.

368 points by dave1010uk 14y ago

While this mentions Android, I think the biggest winners in this could be Mozilla and Samsung's own mobile OS's: Firefox OS and Tizen respectively. I'm hoping that if they're collaborating on Servo then the 2 platforms will hopefully become fairly interoperable (in terms of app portability). Some further details about Servo and Rust can be found here: http://www.mozilla.org/en-US/research/projects/ http://www.mozilla.org/en-US/research/projects/

vitno 14y ago
what apps? :D The whole idea behind firefox OS is the "open web", all "apps" are standards-compliant javascript. App portability shouldn't be much of a problem.
- MatthewPhillips 14y ago
  That's not true, both Firefox OS and Tizen use many not-yet-standard APIs. Luckily they are collaborating on many of these APIs and they will be interoperable.
  - vitno 14y ago
    Right, but they are all in the process of being standardized. The idea behind them is that they WILL be written using standardized APIs
    - MatthewPhillips 14y ago
      That doesn't help with portability though. Tizen apps and Firefox OS apps have to be constructed in such a way (by abstracting away the not-standard APIs) to make them portable. You don't get that for free.
      - thelukester 14y ago
        Throughout its history, HTML has always been a disaster when it comes to cross browser interoperability. Apps have always been desinged for the vogue browser, which has changed from Netscape to IE to webkit now. The more you abstract, the more functionality you lose and the more generic your mobile apps will look. Facebook learned this lesson the hard way when they tried to make their mobile App in HTML5. CSS, javascript, and DOM are just kudge piled upon kludge. HTML5 trying to shoehorn poorly thought out technologies created for hyperlinked static text documents into dynamic applications. Until some disruptive technology completely replaces that massive HTML5 spec you speak of, the natives apps will always rule the mobile space and performance critical spaces.
      - fpgeek 14y ago
        I suspect you get portability to Firefox for Android for (nearly) free. That's a decent start at the very least (and an important proof-of-concept for other Android browsers).
      - vidarh 14y ago
        The point is the goal is to make all of these API's standardised. Of course you will always have portability issues if you use the newest possible API's as someone will always be first out with an implementation. By the time FirefoxOS has any traction, it is likely a lot of these API's will have additional implementations and/or suitable "polyfills". That'd already put it in a better position out of the gate than Android or iOS in terms of portability.
ajross 14y ago
A browser engine is an awfully portable thing. For a consumer, switching between them (e.g. from Firefox to Safari, whatever) is just a question of minor UI skinning. I don't see that it "benefits" any OS in particular. Assuming it's universally better, Android and Tizen would need to port from WebKit and Firefox from Gecko. If it confers a true competitive advantage, they'll all do it. If not, some probably won't. For myself, I'm skeptical. There's really nothing "wrong enough" with Gecko or WebKit that I can see another option really being that much better. Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused. But I'm willing to be proven wrong.
- coldtea 14y ago
  >Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused. Actually your examples nullify your argument. Mozilla would be dead today without Gecko, ie with the old Netscape code piled. KHTML would have gone nowhere much if it wasn't for the Webkit rewrite. So in both cases, it was the rewrites that made those engines break out.
  - ZeroGravitas 14y ago
    And KHTML itself can be (and was, by many) regarded as a pointless rewrite of Gecko, which seems crazy now we're aware of its impact.
    - Samuel_Michon 14y ago
      Surely the impact of Webkit has been greater than that of Gecko? Webkit made decent mobile browsing possible, and until recently Gecko wasn't available in mobile browsers. Gecko did put a dent in desktop browser usage share early on (when Safari was Mac-only, and Safari for Windows has never caught on – for good reasons), but the desktop is quickly becoming the second screen. Nowadays, most sites are built for Webkit first.

MatthewPhillips 14y ago

This will be a big win for faster web apps. DOM performance is the biggest blocker to having a smooth experience in the browser nowadays, not JavaScript speed.

neoeldex 14y ago
IMO not the performance of DOM but the DOM itself is the biggest blocker to a good experience (user and dev)
- coldtea 14y ago
  In what sense? And what do you propose replaces it?
  - lenkite 14y ago
    The DOM should have been a cursor based or perhaps a pull-based API. Everything being an in-memory tree was OK a decade ago but not today the node count in the millions across browser tabs. Dom funcions could have been generic ala C++ STL style for iteration restrictions
    - tantalor 14y ago
      Your comment surprises me. Maybe I don't undertand the DOM as well as you? I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement. You have to query it, right? Of course you can query for the same element multiple times, so it's not cursor-based. But the engine can generate the tree in response to user queries instead of storing the entire tree in memory. What do you mean by pull-based API?
      - vinayan3 14y ago
        [quote]I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement.[/quote] Yes it is not a requirement. What browser have you heard of storing in the tree in something else than memory? Imagine if the browser used a the disk to store parts of the tree.

surrealize 14y ago

Servo is a "high-risk research project"[1], so I've been wondering what would happen if it doesn't pan out. Rust would still be interesting even without Servo, but would mozilla still invest in Rust if they stopped working on Servo? So it's nice to see some non-mozilla involvement and momentum in Rust/Servo. Maybe that means that an investment in learning/using Rust is that much less risky :) [1] http://www.mail-archive.com/dev-servo@lists.mozilla.org/msg00111.html http://www.mail-archive.com/dev-servo@lists.mozilla.org/msg0...

the_mitsuhiko 14y ago
Rust is interesting enough that I'm pretty sure it will do with or without Servo.
nsmartt 14y ago
I can't see Mozilla abandoning Rust. If nothing else, it's valuable as a learning experience for all involved.
- saraid216 14y ago
  Being described as a "learning experience" usually indicates that a project was just scrapped.
  - nsmartt 14y ago
    I meant that it can be called a learning experience to justify further development. Besides, Rust is genuinely useful. I can't be the only one who is interested in (eventually) using it as my go-to language for my projects.
    - pnathan 14y ago
      You aren't. Personally, once Rust stabilizes as a language, I plan to write the bulk of my "low level" at-home code in Rust. After tooling support gets up there (providing things are still awesome), I plan to use it professionally.

paddy_m 14y ago

This is really exciting. I'm glad to see rust being used for serious apps. This is actually the first new browser engine that I know of being written in the past 10 years. Good for Mozilla for attempting hard problems in innovative ways.

hobbyist 14y ago
I am not well-versed in the browser designs, could you highlight what hard problems are you referring to?
- kibwen 14y ago
  Check out the high-level overview of Servo's design: https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design The goal is extremely pervasive concurrency in aspects that no modern engine has yet begun to approach (and likely could not approach without enormous effort and/or a full-on rewrite).
  - jerf 14y ago
    You can drop the "likely". Retrofitting pervasive concurrency onto a sizable existing codebase is to a first approximation impossible. It makes merely trying to retrofit pervasive unit testing (hard, but "merely" a long mechanical slog) or correctness with string encoding a cake walk. "Impossible" here can be taken to read as "would require as much effort to do the retrofit as the rewrite would take".
  - shawn-butler 14y ago
    >> Because C++ is poorly suited to preventing these problems, It is really hard to take seriously any project that has this kind of nonsense in its introduction.
    - eruditely 14y ago
      This says more about you than the quality of the project.

pjmlp 14y ago

Nice to see Rust gaining traction. We need to have more safe alternatives for systems programming.

msutherl 14y ago

It's awesome that language design is being promoted as a significant part of this project. Good design from the ground up.

leeoniya 14y ago

Samsung is really making good use of the hacker community. They hired Cyanogenmod lead dev last year to collab on Android, too.

smacktoward 14y ago
It was back in 2011. And he's already moved on: http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-kondik-departs-samsung http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-kon...
- leeoniya 14y ago
  wow, funny coincidence that news just broke a few days ago. good to know.
g8oz 14y ago
Also Rasterman from the Enlightenment project
- fafner 14y ago
  Not only Rasterman. They seem to have hired a lot of Enlightenment developers.
Avshalom 14y ago
It's worht pointing out that in addition to any actual software Samsung might get from this, compared to a global advertising campaign this is a bargain in the form of dev goodwill->dev mindshare->general mindshare. I'm frequently reminded of the spokesperson for the old US Army game pointing out that the 40 million dev cost was ~ one 30 second spot during the superbowl.

_pmf_ 14y ago

What's in this madness for Samsung?

dave1010uk 14y ago
My guess is it may reduce their dependence on WebKit, which is mostly "controlled" (for want of a better word) by Apple and Google, their main competitors.
- icambron 14y ago
  "Driven" would be my choice of words there.
  - leoc 14y ago
    'Controlled' is honestly pretty accurate. In principle anyone can fork WebKit; in practise it would take major investments on the three fronts of engineering effort, standards politics and mass user adoption to make a WebKit fork that "matters" - one that web designers would worry, and have to worry, about being compatible with. If you don't have both the resources and the desire to do that, then you have to play nice with Apple and Google - or with one of their two remaining competitors.
- sanxiyn 14y ago
  I think this is the best guess.
- Samuel_Michon 14y ago
  Quite right. Like Apple is trying to become less dependent on Samsung, Samsung is trying to become less dependent on Google.
fudged71 14y ago
Reduced dependence on Google browsers for their phones. They have been providing their own proprietary redundant solutions that overlap Google's software territory on mobile, for their own devices. This is just another step. And it gives them the opportunity to integrate with Mozilla to perhaps have a phone using their OS instead of Android in the far future.

ksec 14y ago

I am actually surprise this pieces was written by Brendan, given the way Mozilla has been moving lately with asm.js, PDF.js and Shumway which is like Flash.js; It wouldn't be surprise if their Next Goal were to built the Entire ( or Most of ) Browser with Javascript. I am surprised that Samsung decide to help. Which basically reads to me as relationship with Google is going pretty bad or they are simply hedging their bet. It was only earlier today I posted that Yahoo should also have a few engineers helping Mozilla to develop Servo. And i really really hope Servo is licensed like Rust, Dual MIT + Apache 2.0

kibwen 14y ago
Here's the ticket regarding Servo's license, be sure to weigh in if you feel strongly about it: https://github.com/mozilla/servo/issues/45 https://github.com/mozilla/servo/issues/45
ConstantineXVI 14y ago
Google pays Mozilla to push Google Search, not to develop a browser (which Google can do just fine on their own). It doesn't really mean much that they're teaming with Samsung for Servo, other than Samsung's taken an interest in using Servo for their own products. Note it's not mentioned exactly which division of Samsung they're working with; they may want Servo for Tizen, their Smart TVs, to ensure it plays nice with Exynos, or none of the above. [EDIT: the post explicitly mentions porting Rust and Servo to Android and ARM; which rather strongly suggests the mobile group. Interesting, as FirefoxOS and Tizen are more or less aimed at the same markets]
- bsimpson 14y ago
  But it does say that Samsung is responsible for Servo for Android.
- sanxiyn 14y ago
  I think it is "none of the above". Servo, right now, is cloudcuckooland stuff; this suggests it is a long bet research, not tied to any particular product division. Samsung probably has Tizen, Smart TV, Exynos in mind, so you could equall say "all of the above", but I think "none of the above" is more accurate description.

mtgx 14y ago

To people wondering why Samsung would join this, I think Samsung is a big believer in the HSA Foundation [1] for heterogeneous computing, and they were one of the first partners in this along with AMD and ARM. Samsung seems to believe in having the best performing devices and components, so it's not that surprising that they want to be at the forefront of the heterogeneous computing movement. They also probably see themselves as a competitor against Intel, with both the ARM ISA that they support and the foundry that they own. In the next few years there will be a battle between HSA and Intel's Phi co-processor idea, and I think Samsung is one of the many who wants HSA to succeed (using computing power from all sorts of processors vs using only CPU's for everything). http://hsafoundation.com http://hsafoundation.com

sanxiyn 14y ago
This is a great story, but probably not the case. I would be surprised if the part of Samsung responsible for HSA is even aware of Rust, let alone Samsung is working on Rust. The semiconductor division is pretty independent of other divisions.
- hkmurakami 14y ago
  In particular the System LSI group. http://www.samsung.com/global/business/semiconductor/aboutus/business/overview http://www.samsung.com/global/business/semiconductor/aboutus...

cromwellian 14y ago

I'm no lover of C++, but I'm skeptical that it's really that much more difficult to achieve this design in C++. The parallelism shown is still fairly coarse grained and amenable to traditional techniques. It may be more convenient or less bug prone with Rust, but I read as more substantial, the redesign and rewrite from the ground up. If the redesign was using C/C++, they'd likely get the same benefits, just with uglier code. Isn't it more likely that lessons learned in Servo will simply be back-ported to C++ in Firefox?

sanxiyn 14y ago
Yes, I think that is more likely.
smosher 14y ago
You can write equivalent programs in C++, but if you learned Rust well I am not sure you'd want to. The parallelism shown is still fairly coarse grained and amenable to traditional techniques. [...] If the redesign was using C/C++, they'd likely get the same benefits, just with uglier code. I should hope so, Rust's parallelism is nothing new after all! (Okay, I know, you probably mean by writing programs using explicit mutexes and all that.) I really want to talk about the second part of the quote: what exactly are those benefits? I think you've excluded safety for some reason. If Servo offers competitive performance I think it's most likely the whole engine will simply replace Gecko. I mean why would you spend the time and money to go from the safer to the less-safe code when you can use what you've got?
- cromwellian 14y ago
  There's obviously benefits in using better languages for safety and error checking, it's one of the reasons why I like Closure Annotations/GWT/Dart over raw Javascript because of my experience on large projects and relatively simplistic bugs silently propagating through. The traditional response to these kind of language imperfections is "better tests, better practices". Otherwise as, Unit Tests solve all problems. For C++, someone would say to use some set of abstractions or static analysis tools that confers additional safety that isn't available in the out-of-the-box language. Language level support tends to encourage more consistent usage of something than just depending on vigilance. My metapoint though, is that large code bases are hard to displace, especially if the enduser benefits can be achieved through iteration. Rewriting Gecko from scratch in Rust is a tall order, considering how long it took Gecko and WebKit to get to where they are now. It seems much more likely that WebKit/Gecko can be refactored to get most of the benefits in a much shorter period of time than a rewrite.

ChuckMcM 14y ago

This is a great announcement and adds some much needed support to Servo/Rust. I've been pretty impressed with Samsung too. Clearly they want to have their own seat at the table and they are executing quite well on that desire.

fudged71 14y ago
I'm not confident that Samsung is interested in developing the Android platform, though. They seem to be working on a proprietary ecosystem to separate themselves from the rest of the Android ecosystem. In fact, this is probably one of their motivations: to have control over a leading browser that isn't Chrome so that they can integrate it into their phones as default instead of Google's solution.
- ChuckMcM 14y ago
  Actually if Samsung wants to be a player I really think they can't afford to be tied to Android long term. Too much control at Google and Google is another player and nominally an 'opponent' at some point. Of course their is "Android" and there is the stuff that Google puts around it. Watching the Chinese companies add value to the OS install has been instructive as well. What Android has done has shown the component manufacturers some ways to expand their markets outside "known" players. Part of the challenge of making a phone is getting the chip vendors willing to sign off on giving you software to run their chips (weird I know).
  - kragen 14y ago
    That sounds interesting — what kind of value are the Chinese companies adding?
    - meric 14y ago
      Check it out: http://en.miui.com http://en.miui.com
      - 14y ago

ancarda 14y ago

Any idea when Servo might make it into Firefox desktop builds?

Ygg2 14y ago
A rough guesstimate would be five to ten years. Don't hold your breath either way. Right now Rust is not very optimized and still in flux, while Servo is pretty much a black box for me.

jusben1369 14y ago

"X is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web." Probably says more about how long I've been around but I think I've read a mostly similar paragraph 5 to 6 times over the last decade.

SoftwareMaven 14y ago
And, in the past decade, we've seen the web browsers make significant leaps in security and capabilities. I'm happy to have more of the same.
raldi 14y ago
Mozilla, Firefox, Chrome, Safari, and I think one of the IE's too. And now this. So yeah, 5-6 is a good estimate. Edit: Also the original Netscape.
- fzzzy 14y ago
  None of those were from the ground up. Mozilla was based on the netscape codebase, firefox was based on the mozilla codebase, safari was based on the khtml codebase, and chrome was based on the webkit codebase. IE I'm not sure about, but it seems unlikely that they started from the ground up, surely newer ie uses code from older releases.
  - lifthrasiir 14y ago
    Unless there are actually multiple layout engines developed by Microsoft. At least three (Trident, Tasman and some other used by Expression Web) of them are known, and it is entirely possible that they don't share the common codebase.
  - fpgeek 14y ago
    You're right. Internet Explorer was originally based on Spyglass Mosaic. [1] [1] http://en.wikipedia.org/wiki/History_of_Internet_Explorer http://en.wikipedia.org/wiki/History_of_Internet_Explorer

adamisen 14y ago

If Google is paying Apple $1B/yr to be the default search engine on iOS, it stands to reason that Samsung could negotiate similar per device rates. That seems like enough potential upside for this to be a no-brainer to me.