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

On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

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, nor do they claim to be, simply based on the version number with the leading zero. But Andrew's marketing flair seems to have attracted a lot of followers. At least in the compiler area, D seems to be the opposite. No marketing flair, but DMD in my experience is rock solid (and FAST). Even the much-maligned Phobos has worked well for me. D's documentation, though far from perfect, is far better than zig's, which I think is absolutely awful. I'm not so enthusiastic about dfmt and dub.

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

Ok, thanks for the overview. I agree with what you're saying. I wonder why Zig has so many open bugs. Could it be the complexity of the incremental compilation and hot-code-reloading?

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

In a causal sense they're unrelated, but if a program takes far longer than it "should"
for the amount of work it's doing, then I would expect bugs.

Speed comes from creative people understanding a domain really well. Slowness usually comes from code that solves a problem in a weird/roundabout way (usually because its the first attempt).

In compilers in particular after a certain amount of time working on a codebase it's somewhat easy to see a bunch of places where you could make things faster/correct-er and so on, but these are often serious engineering projects to even try unless the compiler is particularly well put together i.e. other than the speedups that come from chesterton's fences (i.e. "the C standard says...").

It doesn't seem alien to me that codebases that can be made fast (which these days basically means getting to the heart of a problem in a self-contained atom of work that you can cache properly) are less buggy in some limit.

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

You should have stayed more than 5 seconds on the video. He literally said that "Because it takes too much time to fix them. If we could reduce that slice of compiling time to almost inexistent, we could spend more time fixing the bugs".

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

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.

On Monday, 29 January 2024 at 20:51:19 UTC, Don Allen wrote:

Yeah, I tried it a while back, but it didn't last long. It seemed like a nice community and the language sounds like it has good ideas. I felt as if they hid the "not ready for any serious use". This is in contrast to D, which around the time I started using it, any story would have false comments about compiler bugs. I've hit more bugs in gcc than in dmd in that time.

While a faster compiler might help, my impression was that they made a strategic error by trying to do too much, and that meant there was no small core of features you could count on to be reliable. It's been quite a while, so that may not be true in 2024.

On Monday, 29 January 2024 at 08:04:57 UTC, Per Nordlöw wrote:

They pay the debt of the initial joy. Too much done without discipline. Now little hands are required to fix that.