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).
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).
Looked for me to be something like an ignore-list. Something I wish I had here in Germany, when using feature-phones 16 years ago.
Why nobody ever invented a feature inside their phones, I do not know.
At the time I visited, circa 2.5 years back, they had (usually physically disparate) skyscrapers within their HQ complex for at least three or four different mobile platforms (Bada, Android, Windows Mobile, and something else I can't recall). Right now I'd assume they have some resources on FirefoxOS and Ubuntu, plus Android, maybe some other systems.
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 :)
That said, having an ARM backend to Rust on Android phones means big things for the potential of mobile web performance. I'm hopeful!
1) There is no uniform agreement about the state of Servo. Some are more optimistic than others.
2) There is a number of unknown unknowns here; that's what makes it a research project and makes it hard to roadmap. For example doing parallel layout of CSS involving floats is an actual research topic people are currently publishing papers on...
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.
Good for Mozilla for attempting hard problems in innovative ways.
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).
It is really hard to take seriously any project that has this kind of nonsense in its introduction.
Language bashing/trolling serves no purpose.
I am rather most likely being downvoted because HN in the past few months has taken an extreme downturn towards a slashdot/herd mentality, but that is just another pendulum swinging.
You're being downvoted because you clearly have no idea what you're talking about. It's entirely appropriate to criticize a language for being too hard to use correctly - your argument would apply equally well to saying that C++ should never have been created because it was simply the fault of people using earlier languages not using them sufficiently well.
This approaches dark comedy because you're also criticizing a company which maintains one of the largest and most important codebases in existence and has a huge list of bugs and security issues demonstrating that even in the hands of very experienced developers it's too easy to use C++ incorrectly.
Are you able to see how that is different now with a little help? Or is it so insufficient to make up straw arguments and put words into my mouth that now you want to do the same for Mozilla foundation?
If you honestly think there's no point in trying to make better programming languages, you're welcome to continue programming in FORTRAN IV. But don't expect other people to take your opinion seriously about what "serves no purpose".
The point was simple: language bashing/trolling is childish. It is hard to take seriously a project with that kind of statement in its introduction.
If instead it said Rust does X in order to achieve goal Y, that would be more useful.
"Trolling" is bullshitting to provoke a response; your accusation there, if we take you at your word, would have to be that the Rust developers are developing a new programming language as a sort of hoax in order to get a rise out of C++ programmers.
I don't think it really serves your point well to suggest that Graydon Hoare, Brian Anderson, Sebastian Sylvan, Samsung, and so on, are "childish" and "hard to take seriously" and dishonest, because that requires us to choose between taking Graydon and Samsung et al. seriously and taking you, Shawn Butler, seriously. This is a competition that will be hard for you to win. Perhaps instead you could find a way to couch your criticism (whatever it is) in a way that makes it easier to accept. As it is, only people who have a pre-existing hate for Graydon or Samsung will be inclined to accept your argument.
The contention was simple and utterly straightforward. Having a conjectural and value laden statement that is false and using it in an introduction gives me pause. Doing so persuades people holding surface knowledge (as evidenced by this comment thread) but gives people with experience a different response.
Now you are making an appeal to authority.
Also while I hate to be the harbinger of bad news, parallel programming in any language is Really Hard(tm) for most people. Personally, I think there's a fundamental disconnect in how human cognition perceives the world on the one hand and massive parallelism on the other at which very few people I have met really excel relative to the larger population.
Coming from a C++ developer, I don't think you're well aware of its limitations. Do yourself a favor and learn a little bit of Rust. It'll open up your mind a little, and just might make you a better C++ programmer.
I'm pretty sure based on your writing that you have little to offer me that I don't already understand about the language, but thanks for your hollow advice though. Here, I'll make an empty prediction in return: in 3 years you will be complaining about how difficult it is to do distributed parallelism in Rust and what absolute garbage it is compared to <insert name here>.
The point was simple but fanbois want straw men and windmills at which to tilt: if you have something you think is better, extol its virtues and provide comparative analysis instead of bashing/trolling what currently exists completely out of any useful context.
I really have little interest in discussing anything technical on HN anymore. Here's a token wikipedia link, that's what passes for knowledge I guess .
Also I would keep your "advice" to yourself. I certainly hope you wouldn't speak to people like that in person, and you definitely wouldn't be allowed to speak in such a fashion to me in particular. I am pretty familiar with Rust's evolving semantics and syntax, thanks.
But more importantly, Rust doesn't allow any shared mutable state, meaning that all the synchronization primitives C++11 provides can be used by the language automatically by the language on your behalf. Of course, nothing prevents someone from creating a library in C++ that does the same thing, but there's no way for the compiler to enforce the clean thread-wise separation of state and if you've forgotten to get rid of some pointer to an object you're passing to another thread you won't know about it potentially until you're debugging it in production. Also there are a number of threading optimizations that the Rust compiler can make with re-ordering or eliding memory accesses that the C++ compiler can't.
"Or are you claiming that C++ is in fact particularly well suited for parallel development and inherent avoidance of data races?"
I answered the c++ memory model was certainly sufficient and the implementation was left to libraries until C++11 when it was standardized. I did not mean to imply that the c++ memory model underlies that of Rust.
And I agree these are great points to illustrate. Would make some great text to use on their introduction page in place of the trolling. Still, I believe the same deficiency exists regarding compiler enforcement for Rust since the "unsafe" keyword allows for manual management, correct? I can't intelligently comment on the compiler optimizations to which you refer. If you could provide some reference to further analysis? Regardless, the two same two people are downvoting my comments so I won't be commenting further.
Although you clearly understand, I'll throw in the token links for people who may not understand what a memory model is or how the c++ memory model has been formally standardized. To be honest, I don't know why I bother.
Out of curiosity, who wouldn't allow me to speak to you in such a fashion? Who's this imaginary authority who controls how I speak to children?
Then you also have to make sure that your rendering engine behaves in a sane way, supports all the obscure CSS rules from the spec and from webkit...
There's a reason Opera stopped playing this game; it's hard work.
- There are two types of elements: block and inline. You can declare a name of an element with a particular type using perhaps XML namespaces, or just a JSON object.
- Inline elements can be floated left/right along other inline elements.
- Block elements may be positioned absolutely inside their parent elements or relatively to their current position. You cannot float them.
- Width/height may be specified as a pixel width, percentage width of parent, percentage of available space, or percentage of screen size. Additionally, you may specify the box model: whether to include borders, margins, padding, etc.
- CSS rules about typography, margins, borders, padding, etc. shall apply. This way, you can include your own basic rules and build on top of them.
I had the misfortune to do a bit of hacking with GTK+ and at first thought "what an archaic way to lay out elements?!" Then it came to me that HTML + CSS is not advanced, it is cluttered. There are many ways to position an element on the page, and they will conflict. Additionally, things like opacity affecting z-index, having a parent element have a size to give the child element a percentage size, etc. lead to a ton of hacks. It's time we have a better, cleaner tool than the browser if we are going to build serious apps on this platform.
- position: absolute/relative/fixed + top/left values
- float: left/right
- positive/negative margins
- float values of other elements
Yet cannot do simple things like tell a block element to take up all available height.
The spec focuses on various types of data that could be represented. For example we have a <code> tag. This is done in an attempt to be semantic. However, it fails at being comprehensive, and ends up falling back on things like <code class="python"> instead of <python>. The distinction between <code>, <var>, <span>, <label>, and other inline elements is completely arbitrary and which elements get to be first class citizens is also arbitrary. Giving up and saying that there are only <inline> and <block> elements would simplify things a whole lot. If you can then "subclass" a <block> to create a <p> element or subclass an <inline> element to make a <lable>, go for it!
> Unlike the case of HTML, element names in XML have no intrinsic presentation semantics. Absent a stylesheet, a processor could not possibly know how to render the content of an XML document other than as an undifferentiated string of characters. XSL provides a comprehensive model and a vocabulary for writing such stylesheets using XML syntax.
So the big issue with XSL is that it's verbose as hell. I remember using XSL Transforms to do some really simple things, and getting it right was horrible. Debugging it was worse. Given a piece of code that uses HTML + CSS vs XSL, I'd pick HTML + CSS any day simply because it's more readable.
However, yes the core of it seems much better thought out than CSS.
> but now it's too late.
Is it? Is it possible to have some XSL FO to HTML5 + CSS compiler?
Yes, agreed. Though the next thing that we might want to tackle is the whole concept of a web page. Seems like storing application state in a URL is a terrible thing, yet it is so convenient for some use cases. This might mess with the idea of a "browser" more since you wouldn't be "browsing" applications, you'd be running them.
> Plus you will have to build a CSS compatibility layer on top. Hard but worthwhile.
> Sort of thing Adobe might work on.
Are you being sarcastic?
KHTML is a bit older (14 years).
But WebKit development started in 2001, about 12 years ago.
Safari, using WebKit, was released in Jan 2003, over 10 years ago.
So no, WebKit doesn't count as a browser engine started within the last 10 years. ;)
5% might not sound like much, but I'd want something comparative. How much code in the 3.8 kernel is shared with what Linus released in 1991? I suspect it's similarly low, but we still recognize them as the same project.
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
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]
Some further details about Servo and Rust can be found here: http://www.mozilla.org/en-US/research/projects/
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.
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.
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.
I'd make the argument that without Gecko the web would have become even more entangled with and dependent on IE. That would have smothered WebKit in the cradle, making it impossible for anyone outside of Microsoft to make a decent mobile web browser.
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.
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.
We need to have more safe alternatives for systems programming.
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.
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.
Edit: Also the original Netscape.
Dom funcions could have been generic ala C++ STL style for iteration restrictions
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?
I probably should have not used the term "pull based api", since that is just a fancy word for a cursor based api.
Example could be SQL - we get a result set after a query exection and can iterate over the elements of the result set. SQL databases can be implemented in a wide variety of ways. (Though best practice has condensed this to a few).
A browser api that had a query language to get different types of node cursors: read-only, appendable, live, etc and some well-defined, optimizable operations on such cursors would have allowed implementors to choose a wide variety of data-structures/algorithms for optimization.
Isn't it more likely that lessons learned in Servo will simply be back-ported to C++ in Firefox?
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?
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.
The security vulnerabilities found in all browser engines stemming from things like use-after-free suggest otherwise.
"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."
It's really, really hard. The language works against you at all levels. Type systems are much easier ways to achieve the same result.
But it's not right to think of Rust as a safe C++ in the small, particularly because of the ban on shared mutable state. IIRC, Rust is partly a product of the difficulty C++ had in this area.
I don't think they're rewriting Gecko. If the transitive property holds, the code in Servo is at least as different from the code in Gecko as Rust is from C++, and I think that's only amplified in the design. Servo aims to do things that are not realistic for Gecko, like parallelizing more of its operations. I don't think they'd be going this far with Servo at this point if it wasn't for that, I think Gecko would just see the necessary changes and that would be it.
Either way, Servo exists. We're told it started as research, but it is obviously at the point where its promise is more concrete. When the lessons have been learned from Servo, it will be a complete, embeddable (this is one goal Gecko gave up on) engine. There's no sense in backporting its innards to the C++ engine when you can just drop it in place.
Usually, with high-risk long-term research projects, its fairly likely that the main benefit will be providing knowledge that can be applied to more conservative projects or to later high-risk, long-term projects.
OTOH, those insights often come from getting out of conservative boxes and trying something radical and new, and C++ is as much as part of the "box" Servo is trying to get out of as is the existing code base of particular browser engines.
Not with memory safety. Adding memory safety to C++ is incredibly difficult without sacrificing performance—think iterator invalidation.
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.