Earlier quoted context omitted.
Firefox is free as well. You're not making your point very well.
I know, but you can donate to them. Chrome, you can’t.
So if Chrome added a donate link, you would be okay with them..?
Serious Chrome zero-day
311–320 of 377 posts
Re: Serious Chrome zero-day
#312Earlier quoted context omitted.
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. And so, as they say, we should all be using Rust. But allow me to explain why I don't yet. Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole…
> Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc. > I understand the desire to make changes. Many of the changes are impr…
It's sorta kinda both. The original implementation was in OCaml, and many of the early developers were big ML fans. But we also tried to keep syntax more C-like, overall.
"It's a C-like OCaml" was how Rust was originally described to me, when I first heard of it.
Re: Serious Chrome zero-day
#313Earlier quoted context omitted.
Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)
"Polyfills" are quite common in Web development, and are also proof that browsers do a whole bunch of unneeded stuff (if it were needed, there would be no way to polyfill it). I actually think polyfill usage is backwards: the current approach allows code targetting new features to be made compatible with old browsers, by the site providing polyfills. I think it's much better for new browsers to be leaner, simpler and…
This _did_ successfully happen with MathML. It was on track to get native browser support, but they decided it the polyfill (mathjax) was good enough and wasn't worth native support for such a niche feature.
As a web developer, I much appreciate native features and avoid polyfills as much as possible.
Re: Serious Chrome zero-day
#314Earlier quoted context omitted.
I made my choices carefully and consciously. As I said, I entrusted Google with my data, my emails, pictures, history. I know that my data is never sold to anyone and always kept secure. Google is probably one of the most careful companies when dealing with private data in the world. I can delete or take a copy of it if I want as well. Needless to say, I disagree with the "you are the product" polemic.
>Google is probably one of the most careful companies when dealing with private data >private data Ah, the fabled "metadata is not data" defense. Sadly, given the scale and pervasiveness of Google, observing meta-data and cross-referencing your activity with others' activities is good enough to deduce most of the valuable information about you with reasonably good reliability. And this data, both by itself, and also…
Sorry, but what you say doesn't make any sense. What meta data are you talking about?
Re: Serious Chrome zero-day
#315Earlier quoted context omitted.
That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…
> Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Yes, it is, because the language has the concept of safe code to begin with. The problem with C++ is that all C++ code could potentially be unsafe. > Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, u…
I thought Rust was written in C++, apologies.
Re: Serious Chrome zero-day
#316Earlier quoted context omitted.
That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…
> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.
Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe.
When Go 1.8 released, it measured I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.
Re: Serious Chrome zero-day
#317Earlier quoted context omitted.
Let stop hand waving C security exploits caused by top developers, in spite of best practices. C only got outside UNIX in the mid-90's. Its ubiquity is an historical accident, by no means permanent, and thankfully some vendors are finally walking away from it, as proven by Microsoft security advisor for future Windows development best practices.
I'm pretty sure C was pretty well thought out and wasn't used by accident in any way. After almost 50 years of usage, I'm not sure we can say it's "by no means permanent" either.
Modern C is very different to K&R's C. Which itself was based other programming languages before it (like B - got to love their naming convention for programming languages!). But the history of C aside, it wasn't the only language that operating systems were built on. LISP, Pascal and obviously assembly / machine code too. In fact Pascal was a very popular systems language on home computing in the 80s and early 90s. If I recall correctly it used heavily by Microsoft and Apple too.
Don't get me wrong, I do like C. But it wasn't the run away success nor holds quite the monopoly you suggest it does.
Re: Serious Chrome zero-day
#318Earlier quoted context omitted.
Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and t…
> Remove V8's JIT and GC and then one can have a meaningful discussion about memory safe languages. But remove those and the vast majority of Chrome bugs would also disappear. Those are the places of highest complexity while also being the areas which no language offers any meaningful assistance. No, just no. The data just does not back this up. The vast majority of Chrome bugs are not due to the V8 JIT or GC. Full s…
Instead of "getting rid of C++" in a project written almost exclusively in C++, it would seem more sensible for Google to just wait for Firefox to be completely rewritten in Rust in the next ~10 years and if it's really that much better, fork it, add some googley stuff on top like user-tracking and mandatory log-in and then release it as the new Chrome.
Re: Serious Chrome zero-day
#319I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…
Is there an official explanation of the kind of bug? I cannot find it. "Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex." Pointing the finger and saying "see?" is a pretty low quality argument. So, I guess we should wait for the first Rust or managed language remote exploit (or whatever) to say "admit it, finally - you can't write safe... programs ?".
Managed languages remove an entire class of exploits present in C and C++ programs. That alone is a very good start.
Re: Serious Chrome zero-day
#320Earlier quoted context omitted.
> Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc. > I understand the desire to make changes. Many of the changes are impr…
It's sorta kinda both. The original implementation was in OCaml, and many of the early developers were big ML fans. But we also tried to keep syntax more C-like, overall. "It's a C-like OCaml" was how Rust was originally described to me, when I first heard of it.
Moreover, it doesn't matter what it is based on, it matters what it is trying to displace.
I am not really even criticizing Rust. Let it be what it is. Python isn't C++ either. All I'm saying is that if the goal is to increase the number of people using memory safe languages, adding a borrow checker to C++ would serve that goal.
(Also, I would really like to have a language with both a borrower checker and actual C++ templates.)