Zig's Andrew Kelley: "The compiler is too dam slow, that's why we have bugs..."

[user1234]

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:
> On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:
>> I'm glad Andrew too has realized in what order to fix things - 
>> we all should consider performance-problems bugs.
>>
>> See:
>>
>> https://youtu.be/5eL_LcxwwHg?t=565
>
> He thinks they have bugs because the compiler is too slow? That 
> is truly remarkable.
>
> Does Rust accumulate open bugs at the rate we have been seeing 
> for years in the Zig project? The Rust compiler is far slower 
> than the Zig compiler. I've used them both. Haskell? GHC is 
> pretty slow, too.
>
> I'm surprised by this, because Andrew usually seems like a 
> smart, sensible guy. Had he said "We've got lot of bugs. 
> Speeding up the compiler would help to increase the rate at 
> which we can fix them" I wouldn't have reacted this way. 
> Perhaps that's what he meant. But that's not what he said.
>
> And I can tell you from personal experience that the open bugs 
> are a big issue with Zig. Every time I've checked in with Zig 
> (it's been three or four years) and tried to use it, I run into 
> a serious problem with the compiler. Zig is not good enough yet 
> for production work
> [...]

How many times this would have to be repeated: A software with no 
bugs is a software that is not used or tested. It's pretty common 
to see a huge amount of bugs opened in the bug tracker of a 
programming language (sure when it's a mono-repo, that can be 
dramatically big).

- LLVM, clang: 20,530 k
- SWIFT: 6,279 k
- etc.

Just to say the count of bug is not the metric you think it is. 
Amount of bugs can also say "very popular product". People use it 
and find problems.

I tend to think that the ratio opened/closed is a better metric, 
assuming tickets have something to say: do they go into the wall 
? do they manage the problems ? Are they falling into a black 
hole ? etc.