why?
because You know C
I write games in C (yes, C) (2016)
261–270 of 288 posts
Re: I write games in C (yes, C) (2016)
#262Earlier quoted context omitted.
>Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages linux attracted 2,134 developers in 2025 that kinda weakens your argument a little bit
Maybe (and I like C, for the record), but it doesn't follow necessarily. It's possible most of those devs were attracted by "working on linux," and are putting up with the pain of collaborative C. I know there's a movement pushing for more Rust.
I think the popularity of Rust for Linux is also in part a reflection of internal discontent with poorly documented and sometimes straight up poorly understood kernel internal APIs.
When a developer asks Can I Fizzle this Doodad? C is comfortable with the answer being "It'll definitely compile but whether it would work is complicated - ask the expert on Fizzling and the Doodad expert, and hope they give the same answer" but Rust wants the answer to be "Yes" or "No" or at the very least, "Here is some actual text explaining when that's fine"
Sometimes it really is hard work to figure this out but for a project as big as Linux even in those cases it's often worth doing that hard work, because you unlock something valuable for every non-expert contributor and Linux has a lot of those.
Re: I write games in C (yes, C) (2016)
#263Plenty of people cycle on a fixie too. So what? C, especially modern C, does provide metaprogramming and abstraction facilities. In practice, you can even get things like the "defer" construct from other languages: https://lwn.net/Articles/934679/ The question isn't "Can I write a game in C?". Yes, of course you can, and it's not even that painful. The question is "Why would you?", and then "Why would you brag about…
> People say, out loud, "I use C and not C++" to say something about themselves. ISTM that certain circles there's this perception that C is somehow more hardcore.
Sounds like this is just you projecting.
Almost any language has fewer footguns than C++, and thus programmers will take almost anything else over C++.
It's just incidental that "anything else" also includes C.
Re: I write games in C (yes, C) (2016)
#264Earlier quoted context omitted.
The performance gains from bit-level control over memory come from managing the layout to ensure cache locality and do things like SIMD - and nowadays even GPU kernel offload. Enormous performance gains. I agree that it really isn't about garbage collection pauses, but I haven't heard people focusing on "eliminating gc pause" when they talk about low level languages, but they spend a lot of time talking about SIMD, G…
Go defines structs the same way C does, so it's already encouraging thinking about and optimising the physical data layout. It also recently added experimental support for SIMD intristics: https://go.dev/doc/go1.26#simd . Nothing on GPU side yet though, but I wouldn't be surprised to see it there eventually too :)
Yes, I know Go's structs are similar to C in terms of syntax, but does the Go compiler guarantee the same bitwise layout for its data structures? Most GC languages add metadata to the data structures to track GC status, and this changes both the memory layout and the word alignment, which then sometimes forces the language to add extra padding to maintain alignment. And this nests as you put one struct inside another, or an array inside a struct.
Now you have "fat arrays" and "fat structs", so instead of grabbing a pointer and loading the next 128 bits into memory and doing an operation, you have to grab the pointer, read out data from individual elements, combine them, create a new element with the combined data, and then you have a 128 bits. But even then, you don't know whether you have 128 bits or not. Some gc-specific metadata might have been added by the compiler (and probably was).
Bottom line, it's very hard in the GC world to have bit-wise control over memory layout, even if user-level syntax of "structs" is the same. And one consequence of that is that you can't just "do" SIMD in Go. You have to wait for Go to expose a library that does this for you, and you will always be limited by what types of unpacking/repacking the language designers allowed you to do.
Or, you are stuck with hoping the compiler is very smart, which is never the case and requires huge compile times for marginal gains in compiler smarts.
So it's not about GC collection pauses so much as no longer having access to memory layouts.
Re: I write games in C (yes, C) (2016)
#265Earlier quoted context omitted.
> 1. avoids confusion, no matter how unlikely it is in a context like HN Who would be confused by "Go", but not "Rust" and "Zig", which are also common English words not usually associated with programming languages? > 2. search engine "findability". What kind of search engine are you using in 2026 that isn't capable of understanding context? And where one is still using some weird antique thing like a steampunk char…
At least with regards your second point, Google, DuckDuckGo, all other search engines. I always have to add "golang" because otherwise it just fucks up. I have to say that googling for "C", is a lot more dire, and because the LLVM people called their frontend "clang" I can't even use that, otherwise only clang stuff pops up. And even then, once I did manage to convince the search engine that I'm looking for the progr…
> I can't even use that, otherwise only clang stuff pops up.
The searchable form is 'clanglang'. golang is the language compiled by the go compiler, like erlanglang is compiled by the erlang compiler, and clanglang is compiled by the clang compiler.
Re: I write games in C (yes, C) (2016)
#266[dead]
Re: I write games in C (yes, C) (2016)
#267Earlier quoted context omitted.
I'll take things that never happened for $500, Alex
I searched harder, just for you. https://stackoverflow.com/questions/5508110/why-is-this-prog... How would you like to send the $500? Monero is acceptable.
> I searched harder, just for you.
I know this one! How did you waste your time?
> How would you like to send the $500?
Simpsons already did it. Well, at least it is a lot funnier than that PNG thing.
Re: I write games in C (yes, C) (2016)
#268Earlier quoted context omitted.
> Complaining about a language having features you don't want is silly. If your criteria for a good language is "how many features does it have", then sure, C++ wins. OTOH, if you criteria is "How many footguns does the language have" then C++ loses to almost every other mainstream language, which includes C. Sometimes the lack of footguns is a plus.
Surely your criteria should be some combination of the two (plus other factors). C may have fewer footguns than C++, but it still has many, whilst also lacking many useful features
> Surely your criteria should be some combination of the two (plus other factors).
Sure, but the weighting would be different for different people.
> C may have fewer footguns than C++, but it still has many, whilst also lacking many useful features
We are not talking "2 fewer footguns", or "5 fewer footguns"; we are talking "dozens fewer footguns".
When I need a language with more features than C, I don't choose C++, because the choice is not "Use C for simplicity, and use C++ to trade simplicity off against features", it's usually "Use C for simplicity, and use Java/C#/Go/Rust for features".
Re: I write games in C (yes, C) (2016)
#269Earlier quoted context omitted.
Yeah, you could argue that choosing C is just choosing a particular subset of C++. The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
C's string handling is so abominably terrible that sometimes all people really need is "C with std::string". Oh, and smart pointers too. And hash maps. Vectors too while we're at it. I think that's it.
Re: I write games in C (yes, C) (2016)
#270Earlier quoted context omitted.
Go defines structs the same way C does, so it's already encouraging thinking about and optimising the physical data layout. It also recently added experimental support for SIMD intristics: https://go.dev/doc/go1.26#simd . Nothing on GPU side yet though, but I wouldn't be surprised to see it there eventually too :)
Yes, I know Go's structs are similar to C in terms of syntax, but does the Go compiler guarantee the same bitwise layout for its data structures? Most GC languages add metadata to the data structures to track GC status, and this changes both the memory layout and the word alignment, which then sometimes forces the language to add extra padding to maintain alignment. And this nests as you put one struct inside another…
> does the Go compiler guarantee the same bitwise layout for its data structures
It probably won't be fully 1:1 with C, but it's good enough that you can write code like this and it works: https://github.com/fsnotify/fsnotify/blob/main/backend_inoti... (unix.InotifyEvent is just a Go struct: https://pkg.go.dev/golang.org/x/sys/unix#InotifyEvent)
> Now you have "fat arrays" and "fat structs", so instead of grabbing a pointer and loading the next 128 bits into memory and doing an operation, you have to grab the pointer, read out data from individual elements, combine them, create a new element with the combined data, and then you have a 128 bits.
That is not how it works, you get real pointers that you can even do math with using unsafe package.
> Most GC languages add metadata to the data structures to track GC status, and this changes both the memory layout and the word alignment, which then sometimes forces the language to add extra padding to maintain alignment
Go GC uses a separate memory region to track GC metadata. It does not embed this information into structs, arrays, etc, directly.
> And one consequence of that is that you can't just "do" SIMD in Go. You have to wait for Go to expose a library that does this for you, and you will always be limited by what types of unpacking/repacking the language designers allowed you to do.
You very much could, thanks to what I described above. You'll have to write assembly (Go supports assembly), and it's even used in some e.g. crypto libraries not just for performance reasons, but to ensure constany-time operation too.
The downside of using assembly is that it doesn't support inlining, and there's a small shim to keep ABI backwards compatible with the original way functions were called (using stack, whereas newer ABI uses registers). So you need to write loops in assembly too to eliminate the function call overhead. The SIMD package solves this issue by allowing code inlining.