Live data from Hacker News

Usability Improvements in GCC 15

developers.redhat.com

191–200 of 231 posts

Re: Usability Improvements in GCC 15

#191

Earlier quoted context omitted.

Clang: - has about the same quality of error messages as GCC now - is now almost exactly as slow (/fast) as GCC at compiling now - sometimes produces faster code than Clang, sometimes slower, about the same overall I see no reason why the default would change.

well for one clang uses way less memory (RAM). also ld.lld is wayyyyyyyy faster than ld (and also uses way less memory).

ld.lld works with any compiler, and anyway, mold is even faster and also works with any compiler.

Re: Usability Improvements in GCC 15

#192
post #179
post #135

Earlier quoted context omitted.

GNU isn't Unix as NT isn't Win32. Gnu promotes Unix, but also promotes Emacs on top. NT can run Win32 on top of it, but there's far more than Win32 with NT systems. Just get ReactOS and open the NT object explorer under explorer.exe. Far more advanced than Windows 95/98.

Win32 is an API, while UNIX, NT and GNU are all operating systems made by AT&T, Microsoft and the GNU Project respectively. I agree that the GNU operating system isn't the UNIX operating system, and I agree that the NT operating system isn't the Win32 API, but I have no idea what comparison you're trying to draw. It almost sounds like you think UNIX is an API like Win32, and that GNU is an operating system which "imp…

No, I'm not confusing Unix with POSIX, but POSIX today superseded old Unix. What I mean both NT and GNU enhanced and modernized their own subsystems.

Even OpenBSD is not as 'pure Unix' as Unix V7.

Re: Usability Improvements in GCC 15

#193

Earlier quoted context omitted.

I don't know, you wanted to grep for the emoji.

That's what you think? I wanted something I could grep for easily. Which doesn't seem to be the emoji, since it needs extra software to get on the grep command line...

It's not a "what I think" thing, these were your literal words:

> How do you grep for it

And then how badly or well this works will depend on your build of grep and your environment variables, as the other user noted. I did not consider this, because I'd expect grep to just work with Unicode symbols like this when my stdin is set to UTF-8, which I'd further expect to always being the case in 2025, but it appears that's not an expectation one can reasonably have in the *nix world.

It was and continues to be unclear to me why you'd want to grep for the warning emoji though, since according to the article these are inserted somewhere deep in the console-visual explanations. They do not replace the slug denoting the compiler message type at the start of these, which as you said, can (still) be found by just grepping for "warning".

Re: Usability Improvements in GCC 15

#194
post #180

Earlier quoted context omitted.

Dude you can't just quote a fraction of a sentence and then argue against that fragment. Read the whole sentence. The part about how "the vendor could make their toolchain proprietary" is kinda important.

My comment was about proprietary software being open sourced.

My comment was about forcing companies to not make proprietary software.

Re: Usability Improvements in GCC 15

#195

Earlier quoted context omitted.

That's what you think? I wanted something I could grep for easily. Which doesn't seem to be the emoji, since it needs extra software to get on the grep command line...

It's not a "what I think" thing, these were your literal words: > How do you grep for it And then how badly or well this works will depend on your build of grep and your environment variables, as the other user noted. I did not consider this, because I'd expect grep to just work with Unicode symbols like this when my stdin is set to UTF-8, which I'd further expect to always being the case in 2025, but it appears that…

> xpect to always being the case in 2025

Oh but in the real world you vpn into a server that privately tailscales to some boxes that are hard to reach inside a factory and no one has physically touched them since 2018 at best ...

What's this 2025 you speak of? Not in production.

Re: Usability Improvements in GCC 15

#196
The writer David Malcolm tells a story in his article about compiling C17 code and pretending it's C23. Duh, no wonder it breaks!

You C standard authors have it bass-ackwards. The version of the code must accompany the code, not the compiler invocation.

Re: Usability Improvements in GCC 15

#197

Earlier quoted context omitted.

It's not a "what I think" thing, these were your literal words: > How do you grep for it And then how badly or well this works will depend on your build of grep and your environment variables, as the other user noted. I did not consider this, because I'd expect grep to just work with Unicode symbols like this when my stdin is set to UTF-8, which I'd further expect to always being the case in 2025, but it appears that…

> xpect to always being the case in 2025 Oh but in the real world you vpn into a server that privately tailscales to some boxes that are hard to reach inside a factory and no one has physically touched them since 2018 at best ... What's this 2025 you speak of? Not in production.

Don't remind me lol, even worse when it's a fresh VM but the software is still ancient.

Re: Usability Improvements in GCC 15

#198

Earlier quoted context omitted.

gccrs is a rust implementation for gcc. Just because Rust developers don't want their users to be fully free doesn't mean there are any problems with gcc. And clang is developed by Apple which is a huge warning sign by itself.

LLVM/Clang is evolving more quickly than and is a much richer base for innovation than GCC is. LLVM spawned Rust, Swift, and Zig. The most recent GCC languages are Spark and COBOL. One of the reasons that LLVM has been able to evolve so quickly is because of all the corporate contribution it gets. GCC users want Clang/LLVM users to know how dumb they are for taking advantage of all the voluntary corporate investment…

GPL gives more freedom to software users. BSD gives more freedom to software developers.

I think that's the core difference.

Re: Usability Improvements in GCC 15

#199

Earlier quoted context omitted.

Emoji selector is fast and works perfectly fine over SSH, it's no different to any other input method that needs to use characters beyond 7-bit ASCII. grep is a bit more iffy. UNIX command line tools seem to be a bit of a crapshoot in how or if they support Unicode, especially if you switch between different systems like Linux, BSD, Cygwin etc. You might need a bit of experimenting with the LANG variable to get it wo…

> that's a win for non-English users of the command line I am non english. I use ăâîșț. When writing a text document for humans. I also use :) but not . I'm still of the opinion that anything not 7-bit ascii doesn't belong in something that may be machine processed. Which includes compiler output. Edit: hey, HN erased my emoji. The dot was supposed to be the :) emoji style.

Didn't you ever grep a text document written in a language other than English? No processing of CSV files in different charsets? Not even encountered a file with a non-English character in the name? Not to mention the folks who deliberately set LANG so that their compiler and everything else will give them localized error messages. This stuff was all much worse 25 years ago, even 15 years ago. Like them or not, I do think emojis have helped drive forward much better Unicode handling across the whole stack, including the command line.

Re: Usability Improvements in GCC 15

#200

Earlier quoted context omitted.

This type of thinking is what doomed uBlock Origin. I strongly disagree.

How is uBlock Origin "doomed" ?

An advertising company controls the user agent everyone uses to access the internet, and wants to shove more ads into your eyeballs. uBlock exists as long as they allow it. Anyone who disagrees with this, works for them or own shares in the company.
Post reply on HN