Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google fixed more Chrome bugs in June than over the past two years, thanks to AI

blog.google

Post reply on HN
Print view View original

561–570 of 667 posts

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#561

Post by inigyou »

insanitybit wrote: post #516
inigyou wrote: post #483

Earlier quoted context omitted.

Sometimes when you look at code you know is slow, you can immediately see why it's slow. Obviously you didn't see it when you wrote it, which disproves your hypothesis.

What? Sorry, I genuinely have no idea what you're talking about. Is it possible to look at code and intuit, just by reading, how to speed it up? Duh, yes. If you disagree, lol. Keep in mind that I've never stated that all performance issues are findable through code review. Just that there are many that are. > You can very easily spot performance issues through code. If you think that this is false, there's literally…

Demonstrate for me, then.

Here's some slow code: https://github.com/torvalds/linux

Speed it up.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#562

Post by inigyou »

ygjb wrote: post #529
inigyou wrote: post #277

Earlier quoted context omitted.

What does that mean? Democratising the breakthroughs you can point LLMs at?

Until a couple of years ago you needed to be able to read research papers and code to build fuzzing harnesses and triage the findings to find vulns. Now you can point Claude, codex, Kimi, or even some smaller open models that run local and get a servable fuzzing loop in a couple of hours. That's democratization - shifting power and skills away from those with the wealth to purchase vulns and run offensive security te…

Instead you need the wealth to buy infinite tokens, right?

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#563

Post by fluffybucktsnek »

rustfreeforme wrote: post #533
rpdillon wrote: post #487

Earlier quoted context omitted.

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?

[dead]

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.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#564

Post by jkrejcha »

xyzsparetimexyz wrote: post #541
hn_submit wrote: post #431

Earlier quoted context omitted.

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.

How is it high level assembly? Have you written much assembly recently?

C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets

For example, I kinda know that the code

    for (size_t i = 0; i
...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc.

This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#565

Post by lelele »

throwaway2037 wrote: post #560
hn_submit wrote: post #389

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 concer…

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…

> 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.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#566

Post by budsniffer952 »

userbinator wrote: post #550

What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI. The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.

[flagged]

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#567

Post by xigoi »

sitzkrieg wrote: post #451
hn_submit wrote: post #431

Earlier quoted context omitted.

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.

yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that

You can have that without writing them in C or C++.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#568

Post by sothatsit »

calmingsolitude wrote: post #556
murukesh_s wrote: post #555

Earlier quoted context omitted.

If that is the case, isn't that the failure of your testing strategy/setup? If your style doesn't fit full vibe coding - you can do the path of AI generate code - human reviews and tests all edge cases flow - I think in any serious software - that should be the flow until next few iterations. But either way, don't see a going back to coding every line by hand now, those days are gone. Was fun while it lasted!

No. I’ve heard this argument multiple times before - “let the human review and write tests” - and sure it might work, but this is almost never practiced. AI makes coding a lot faster, so no one is really ready to spend time on manual review and writing tests when LLMs can do that as well and take you most of the way.

This is evidence of culture problems in whatever teams you are a part of, or extrapolating what you see on social media to all of software engineering.

We still have a very strong review culture, and people work hard to review their own code before making PRs to avoid wasting other people's time.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#569

Post by sumitkumar »

userbinator wrote: post #550

What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI. The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.

Google improved chrome by reading code: Google built an agent harness using Gemini to scan Chrome's codebase, trained on a knowledge base of prior CVEs and the entire Git history, with a "critic" agent consuming developer-supplied SECURITY.md files.

In my experience, I find it to be exceptionally good at exploring and fixing the edge cases. Of course the output is not human maintainable for these fixes and needs to be heavily tests controlled, refactored or just accepted as being agent-maintained going forward.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#570

Post by xigoi »

tmp10423288442 wrote: post #457
frizlab wrote: post #148

Earlier quoted context omitted.

In $COMPANY, for the mid-yearly review, the employees were asked whether their AI usage was 1/ efficient, 2/ adoptive (integrated in the way they work) or 3/ transformative. Saying “never used it” or “I tried and it was useless” was literally not possible.

You'd have to be a pretty stubborn software engineer to not find AI useful for anything at this point, unless they're making you use Github Copilot or something far behind the frontier. You don't have repetitive tests to write? You never need to write a script to run something?

I don’t use AI for ethical reasons. I don’t want to support companies that are destroying the planet and inflating hardware prices.
Post reply on HN