3 ms·

Because defining the Web as a legacy pile of mostly sequential C++ code dating back to the '90s is not a forward-thinking idea. Is your position that Blink's a

Because defining the Web as a legacy pile of mostly sequential C++ code dating back to the '90s is not a forward-thinking idea. Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?

2bitencryption 10y ago
> Or that C++ is a good foundation on which to build some of the most security-critical software on the planet? I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.
- pcwalton 10y ago
  And if the language has a direct impact on the efficiency and safety of the product, then what? A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
  - Spivak 10y ago
    And taking the train dramatically reduces the risk of being in an automobile accident. Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities. I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
    - pcwalton 10y ago
      > Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities. No, because: 1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains. 2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages. 3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
      - Spivak 10y ago
        > Errors such as use after free simply don't exist in memory safe languages. Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear. I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
        pcwalton 10y ago
        > Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear. No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does. > I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language. W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
- dragonwriter 10y ago
  > I care who is writing it and how well it is tested. Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
tomc1985 10y ago
This place hardly seems like an appropriate venue for debating the suitability of C++, given that a large chunk of the audience here seems to have a financial interest in competing technologies. The FUD is strong...
- pcwalton 10y ago
  How is an argument that C++ is a bad foundation not relevant to the proposal that we should define the Web to be a big pile of C++?
  - tomc1985 10y ago
    Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. Further, since people here seem to be very invested in <sarcasm>futuristic</sarcasm> technologies and <sarcasm>disruption</sarcasm> they are naturally inclined to knock C++ just because, and then rationalize it with some technical bullshit.
    - pcwalton 10y ago
      > Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument? > rationalize it with some technical bullshit. If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
      - tomc1985 10y ago
        > If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems. Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}. Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)
derefr 10y ago
I don't think it matters what the particular engine everyone gets stuck with is. The argument is more that forcing everyone to use it, means that everyone now has an incentive to refactor it into something nice. Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape. When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave. Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.
- pcwalton 10y ago
  OpenGL is a standard, not an implementation! Imagine if were all stuck with SGI's implementation of GL instead of having it be a standard that the industry could create unique hardware implementations of. Would SGI have willingly collaborated with 3dfx on the Voodoo? Not likely--instead, 3dfx implemented a subset of the de facto GL standard, called it Glide, and created the entire PC GPU market in one fell swoop. OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :) > everyone now has an incentive to refactor it into something nice. My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward. Do you honestly think Google would be likely to collaborate on that?
  - derefr 10y ago
    I don't see it. My point doesn't change between talking about "a standard", and talking about "a FOSS project with open committee-based maintainership" (like e.g. ASF projects are.) It's stone soup: you'd start off with a worthless project—but if that pile of crap has to "feed the whole town", people are going to turn it into something worthwhile. Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code. > My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that? Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change. See: the Linux kernel.
flatline 10y ago
There's nothing wrong with modern C++, I think it can give any other language a run for its money in this space. If you are talking about a complete re-write, I don't think you can fairly overlook it. RAII + smart pointers eliminate the most pernicious memory management issues. The STL has grown to parity with other modern platforms. Even without a rewrite, given enough time and effort, that crappy old Konquerer codebase may even turn out to look reasonably good. I would not, however, wish it to be the only thing available.
- dragonwriter 10y ago
  > There's nothing wrong with modern C++ The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
  - flatline 10y ago
    Yes, that is the problem. It's also what allows you to drag that 20 year old mess forward into the 21st century. It compiles to virtually any platform with a number of compilers. Trade offs...
    - johncolanduoni 10y ago
      What platform needs/wants a web browser that isn't covered by an LLVM target?
- pcwalton 10y ago
  > RAII + smart pointers eliminate the most pernicious memory management issues. No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening. The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.

2bitencryption 10y ago

> Or that C++ is a good foundation on which to build some of the most security-critical software on the planet? I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.

pcwalton 10y ago
And if the language has a direct impact on the efficiency and safety of the product, then what? A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
- Spivak 10y ago
  And taking the train dramatically reduces the risk of being in an automobile accident. Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities. I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
  - pcwalton 10y ago
    > Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities. No, because: 1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains. 2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages. 3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
    - Spivak 10y ago
      > Errors such as use after free simply don't exist in memory safe languages. Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear. I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
      - pcwalton 10y ago
        > Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear. No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does. > I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language. W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
dragonwriter 10y ago
> I care who is writing it and how well it is tested. Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)

tomc1985 10y ago

This place hardly seems like an appropriate venue for debating the suitability of C++, given that a large chunk of the audience here seems to have a financial interest in competing technologies. The FUD is strong...

pcwalton 10y ago
How is an argument that C++ is a bad foundation not relevant to the proposal that we should define the Web to be a big pile of C++?
- tomc1985 10y ago
  Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. Further, since people here seem to be very invested in <sarcasm>futuristic</sarcasm> technologies and <sarcasm>disruption</sarcasm> they are naturally inclined to knock C++ just because, and then rationalize it with some technical bullshit.
  - pcwalton 10y ago
    > Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument? > rationalize it with some technical bullshit. If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
    - tomc1985 10y ago
      > If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems. Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}. Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)

derefr 10y ago

I don't think it matters what the particular engine everyone gets stuck with is. The argument is more that forcing everyone to use it, means that everyone now has an incentive to refactor it into something nice. Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape. When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave. Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.

pcwalton 10y ago
OpenGL is a standard, not an implementation! Imagine if were all stuck with SGI's implementation of GL instead of having it be a standard that the industry could create unique hardware implementations of. Would SGI have willingly collaborated with 3dfx on the Voodoo? Not likely--instead, 3dfx implemented a subset of the de facto GL standard, called it Glide, and created the entire PC GPU market in one fell swoop. OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :) > everyone now has an incentive to refactor it into something nice. My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward. Do you honestly think Google would be likely to collaborate on that?
- derefr 10y ago
  I don't see it. My point doesn't change between talking about "a standard", and talking about "a FOSS project with open committee-based maintainership" (like e.g. ASF projects are.) It's stone soup: you'd start off with a worthless project—but if that pile of crap has to "feed the whole town", people are going to turn it into something worthwhile. Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code. > My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that? Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change. See: the Linux kernel.

flatline 10y ago

There's nothing wrong with modern C++, I think it can give any other language a run for its money in this space. If you are talking about a complete re-write, I don't think you can fairly overlook it. RAII + smart pointers eliminate the most pernicious memory management issues. The STL has grown to parity with other modern platforms. Even without a rewrite, given enough time and effort, that crappy old Konquerer codebase may even turn out to look reasonably good. I would not, however, wish it to be the only thing available.

dragonwriter 10y ago
> There's nothing wrong with modern C++ The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
- flatline 10y ago
  Yes, that is the problem. It's also what allows you to drag that 20 year old mess forward into the 21st century. It compiles to virtually any platform with a number of compilers. Trade offs...
  - johncolanduoni 10y ago
    What platform needs/wants a web browser that isn't covered by an LLVM target?
pcwalton 10y ago
> RAII + smart pointers eliminate the most pernicious memory management issues. No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening. The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.