Mozilla's Servo Is Whooping The Other Browsers In Performance

[codensity]

how can it be superior choice without being better?
if it better in some arbitrary aspect, but worse in others, it is not superior choice, it is choice of marginals

Apologies, that was poor phrasing on my part. I'd meant something like "rust isn't building on the ideas of C++"---it's merely targeting a similar domain.
I also agree that there are trade-offs (for me: svh, realistically no libs, complex linking, cargo, no higher kinds, etc.), however this is always the case in computer science. After all this discussion likely wouldn't exist if it were clear cut. I have to make trade-offs when choosing C++ over C as well (sure I can drop into C in C++ but this is equivalent to choosing C).

we have no rust spec at all, how could you compare one development compiler without spec with real iso standard with many mature implementations?

This is a good point, we don't yet have a central spec to look at; however I would argue that the numerous RFC's we do have are of very high quality. Much more so than C++. With rust it's an issue of age (many things not yet set in stone) whereas with C++ it's an issue of being badly designed (many things set in stone and done so badly). We're even getting a proof that rust's type system is sound.

it inherints c problems not for fun, but because without backwards compatibility you can only get toy language like rust

I'm not sure it's strictly true that language success implies strong backwards compatibility with C semantics. There are many languages with C's success (in terms of industry demand) that are less compatible. I wouldn't consider any of these languages to be toys (e.g. java). I do however agree that it would be crazy to forgo an ffi (rust can fortunately bind C libs automatically). Likely in support of the ffi, rust additionally has great support for C compatible data layout such as C style structure representation, enum representation, etc.

if you are talking about static type, then it's a tool's fault. compiler knows it, tool could just ask compiler.

This was me being unclear again, sorry. I was referring to custom type systems. The C++ compiler can't properly infer the necessary types either (nor do they exist for it). This problem stems from being unable to infer some required assertions or proofs because the problem is undecidable and we haven't thought of sufficiently clever tricks/heuristics (similar to why we get inference in vanilla haskell but lose it with RankNTypes or why djinn can infer some programs but not others).

[unixfan2001]

So, the difference is: these pesky C/C++ gurus can do everything you can, and much more than that. On other hand, these l33t $cr1pt k1dd13z are quite limited in their abilities. Not like Mozilla or Google could help 'em too much.

I call bollocks!
Even if I was limited by the basic language constructs, ever heard of an FFI?

Of course you're not. Because you have no even slightest idea on how Linux containers are working and what clone does.

Or perhaps you're confusing child processes with actual Linux containers (LXC)? While you mention Kernel namespaces and SECCOMP filters, the rest of your explanation sure makes it sound that way.

Lol, if they're going to remove XUL and XPCOM and using Chrome extensions apis, it just kills last reasons to use Firefox at all. Chrome/chromium are already multi-processes, already got these apis, they are just as "customizable" as mozilla is going to be, can isolate into containers on linux, faster in js and overall ti is a production-quality thing, not some half-borked experimental engine. With some powerful features like nacl, and also not being inclined on ecosystem shit, so one can add any extension to chrome, without asking google to sign it, etc.

1. Do you only run a browser for the extensions? Seriously?
2. You talk about past security breaches but then bitch and moan about developers being required to sign their extensions in the future. Again. Seriously?

Yeah, greedy mozilla fucks, take that.

Greedy? Really? What did you pay Mozilla for the privilege of using that browser? I don't remember a monthly subscription model.

So they learned nobody needs third-rate shit. They're going to learn it even harder.

Yea. Because no one ever needed competition to base future efforts on... Are you posting from inside North Korea?

This "special" version called "chromium" and is what supplied by most Linux distros by default. Sure, even Chromium could be a bit nasty in terms of privacy.

Glad you're happy with a completely crippled browser that only supports a fraction of what Chrome does...

But damn, Mozilla got like 30 (!!!) reasons to phone home. Reporting a plenty of data.

Kindly provide me with a transaction log, because I have a hard time believing that claim.

Um, btw, Ubuntu is eager to get rid of Firefox for several Ubuntu versions already. I guess Mozilla can eventually get quite a major slap in the face, losing around 20M users at once. Looking on changelogs, it seems ubuntu devs already had some extra "fun" with extensions signing, so they would like Mozilla even more.

They aren't trying to get rid of it entirely. Just no longer make it default.
In the future, I suspect Canonical is going to include only their own browser in the default installation as that one is a central part of Unity8 anyways.

Chrome is confined in Linux container, to begin with. Rogue code would see very boring system with few processes, almost no data, no programs and so on. Breaking out of container is entirely different story.

I don't even need to break out of the container in order to access X. Why would I want access to your boring processes and your data when I can log your keyboard input?

Chrome-like browsers on Linux would suffer much less, and google is rarely paying full reward, assuming breaking of all defence layers these days.

The last zero day attack on Google Chrome based browsers proves you wrong.

But somehow I'm not a big fan of performance and quality of Mozilla's video playback. And their brand new idea to supply Cisco's codec has been utter trashbin. Not just they download some 3rd party blob without user consent, it just suxx very hard when playing video.

1. OpenH264? Brand new? It's been in there since Firefox 33 (i e since late 2014)
2. What if I told you that this particular plugin wasn't even used for mere video playback but only for WebRTC and on systems without platform specific codecs (ffmpeg on GNU/Linux, or GStreamer if ffmpeg isn't available)?...

I think they first may want to stop fucking up users, devs and admins, breaking user experience all the time, changing all sorts of crap while ignoring plenty of long-standing problems.

Are we using the same browser? Firefox hasn't broken user experience for a long time. It's rather orthodox.
Are you seriously still bitching about the change in the extension model? That's like GTK2+ -> GT3+ or KDE3 -> KDE4.

Change needs to happen. Either deal with it or rent a bunker and isolate yourself from the rest of society.

But at least it does not breaks user interface every few months, do not install crappy cisco codecs, which warrant extremely jerky video playback everywhere including youtube, do not lock down extensions devs/users and so on.

See above. It doesn't ever use that codec for video playback on Youtube.