5 ms·

To me this merely signals how broken C++ development really is. Most if not all of the bugs being uncovered are memory related and therefore intimately tied to

• rhdunn 2mo ago
  C++ has had smart pointers for memory (and other resource) management for a long time now (see e.g. the Windows ATL classes for working with COM objects and resources). There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust). 1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated). 2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code. 3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.
  • mbac32768 2mo ago
    Actually, if you implement a JavaScript runtime at all your choice is either too slow for modern web users or `unsafe` everywhere. Runtime values are often simultaneously either words that encode immediates or pointers to heap blocks and doing this the proper way blows up time and space. Doing it the fast way means you have `unsafe` everywhere and Rust's lifetime model can't help you at all. Everyone chooses the fast way. Maybe Rust let's you encapsulate the unsafe a little better than C++ but the wins are going to be surprisingly small. If you had to build it today you'd maybe use Rust but the case for rewriting an existing C based runtime in Rust is not that strong. Also for things like interpreter loops the absence of computed goto in Rust stable is a real performance killer. Explicit tail calls (the `become` keyword in nightly) work but maybe you don't want your big rewrite to rely on that.
• gtowey 2mo ago
  I'll await your Rust ports of Windows, Linux and MacOS then. This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly. Its staying power is due to the fact that we really haven't had many good alternatives until maybe the last few years. Things are not going to get ported and rewritten overnight, especially when they largely just work like Linux & PostgreSQL. We'd nuke a huge amount of institutional knowledge and inertia to change those up. And C/C++ are still key in the embedded space where we still have devices constrained on compute and memory. That's not going to go away anytime soon. This criticism feel like someone complaining about why anyone still uses horses on the day the Model T was announced. Change takes time.
  • jdm2212 2mo ago
    They're working on it for Linux: https://rust-for-linux.com/ https://rust-for-linux.com/
  • hn_submit 2mo ago
    C is literally "high level assembly" and therefore lacks any guard rails you'd expect in a programming language. It's just unfortunate that so many software developers embraced C for its speed, even when it wasn't strictly needed. I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.
    • sitzkrieg 2mo ago
      yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that
      • hn_submit 2mo ago
        I, for one, can't see any speed difference between a program written in Pascal (Total Commander, which I use every day) and one written in C++ (Windows Explorer).
• rpdillon 2mo ago
  The entire compute world was built on top of C and C++. Saying they're not fit for purpose doesn't seem correct. I think what you're really saying is they're not an optimal choice from a safety perspective. > All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem. Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly. Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?
  • raverbashing 2mo ago
    Well we make work with the tools we have It worked well enough, maybe "fit for purpose" is a stronger word
    • rpdillon 2mo ago
      Makes sense, but strangely, no one has responded to my question about why Servo hasn't been picked up, if Rust is such an important factor in browser engine implementation. People are calling using C and C++ "ridiculous" and "irresponsible" and "not fit for purpose". And yet, no one's using the alternative that's sitting right there?
      • rustfreeforme 2mo ago
        [dead]
        • fluffybucktsnek 2mo ago
          People who believe in total unsuitability would be acting silly indeed. But most would agree that writing code on languages that provide better and safer tooling is a positive. Sure, the main Rust compiler currently depends on LLVM, which is currently written in C++. But the rustc team might choose to follow a similar path to Zig and replace LLVM, or LLVM might get rewritten in Rust. Finally, while most bugs are logical, the most damaging ones, security bugs, are primarily related to undefined behavior.
• ls-a 2mo ago
  blaming bugs on C++ has got to be the most leetcode thing I've heard in my life
• bschoepke 2mo ago
  Rust certainly helps for certain classes of errors but doesn't help at all for logic errors or incompletely understood requirements or occasional need for hacks due to business needs.
  • margorczynski 2mo ago
    It basically completely eliminates the most common class of errors which are bugs related to memory management. Hard numbers and statistics show that every application with enough complexity will be riddled with those. It is simply impossible, even for the smartest human minds, to manage this kind of complexity. And this is a fact.
    • uecker 2mo ago
      Somehow, magically, some people managed to write C software that I now use for three decade with not a single crash in all this time.
      • vor_ 2mo ago
        What software would that be, and how do you know there have never been memory-related bugs and vulnerabilities in it?
        • uecker 2mo ago
          Basically all C programs I use, shells, editors, terminals, etc. But I do not claim that there "never has been a memory-related bug" but that it is not "riddled with" memory-related bugs, which I would expect would have manifested in at least one segfault over all these years, which I did not observe.
          • rustfreeforme 2mo ago
            [flagged]
• wilg 2mo ago
  This seems an awful lot like confirmation bias. Web browsers are themselves extremely complicated. Also, this doesn't address why the rate increased, which is the interesting part!
• azakai 2mo ago
  You can also take the opposite conclusion from this: C++ is now viable because LLMs can catch the security bugs. I'm obviously not entirely serious here, but I think this is true to some extent: the number of memory safety bugs in a codebase is finite. Once you have a way to find them, you can drive that number down to zero. C++ has become a far safer language thanks to LLMs - at least if you run the LLMs before you are attacked.
• jeong_jeong 2mo ago
  You make a false equivalence between being an idiot/“didn’t know what they were doing” and not knowing how to properly manage memory. Also, why do you think the devs who worked on google chrome weren’t idiots? Some of the most important and safety critical large scale projects in the history of humanity had/have manual memory management. If you think the effort of doing it correctly is not worth it for certain projects, that may be a reasonable opinion. But the idea that humans cannot write correct C/C++ programs is in direct contradiction to historical fact.
  • thin_carapace 2mo ago
    if you go around pulling out logic flaw arguments and then proceed to commit logic flaws yourself, it isn't a good look man. the quoted statement was "beyond most intelligent individuals" which contradicts your assertion that the argument was stated as "humans cannot write correct C". anyway I do find it ultra amusing how software engineers believe software engineering is the backbone of programming, when in reality it is merely the flesh. we landed men on the moon long before Rust was even zygotic. for all its benefits, the argument to use memory safe languages ultimately serves to benefit large corporations who can faster generate profit by faster churning out code.
    • rustfreeforme 2mo ago
      [flagged]
      • deleted 2mo ago
        [deleted]
      • deleted 2mo ago
        [deleted]
• throwaway2037 2mo ago
  Assume that you are writing a green field project in C++. If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? I don't have a lot of experience with them, but I found it dramatically reduced memory related bugs. I'm a very average C++ programmer, and those templates helped me greatly. Do you think it would help Chrome/ium to use (more) std::unique_ptr and std::shared_ptr?
  • lelele 2mo ago
    > If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? It will, as long as the code uses them correctly all the time, including when refactoring. In the end, that's still manual memory management.
  • tonfa 2mo ago
    At a minimum you'd also need to enable runtime bound checking for span/vector accesses (I think chrome did that).
  • Orphis 2mo ago
    Chrome uses those already, and a few other pointer types that are fit for purpose. For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected. Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).
• zik 2mo ago
  > Most if not all of the bugs being uncovered are memory related I checked the stats. 73% were memory management related issues, mostly use-after-free. The rest were logic errors of various sorts.
• deterministic 2mo ago
  > C and C++ are simply not fit for purpose when large scale software projects are concerned The world runs successfully on C and C++. Ignoring that fact and claiming that Rust will magically remove all bugs is BS^2.