[flagged]
Google fixed more Chrome bugs in June than over the past two years, thanks to AI
651–660 of 668 posts
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#652Earlier quoted context omitted.
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. It…
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 e…
> And the barriers are far more social, organizational and political than they are technical.
At the core it's even more of an economic barrier which isn't even unique to capitalism.
I recall an article talking about why the Romans didn't invent steam engines and things like railroads considering people were aware that steam could be used to do work. The answer was largely that slave labor was so cheap that nobody really cared about finding more efficiency. It didn't solve any problem they had at the time.
The analogy transfers to the tech industry today, economics tend to drive most decisions. While I love technology and think research and innovation is important for its own sake -- particularly because we might not know what we're missing out on unless we explore -- but those controlling the purse strings have other priorities.
Others might point out that the economic cost of the bugs and failure cases in programming languages without memory safety might actually be greater than the cost of developing alternatives or accepting less performance in exchange for correctness. They're probably right! But unless you can measure it and present it on a spreadsheet to the management class, they won't acknowledge or understand it. It's really difficult to measure "incidents you didn't have". In any case it still might be cheaper to work on the next big startup idea, hype it & sell equity -- that strategy has produced trillion-dollar valuations recently. However correctly or incorrectly that may be, the benefit to an elite few is very real.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#653Not that I don't believe its possible to fix a lot of bugs, I also wonder what the actual dynamic was. Were the people in team working much more than usual as well? Given its Google, I wouldn't be surprised if there was an "internal push" to fix more bugs over next X sprints so that they can publish this blog and some manager can show impact and AI adaption to his superior.
I will say - and this is just my own experience and not a certain userwide trend response - that one benefit of LLMs is that they are able to take an annoyed observation and format it into a pretty stellar bug report, and then the human being can work on spit-polishing. Having the middle part of the composition automated is a real benefit (at least IMO) - I've been a better reporter.
I previously reported on my own and was ignored; now, not so much. I assume that the assistance by the LLM is providing needed detail or formatting. (Yes, I am reading what I am submitting and making sure it is optimal before sending it.)
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#654Earlier quoted context omitted.
[dead]
> Tell me why you think you're right. The more verification you do, the more likely it is for a program to be correct. Lean towards Assembly, and you get less correctness, but lean towards Ada/SPARK, and you get more. Rust is a notoriously difficult language specifically because it adds some limited verification features, going further along that correctness continuum than C. I didn't think that could even be dispute…
+1 for the Blub Paradox. First time I'm hearing it.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#655Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#656[dead]
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#657Earlier quoted context omitted.
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.
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.
When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code.
Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change.
So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change.
Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers).
Did bugs still get missed? Of course, just like today even with today's new tools.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#658To 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 concer…
> 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.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#659Earlier quoted context omitted.
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. It…
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 e…
> ... don't value correctness or security enough
Wrong. It is the market that doesn't value correctness or security enough.
We have the tools (formal verification) to create bug free software (see seL4 and CompCert for example). However customers are not willing to pay for the extra cost needed.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#660Earlier quoted context omitted.
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 e…
The real curious thing is serious C/C++ folks seem like one of the least likely groups imaginable, to want to undergo humiliating and embarrassing blunders… Yet they seemingly don’t mind that it practically guarantees them to make blunders over and over again.
Show me a programming language that doesn't result in developers "making blunders over and over again" when developing the kind of very large software C/C++ is used for.