| ▲ | hn_submit 3 hours ago |
| 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 the mental memory model of C and C++, namely manual memory management. It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability. C and C++ are simply not fit for purpose when large scale software projects are concerned. All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem. The hundreds if not thousands of developers working on Chrome weren't idiots who didn't know what they're doing. The complexity of programming in C/C++ is simply beyond most intelligent individuals' ability to get perfect all the time. |
|
| ▲ | gtowey 3 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | tikhonj 26 minutes ago | parent | next [-] | | A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value correctness or security enough. We didn't have good alternatives until recently because we did not, collectively, invest in developing these alternatives. One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year. Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change. So really, the problem isn't that people complain too much, it's that they don't complain enough :) | |
| ▲ | akersten 33 minutes ago | parent | prev | next [-] | | It's not a fair take in the sense that replacing the backbone of lead solder plumbing and paint in 1960's wasn't a fair take, and plenty of us are still awaiting the lead-free replacements. That doesn't mean we shouldn't do it. | |
| ▲ | Dylan16807 an hour ago | parent | prev | next [-] | | Computers have gotten more than an order of magnitude faster since safer languages got into the same speed and memory ballpark as C, but we keep wasting that speed. The model T of memory safety was Java 31 years ago. (I'm not sure what lisp is in this analogy.) | |
| ▲ | hn_submit 2 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | inigyou 25 minutes ago | parent | next [-] | | C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power. | |
| ▲ | sitzkrieg 2 hours ago | parent | prev | next [-] | | yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that | | |
| ▲ | Dylan16807 an hour ago | parent | next [-] | | Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean. | | |
| ▲ | uecker 16 minutes ago | parent [-] | | The C programs I use daily are generally very fast, very lean and very stable: Programs such as linux, terminals, shells, vim, etc. |
| |
| ▲ | krior an hour ago | parent | prev | next [-] | | false dichtonomy | |
| ▲ | hn_submit an hour ago | parent | prev [-] | | 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). | | |
| ▲ | asdff 34 minutes ago | parent | next [-] | | You can’t compare apples to elephants here. | |
| ▲ | leptons 28 minutes ago | parent | prev [-] | | File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction. The programs that do benefit from speed aren't file browsers. | | |
| ▲ | Alpha3031 25 minutes ago | parent [-] | | There are a lot of applications like that though, only they're all being rewritten for electron. |
|
|
| |
| ▲ | emilfihlman 44 minutes ago | parent | prev [-] | | >therefore lacks any guard rails you'd expect in a programming language This is simply not true. Guardrails are enforced by the compiler, and both gcc and clang have a myriad of flags to make C safe, not to mention Fil-C. |
| |
| ▲ | jdm2212 2 hours ago | parent | prev [-] | | They're working on it for Linux: https://rust-for-linux.com/ |
|
|
| ▲ | rpdillon 3 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | hn_submit 2 hours ago | parent | next [-] | | I assure you that Microsoft knew for years that there were thousands if not tens of thousands of memory related bugs lurking in Windows. But their policy was "don't fix" (and "don't look") unless a remotely exploitable vulnerability was making headlines. Because every minute a developer spends finding and fixing bugs is a minute he can't spend on adding new features customers will pay for. Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner. | | |
| ▲ | davidjade 2 hours ago | parent [-] | | And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary. | | |
| ▲ | hn_submit an hour ago | parent [-] | | Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs? Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile. |
|
| |
| ▲ | dingaling 2 hours ago | parent | prev | next [-] | | > Saying they're not fit for purpose doesn't seem correct. I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration. Writing a browser in C++ in the 21st century was ridiculous and irresponsible. | | |
| ▲ | aenis 2 hours ago | parent [-] | | Ekhem. When Chrome was announced there wasnt Rust. And Java was a programming language for slow moving systems, with many a flaws and its own classes of footguns. I dont think they had much of a choice in 2008. Now? Sure. I bet a rust port is in the works. | | |
| ▲ | floil an hour ago | parent [-] | | This is correct (I worked on chrome in 2008) it's important to remember that chrome's renderer was webkit, an existing c++ stack. Chrome's stability innovation was to run different tabs in different processes, and the security innovation was then to sandbox those processes. Rust would have been super nice but it wasn't an option then, and of course let's remember that Rust was developed by Mozilla specifically with the goal of making safer browsers. |
|
| |
| ▲ | raverbashing 3 hours ago | parent | prev [-] | | Well we make work with the tools we have It worked well enough, maybe "fit for purpose" is a stronger word | | |
| ▲ | rpdillon 4 minutes ago | parent [-] | | 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? |
|
|
|
| ▲ | rhdunn 3 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | azakai an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | bschoepke 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | hn_submit an hour ago | parent | next [-] | | Why is everyone always referring to logic errors when pushing back against Rust? No programming language ever invented (or to be invented) will fix logic errors made by developers. Logic errors are "out of scope" for Rust or any other programming language. | |
| ▲ | margorczynski an hour ago | parent | prev | next [-] | | 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 7 minutes ago | parent [-] | | 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. |
| |
| ▲ | Ar-Curunir an hour ago | parent | prev [-] | | It does help for logic errors too, with, eg, sum types and traits and abstraction. Also better defaults. |
|
|
| ▲ | wilg 2 hours ago | parent | prev | next [-] |
| 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! |
|
| ▲ | ls-a 2 hours ago | parent | prev [-] |
| blaming bugs on C++ has got to be the most leetcode thing I've heard in my life |