8 ms·

A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for t

A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another language.

gpm 8y ago
It doesn't even have to be memory safe, just less memory accident prone. D for example would have been an interesting choice (and I think it was usable back then).
- flukus 8y ago
  D was released in 2001, KHTML in 1998, it's like suggesting they should have written vim in java.
  - jlgaddis 8y ago
    ... and Chrome in 2008.
    - jsjohnst 8y ago
      Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.
      - kolme 8y ago
        KHTML is the rendering engine for the Konqueror browser. Webkit is a fork of KHTML. And Chrome's engine is called Blink (it used to be Webkit, but they forked it).
- kllrnohj 8y ago
  D would be interesting but it's also not memory-safe. Not strictly. You can restrict yourself to SafeD, but then you're stuck with a GC you don't really want. Or you can tag all your functions as @Safe, but then it's just a "best practice" and you can't do it everywhere because you can't do things like make system calls. D has some interesting bits, but it did a lot of head-scratching stuff too. It seemed really confused about what target it was going after, like some middle ground between C#/Java & C/C++ that really doesn't seem to exist.
deleted 8y ago
[deleted]
doctorpangloss 8y ago
Their egos have priced them out of a lot of stuff though. The Chrome team is great but when you're surrounded by people who think they're god damn gods on Earth it's hard to question orthodoxies, especially old ones.
- Roboprog 8y ago
  As trollish as that sounds, there's a painful amount of truth there. Program in GNU Pascal or some such thing? Not us. Pedal to the metal!
kllrnohj 8y ago
Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.
- staticassertion 8y ago
  I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue. What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm not interested in making a judgment call on their initial choice - I totally get the decision, regardless.
  - kllrnohj 8y ago
    > What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all scream "you cannot use this language safely!!!", now does it? I would certainly argue for something like Rust instead if starting from scratch, though, but just because A is better than B doesn't make B unusable trash, either.
    - staticassertion 8y ago
      Well, that's not really a fair interpretation of my argument, I'd say. My argument is: * We have a production, widely used codebase * This codebase is in C++ * This codebase has probably the most significant efforts to secure it of anything of its size, or at least it's in the top 5 * This codebase suffered enouguh critical vulnerabilities for users to be attacked in the wild So let's be clear - Chrome suffers from thousands of memory safety vulnerabilities, but not many make it to ITW exploits. This case is special because users actually suffered because of it. It isn't fair to say they've had "one security issue", certainly, just one that's had major user impact. I'm not judging C++ or the choice to use it. I am saying that this is an example of a very hardened system not being able to compensate for memory unsafety.

gpm 8y ago

It doesn't even have to be memory safe, just less memory accident prone. D for example would have been an interesting choice (and I think it was usable back then).

flukus 8y ago
D was released in 2001, KHTML in 1998, it's like suggesting they should have written vim in java.
- jlgaddis 8y ago
  ... and Chrome in 2008.
  - jsjohnst 8y ago
    Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.
    - kolme 8y ago
      KHTML is the rendering engine for the Konqueror browser. Webkit is a fork of KHTML. And Chrome's engine is called Blink (it used to be Webkit, but they forked it).
kllrnohj 8y ago
D would be interesting but it's also not memory-safe. Not strictly. You can restrict yourself to SafeD, but then you're stuck with a GC you don't really want. Or you can tag all your functions as @Safe, but then it's just a "best practice" and you can't do it everywhere because you can't do things like make system calls. D has some interesting bits, but it did a lot of head-scratching stuff too. It seemed really confused about what target it was going after, like some middle ground between C#/Java & C/C++ that really doesn't seem to exist.

deleted 8y ago

[deleted]

doctorpangloss 8y ago

Their egos have priced them out of a lot of stuff though. The Chrome team is great but when you're surrounded by people who think they're god damn gods on Earth it's hard to question orthodoxies, especially old ones.

Roboprog 8y ago
As trollish as that sounds, there's a painful amount of truth there. Program in GNU Pascal or some such thing? Not us. Pedal to the metal!

kllrnohj 8y ago

Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.

staticassertion 8y ago
I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue. What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm not interested in making a judgment call on their initial choice - I totally get the decision, regardless.
- kllrnohj 8y ago
  > What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all scream "you cannot use this language safely!!!", now does it? I would certainly argue for something like Rust instead if starting from scratch, though, but just because A is better than B doesn't make B unusable trash, either.
  - staticassertion 8y ago
    Well, that's not really a fair interpretation of my argument, I'd say. My argument is: * We have a production, widely used codebase * This codebase is in C++ * This codebase has probably the most significant efforts to secure it of anything of its size, or at least it's in the top 5 * This codebase suffered enouguh critical vulnerabilities for users to be attacked in the wild So let's be clear - Chrome suffers from thousands of memory safety vulnerabilities, but not many make it to ITW exploits. This case is special because users actually suffered because of it. It isn't fair to say they've had "one security issue", certainly, just one that's had major user impact. I'm not judging C++ or the choice to use it. I am saying that this is an example of a very hardened system not being able to compensate for memory unsafety.