| |||||||||||||
Mozilla and Samsung building a new browser engineMozilla and Samsung building a new browser enginePosted 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 (subscriber, #15091) [Link] [...] Rust looks like an excellent language [...]After browsing the home page for two minutes I see two major flaws:
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.
> What kind of cruft are you objecting to? make()? append() and friends?
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 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?
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 4, 2013 15:43 UTC (Thu) by tjc (subscriber, #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)?
Another weird part is the for: 'for v.each |e| { bar(*e);}', uh?
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.
|
|||||||||||||