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

471–480 of 668 posts

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

#471

Post by Dylan16807 »

gtowey wrote: post #414
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…

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…

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

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

#472

Post by emilfihlman »

hn_submit wrote: post #431
gtowey wrote: post #414

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

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.

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

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

#473

Post by asdff »

hn_submit wrote: post #454
sitzkrieg wrote: post #451

Earlier quoted context omitted.

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

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

You can’t compare apples to elephants here.

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

#474

Post by akersten »

gtowey wrote: post #414
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…

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…

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.

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

#475

Post by hokapo »

fzeroracer wrote: post #207
hokapo wrote: post #154

Earlier quoted context omitted.

I think the main cause of different views is just the fact that people have very different products and codebases they're working on. Therefore, the requirements and applicability of AI varies a lot, case-by-case. It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details, but at least some transp…

> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big Hi, professional game dev here. No it's not. Thank you for reading.

Yeah, as I said in a reply to another comment, I oversimplified there. What I should have said is that solo or almost-solo gamedev with relatively small games is a good example of where AI shines. I don't have experience of developing larger games in larger teams.

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

#476

Post by leptons »

hn_submit wrote: post #454
sitzkrieg wrote: post #451

Earlier quoted context omitted.

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

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

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.

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

#477

Post by dpark »

cyanydeez wrote: post #438
dpark wrote: post #413

Earlier quoted context omitted.

I don’t understand how LLMs make more stuff “bike sheddable”. What LLMs do is allow people to contribute low value garbage to all areas, but we have a word for that and it’s not “bike shedding”. It’s “slop”.

bike shedding is slop; you're arguing with some anchored semantics where culture, terms, etc are fluid. Can only assume english might not be your first language.

I hope this weird redefinition of bike shedding doesn’t take off. It’s a useful and meaningful term and repurposing it to mean AI slop is negative value.

Thankfully until this thread I’d never seen anyone use the term this way.

> Can only assume english might not be your first language.

This not-subtle insult does not add anything here.

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

#478

Post by tikhonj »

gtowey wrote: post #414
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…

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 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 :)

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

#479

Post by Alpha3031 »

leptons wrote: post #476
hn_submit wrote: post #454

Earlier quoted context omitted.

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

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.

There are a lot of applications like that though, only they're all being rewritten for electron.

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

#480

Post by inigyou »

hn_submit wrote: post #431
gtowey wrote: post #414

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

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.

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.
Post reply on HN