User: Password:
|
|
Subscribe / Log in / New account

Mozilla and Samsung building a new browser engine

Mozilla and Samsung building a new browser engine

Posted Apr 3, 2013 18:25 UTC (Wed) by markhb (guest, #1003)
Parent article: Mozilla and Samsung building a new browser engine

...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... hardware to enable new and richer experiences on the Web.
Isn't that what they said about NGLayout (aka Gecko)?


(Log in to post comments)

Mozilla and Samsung building a new browser engine

Posted Apr 3, 2013 18:48 UTC (Wed) by apoelstra (subscriber, #75205) [Link]

> Isn't that what they said about NGLayout (aka Gecko)?

If they did (I don't remember), they would have been correct -- Gecko was a huge step up for graphical web browsers. But even in the last five years the use of browsers has changed drastically, so that websites now are often elaborate and complex Javascript frontends to server-side applications, shunting loads of data around and using several domains. The security and performance requirements are therefore very different than they were when Gecko was conceived.

As for this project, I hope it succeeds because Rust looks like an excellent language, and it would be great to see it completed and have traction.

Mozilla and Samsung building a new browser engine

Posted Apr 3, 2013 19:41 UTC (Wed) by bronson (subscriber, #4806) [Link]

> Rust looks like an excellent language, and it would be great to see it completed and have traction.

Isn't that what they said about XUL? :)

Mozilla and Samsung building a new browser engine

Posted Apr 3, 2013 20:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Well XUL is just markup and it did gain a lot of traction for a while (flickr uploader, Songbird, Activestate Comodo etc) but it didn't stick

Rust-lang

Posted Apr 3, 2013 21:12 UTC (Wed) by man_ls (guest, #15091) [Link]

[...] Rust looks like an excellent language [...]
After browsing the home page for two minutes I see two major flaws:
  • Another Google-unfriendly language, like Go? Apparently it is those companies that should know better (first Google, now Mozilla) that fall into this stupid trap. Why not call your shiny new language a string that doesn't already have more than 100M hits on Google? Admittedly Go is worse, with 13G hits.
  • And another keyboard-unfriendly language. In this case even worse than Go or any other C derivative: not only curly braces but also with stupid | bars. The situation becomes even more bizarre with non-US layouts: my Spanish ISO keyboard has the | with Alt+1. But anyway it appears to be a very symbol-rich language, with "()[]{}|&:,;!%" in the trivial example on the front page.
Honestly, I don't look forward to learning it.

Rust-lang

Posted Apr 4, 2013 0:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, you have to choose modifiers at the end of the day. Rust is actually pretty sane in this regard - just look at Scala for a comparison.

I've recently tried to use Rust instead of Go for simple "scripts" and I really loved it. Rust has a good type system (real reified generics!), unique memory management system (with explicit inter-thread sharing), normal exceptions support, etc.

In comparison, Go really looks like a kludged second-system effect language.

Rust-lang

Posted Apr 4, 2013 3:11 UTC (Thu) by imgx64 (guest, #78590) [Link]

I think the competition between Rust and Go is going to be really interesting. Go is a really simple language that tries to be practical instead of feature-complete (i.e. a better C). Rust on the other hand tries to include a lot of features and wants to be the end to all your programming needs (i.e. a better C++).

Rust-lang

Posted Apr 4, 2013 3:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Go doesn't really tries to be 'better C'. It's more like "Java but from Google" - they are even repeating the same "mistakes" like having mutable variables by default and the common heap.

And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.

Rust-lang

Posted Apr 4, 2013 4:08 UTC (Thu) by imgx64 (guest, #78590) [Link]

> Go doesn't really tries to be 'better C'. It's more like "Java but from Google"

Java? What does Go have in common with Java?

Go didn't even start its life as "something from Google" (unlike Dart for example). It started as a 20% project by Rob Pike, Ken Thompson, et al. then other developers at Google started using it because they found it a good fit for their problems.

> having mutable variables by default and the common heap.

Like I said, "practical"--that's how computers work.

> And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.

What kind of cruft are you objecting to? make()? append() and friends?

I agree they're not orthogonal, and to an outsider, they feel like a kludge for the lack of generics. But after using them for a while, they don't bother me much. And the simplicity of the rest of Go more than makes up for any conceived "cruft".

Rust-lang

Posted Apr 4, 2013 4:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

>Java? What does Go have in common with Java?
"Style" of it.

>Like I said, "practical"--that's how computers work.
No it isn't. CPUs now quite often have their own local memory so having explicit support for local arenas is becoming essential.

> What kind of cruft are you objecting to? make()? append() and friends?
The idiotic error handling with tuples. For example. Then the whole generics fiasco.

From what I'm seeing, a lot of Go code out there simply has no error handling - it either works or fails mysteriously.

Rust-lang

Posted Apr 8, 2013 7:53 UTC (Mon) by nix (subscriber, #2304) [Link]

>>Java? What does Go have in common with Java?
>"Style" of it.

That's C's style you're seeing, not Java, which is not surprising given who its authors are.

I'm afraid most of your criticisms are heavy on vituperation and light on facts, or anything that would suggest what you find wrong (naming features and calling them 'fiascos' does not satisfy).

Rust-lang

Posted Apr 8, 2013 10:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

No, I'm definitely see Java's style: half-baked solutions made in the order to be 'simple'. Which lead to the kind of complexity caused by necessity to combine _a lot_ of 'simple' components to get anything meaningful.

My favorite language which tries to avoid it is Python.

Rust-lang

Posted Apr 4, 2013 6:57 UTC (Thu) by heijo (guest, #88363) [Link]

It seems to me that Rust is going to be completely superior to Go, and is likely to kill it.

More interesting is whether it will manage to be a complete replacement for C++, with the same performance but adding safety, which would be a VERY much needed development, since using unsafe languages needs to stop.

And also what's going to happen to the high-level space (currently led by Java/Scala and C#), and specifically whether Rust's lack of a global garbage collected heap and multiple pointer types will prove good or bad.

It's definitely one of the most promising languages in existence, along with Scala.

Rust-lang

Posted Apr 4, 2013 8:43 UTC (Thu) by imgx64 (guest, #78590) [Link]

> It seems to me that Rust is going to be completely superior to Go, and is likely to kill it.

This is why I think the competition will be interesting; a classic C vs. C++ / Simplicity vs. Features sort of competition.

As far as Rust killing Go, Go has already released v1.0 (with v1.1 coming in the next few weeks), and is actually used in mission-critical applications. Rust? Still not much.

Rust-lang

Posted Apr 4, 2013 8:02 UTC (Thu) by renox (subscriber, #23785) [Link]

> Well, you have to choose modifiers at the end of the day. Rust is actually pretty sane in this regard - just look at Scala for a comparison.

Uh? Could you give an example of what you're talking about?
I'm not using Scala but last time I looked its syntax was much,much better than Rust "syntax".

Rust-lang

Posted Apr 4, 2013 16:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

"qsort(rest).::(pivot).:::(qsort(smaller))"

Rust-lang

Posted Apr 4, 2013 22:55 UTC (Thu) by HelloWorld (guest, #56129) [Link]

Nobody writes it that way, there's a reason why one is allowed to omit the . and the (). Also, you've confused ::: and ::. qsort(rest) ::: pivot :: qsort(smaller) I don't think this looks too bad.

Rust-lang

Posted Apr 6, 2013 13:24 UTC (Sat) by gevaerts (subscriber, #21521) [Link]

> you've confused ::: and ::
Are you sure you're making the point you're trying to make?

Rust-lang

Posted Apr 6, 2013 16:38 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Yeah, I know, people confuse + and ++ in C all the time. Oh wait: they don't!

Rust-lang

Posted Apr 8, 2013 11:19 UTC (Mon) by dgm (subscriber, #49227) [Link]

Indeed, the difference is crystal-clear. But, for some odd reason, it reminds me of Brainfuck and Whitespace.

Rust-lang

Posted Apr 8, 2013 11:45 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> But, for some odd reason, it reminds me of Brainfuck and Whitespace.
Yawn. Those stopped being funny like 10 years ago.

Rust-lang

Posted Apr 4, 2013 15:43 UTC (Thu) by tjc (guest, #137) [Link]

> I've recently tried to use Rust instead of Go for simple "scripts" and I really loved it.

What OS/distro are you using? I tried to build Rust on both OS X and Linux Mint 12.04, but both failed, for different reasons.

Rust-lang

Posted Apr 4, 2013 17:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Mac OS X with recent enough MacPorts. No problems at all during the build.

Rust-lang

Posted Apr 4, 2013 3:34 UTC (Thu) by dirtyepic (subscriber, #30178) [Link]

You think that's bad? I've heard of languages with single letter names!

Rust-lang

Posted Apr 4, 2013 6:18 UTC (Thu) by donbarry (guest, #10485) [Link]

And not just the obvious one. J is an incredible language which deserves to be known widely. K is even less well known (probably deservedly) and distantly related, by an unrelated development team but inspired by the same roots in APL.

Rust-lang

Posted Apr 5, 2013 8:21 UTC (Fri) by dgm (subscriber, #49227) [Link]

I don't find those much problematic, but go read the tutorial, and in section 3.1 you will find that:
let var = 
  if (condition1) {
    value1
  } else {
    value2
  };
is completely different from:
let var = 
  if (condition1) {
    value1;
  } else {
    value2;
  }

The second one would be almost surely a mistake, but the compiler would not complain. In my opinion this defeats the purpose of doing Yet Another Curly Brace Language. The mere fact that they feel they need to point it out in the tutorial is a clear sign that something is wrong here.

I hope they get this sorted out before 1.0

Rust-lang

Posted Apr 5, 2013 12:39 UTC (Fri) by renox (subscriber, #23785) [Link]

Yes, in Rust you have to be very cautious about the usage of ';'!
Thankfully as the return type of functions is not inferred but given explicitly in many cases the compiler will be able to complain, not in the example you've given though.

Apparently they don't like 'return', I'm not sure why.. Maybe it's because it's 'big' (they seem to like short keyword)?
In this case, they could have done like SmallTalk use '^' instead of return.

Another weird part is the for: 'for v.each |e| { bar(*e);}', uh?
The languages I know use either for (for e in set { .. }' or each (set.each |e| { .. }) but having both for AND each at the same time??

Also code with named lifetime seems really hard, but I don't think that's a syntax issue, it's just a difficult concept to master.

Rust-lang

Posted Apr 5, 2013 12:54 UTC (Fri) by HelloWorld (guest, #56129) [Link]

It is trivial to add a warning for that. Just check if a local variable is bound to a value of type ().

Rust-lang

Posted Apr 5, 2013 17:01 UTC (Fri) by jimparis (subscriber, #38647) [Link]

A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.

Rust-lang

Posted Apr 5, 2013 22:18 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.
It doesn't matter whether the branch can be taken, the values of both branches are of type (), and it doesn't make sense to store a value of that type in a variable.

Rust-lang

Posted Apr 5, 2013 22:47 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> It doesn't matter whether the branch can be taken, the values of both branches are of type ()

So imagine a case where both branches are different. Or where the conditional is deep inside a function before the return value finally gets to the assignment. If having a conditional return type () makes sense in some cases and not others, then you can't trivially warn about it.

Rust-lang

Posted Apr 6, 2013 0:26 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> So imagine a case where both branches are different.
That's a type error in itself in most cases. In order for such code to typecheck, the branches' types must have a common supertype. As far as I can see, Rust allows only interfaces to form hierarchies, and I don't know if it's even possible for () to implement interfaces. But even if it is, this situation is going to be so rare that it's not worth losing any sleep over it.

Rust-lang

Posted Jun 21, 2013 8:04 UTC (Fri) by jessopher (guest, #91536) [Link]

You can return a pointer to a value of a type that satisfies a trait constraint, but not a direct value.

Imagine something like this

fn foo(which: bool) -> Number
{
if which { return (1 as int); }
else { return (1 as byte); }
}

now ask yourself "what is the bit-width of the value returned?", and "how is the implementation of the interface specific to each subtype determined at runtime?". For pointers, what is actually pointed to can be something that carries runtime type information, like the bit-width of the value, and the address of some dispatch table.

So really the situation isn't a rarity, it is non-existent. You are not going to accidentally return a pointer to (), from a function that has a polymorphic return type that () satisfies.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds