Complaining about a language having features you don't want is silly. C++ doesn't take longer to compile if you don't abuse templates.
It might be silly if you're working on your own. Software that delivers a lot of value is usually developed and evolved not only by team, but by a team with changing members and changing leadership over the project's lifetime. The features used will be the union of all features used over the years, and while it's easy for team leads to allow the use of more features than their predecessors, it's quite hard to reduce them.
Also, you may be forced to use language features you don't want if they're used by libraries whose functionality you do want. For example, when doing low-level programming, I don't like implicit calls that I can't clearly see on the page (e.g. destructors or overloaded operators). But if libraries I want use them, then I'll have those implicit calls. But if the language doesn't have those features, libraries obviously won't use them.
That's exactly the case when it's easiest. If you don't need a feature, just don't use it and case closed. With a team it's harder - you have to force/enforce others not to use a given feature.
> if they're used by libraries whose functionality you do want
If you're using C++ you can just use the C library you would've used otherwise, no?
This is quite important and often overlooked. An annoying fallacy is that people think some features are optional, but once they get heavily used, they aren't anymore. Often they quickly become an requirement and if you don't follow suit, your code is legacy or you are an idiot. But well, I guess I create legacy code upfront and the cargo cultists create modern code that turns into legacy next day.
It actually does though, unless you also drop C++ stdlib usage completely (have you looked at how many lines of code just <vector> alone pulls into each source file? - it's upward of 20kloc and growing with each new C++ version).
And at that point you get into discussions with various C++ camps about why you don't use the C++ stdlib and instead prefer to reinvent the wheel (and this friction with other C++ coders is the main problem of carving out your own subset - it works ok in complete isolation, but software development work hardly happens in splendid isolation and even then you'd might to want to use C++ libraries written by other people from time to time...)
And once you've been dragged into such C++-subset-discussion month after month, year after year, at that point it is much less exhausting to just write plain C. And the C community (if it can be called that) seems to be much less concerned about coding style dogma and generally a nicer bunch to interact with.
FWIW, I switched around 2017 and each time I have to interact with a C++ library for lack of alternatives it's usually not a pleasant experience (with the notable exception of Dear ImGui - but even there I started to prefer the C bindings so that I don't need to strictly separate the UI code from the rest of the code base, which sometimes makes sense, but often not, especially with an immediate mode UI framework).
C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull carries around that vtable pointer even if it goes nowhere near that 10% of the system. This way your Bird code "just works" in C++.
That's not the only way to crack this nut. Idiomatic Rust approach uses vtables only in the Bird code, elsewhere they don't exist, and thus don't take up space in a Duck or whatever that's always a Duck, but in exchange now you're spending more time thinking, because by default there aren't any vtables and so dynamic dispatch isn't possible at all.
So while that C programmer has to implement features by hand, they are at least able to specifically implement the feature they wanted, not whatever was easiest for Bjarne Stroustrup last century.
C programs tend to nudge you into thinking in terms of arrays of data.
For game development you generally want to think this way. The cost of vtables and all the cache misses doesn’t have to be paid. A game has to stream bytes. Many things at once. Rarely single elements at a time.
There is this anti-C++ bias that keeps forgetting that using C++ doesn't mean use every feature.
Just like many keep using C as if C89 was latest, and never adopt anything added in the last 30 years.
The struggle is that if you choose a subset of the language to use and you have dependencies… well you’re including whatever features they use into your subset.
I don’t think C++ is a bad language at all or anything. Just that it nudges developers into certain modes of thinking based on the features it chooses to focus on. Might explain why some developers still choose C.
>> C89
> agree :D
It's not true. Virtual methods table is present only for classes with at least one virtual method. Learn C++ properly before doing such claims.
You can get exactly what you are asking for in C++ using techniques of static polymorphism and CRTP pattern (https://en.wikipedia.org/wiki/Curiously_recurring_template_p... and https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick) along with traits and dynamic dispatch (if needed).
For great examples of the above, see the classic Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples by Barton & Nackman (1994).
What i am pointing out are neither complex nor any magic under-the-hood. They are simply techniques in the C++ repertoire well-known since the early 90's and used in all high-performance C++ libraries.
tialaramex made a big deal out of overheads in C++ dynamic dispatch (which incidentally are pretty minimal) using a trivial example, when performance focused (both time and size) C++ programmers do not use it that way at all. Modeling in C++ can be done in any number of ways and is driven by specific perspectives of the end goal.
Now with reflection even more tools will be available.
Which is why despite all its warts and security flaws, many inherited from C source code compatibility, many domains will keep using it, because they will complain about their missing 1% that no one else uses.
You can write C++ style OOP hierarchy code in Rust but that's not idiomatic, and you can write Rust style explicit dynamic dispatch in C++ but again it isn't idiomatic.
Surprisingly, this is not true. I've written a C++ file only to realize at the end that I did not use any C++ features. Renaming the file to .c halved the compilation time.
After writing that, I wrote my own standard library (it has data structs like vector, hashmap and sets; slices, strings, rng, print, some io functions, and more) which uses a lot of templates, and it compiles in <200ms on both clang and gcc. Many standard library headers take much longer to compile than that. It's not a terrible idea to have your own standard lib if you need quick compile times.
I have a "mini-std" headerfile that's about 500 LoC implementing lightweight variants of std::vector, std::function, a stack-local std::function (unsafe as hell and useful as hell to avoid allocations), a shared-ptr, qsort and some other nifty stuff.
That does a lot of things, but even then I use other patterns that brings a lot of bang for the buck without having to go full C (hint: the stack-local function equivalent gets a lot of mileage).
int a = 3;
foo(a);
// What value has a ?
#define foo(a) a = 12On top of likely having worse performance.
If that were actually true C++ would be a lot easier to accept as a 'C successor'. Instead you have the implicit this-pointer, complicated rules for which constructor or operator overload is actually called, a hidden vtable pointer (not to mention multiple inheritance), then you have public/private/protected, override vs final, const methods (which wouldn't be needed as a separate syntax feature if the this arg wouldn't be implicit) etc etc etc... that a lot of OOP-baggage which a lot of C++ coders probably don't even notice anymore.
A plain C struct with function pointers does indeed make a lot more sense than all the OOP-ism that C++ hides from you ;)
Have you bothered to look how GCC and clang are implemented?
Drivers, and extension points for userspace.
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.
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".
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.
Oh, and smart pointers too.
And hash maps.
Vectors too while we're at it.
I think that's it.
And it wasn't hard to achieve. The idea was to use length delimited strings rather than 0 terminated. This meant that slices of strings being strings is a superpower. No more did one have to constantly allocate memory for a slice, and then keep track of that memory.
Length-delimited also super speeded string manipulation. One no longer had to scan a string to find its length. This is a big deal for memory caching.
Static strings are length delimited too, but also have a 0 at the end, which makes it easy to pass string literals to C functions like printf. And, of course, you can append a 0 to a string anytime.
One of the fun things about Empire is one isn't out to save humanity, but to conquer! Hahahaha.
BTW, one of my friends is using ClodCode to generate an Empire clone by feeding it the manual. Lots of fun!
The latter two (hash maps and vectors), though, are just compound data types that can be built on top of standard C. All it would need is to agree on a new common library, more modern than the one designed in the 70s.
Hash maps are mostly only important because everyone ought to standardize on a way of hashing keys.
But I suppose they can both be “bring your own”… to me it’s more that these types are so fundamental and so “table stakes” that having one base implementation of them guaranteed by the language’s standard lib is important.
I think you want the string slice reference type, what C++ called std::string_view and Rust calls &str. This type is just two facts about some text, where it is in memory and how long it is (or equivalently where it ends, storing the length is often in practice slightly faster in real machines so if you're making a new one do that)
In C++ this is maybe non-obvious because it took until 2020 for C++ to get this type - WG21 are crazy, but this is the type you actually want as a fundamental, not an allocating type like std::string.
Alternatively, if you're not yet ready to accept that all text should use UTF-8 encoding, -- and maybe C isn't ready for that yet - you don't want this type you just want byte slice references, Rust's &[u8] or C++ std::span<char>
Yes, SDS exists, however vocabulary types are quite relevant for adoption at scale.
So that wouldn't really fit C very well and I'd suggest that Rust's String, which is essentially just Vec<u8> plus a promise that this is a UTF-8 encoded string, is closer.
And const references.
And lambdas.
The differences are the usual that occur with guest languages, in this case the origin being UNIX and C at Bell Labs, eventually each platform goes its own merry way and compatibility slowly falls apart with newer versions.
In regards to C89 the main differences are struct and unions naming rules, () means void instead of anything goes, ?: precedent rules, implicit casts scenarios are reduced like from void pointers.
I feel like if you need to implement modern language features, you shouldn't be using C. The entire point of C is to not be modern.
It's arguably irrational to evaluate a language based on this, but you can think of "this code could be better" as a sort of mild distraction. C++ is chock full of this kind of distraction.
A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ultimately forcing the whole team to become an expert in C++ simply because they all will be familiar with a different set of C++ features.
But for a solo dev? No reason not to use it, IMO. It's got a much nicer standard library with a rich set of datastructures that just make it easier to write correct code even if you keep a C style for everything.
Being on Borland ecosystem that was followed by several years of Object Pascal (I was already using TP at the time), and C++.
Never got the point of why to keep using C, other than external constraints like school assignments, jobs requirements or lack of compilers.
A lot of smart people pick and choose what they want from the language, just like religion, they keep the good parts and discard the bad.
Even with the recent extension where it looks like it isn't, the compiler adds one for you.
Regrettably not every C++ feature is free if you don't use it. But there aren't many that aren't.
That's definitely harder.
Mindread much?
This is why zig is a godsend. It is actually simpler than C while being more precise than C!
For example zig can distinguish between a pointer to a single element vs a pointer to an array of unknown length. Where as in c abi, it is all T*
When importing a c lib, you can make it more ergonomic to use than c itself.
Being able to easily import c lib is especially important to game dev, as practically all so called c++ libs also export a c header as they know how important it is.
https://github.com/zig-gamedev has a lot of repos of ziggified c libs used in games.
As for the preprocessor, zig comptime is so much better. It’s just more zig that runs at compile time.
In the gamedev space, I'd say too few of them do.
That said, I also acknowledge that often times I need to solve problems that can benefit from a language that embraces what I call necessary complexity, but do it in elegant ways. Whenever I need to prioritise code correctness, especially memory and concurrency safety, using a mostly functional pattern instead of OOP, but without going as extreme as say Haskell, I unquestionably choose Rust, my favourite complex language. I often work with network code that is highly concurrent, must be as correct as possible and benefits from good performance, so then again, Rust feels natural here.
On the other hand, I love coding simple indie games and for that particular case, I like a simple and performant language using an imperative, non-OOP style. In my opinion C, and in particular Odin more recently are quite a good fit. If Jonathan happens to be reading this comment, since he mentioned Golang, I would suggest him Odin as perhaps the best of both worlds between C and Golang. It has all the simplicity of Golang, but without a garbage collector, plus it is quite easy to code a game using Raylib.
It's interesting to me that you say this, because it's the exact way that I describe Zig to people. Especially with the new std.Io async / concurrency changes. Do you feel Odin fits the space between Go and C better than Zig? Or just differently, and they both share the same space?
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 character, "C" is going to be the least findable, yet it didn't receive the same treatment. Why is that?
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.
Said frontend is for the C programming language. Isn't that perfectly appropriate? I did a web search for "golang" and the first result was a download page for a Go compiler, so there is precedent.
Which is the best one could hope for given that the search engine doesn't control the content. If I am searching for "golang", a Go compiler is the most likely thing I would want to find. Presumably someone who already has a Go compiler installed will have more specific queries. Likewise, if I am searching for "clang", a C compiler is also the most likely thing I would want to find. For all intents and purposes that is the entry point into using a language.
All in all the search engine did a great job and gave exactly what I would have expected.
And why is it unique to Go? I am sure there are comments on HN about metal oxidization, making sharp changes in direction, Norse gods, and letters of the alphabet.
Whereas the first 50 golang hits are all about the language.
You might have your preferred approach, but there are good reasons for using golang.
Such as? If you type in 'C' into HN's search box, the first result is about the F.C.C., followed by C.E.O., then USB-C. Even once we finally see one about a programming language, it is about C#.
If the earlier list was instead 'Clangclang, Golang, Odinlang and Ziglang' then I could maybe understand where you are coming from, but that is not what we saw. Clearly there was no effort put into aiding searchers universally.
Are you trying to suggest that Go is the only language worth reading about? Let me try to restate the earlier question in your tongue: Why is it unique to 'golang'?
It might end up finding stuff about a compiler though.
>The library support for games[in Go] is quite poor, and though you can wrap C libs without much trouble, doing so adds a lot of busy work.
I can't see when this was written, but it has to be around 2015. So, about 10 years ago. I wonder what his opinion is today.
Also here is a snapshot of the main page of his website from that time, which has screenshots of his games and thereby provides context into what kind of games he had made and published when the blog post was written.
https://web.archive.org/web/20160110012902/http://jonathanwh...
This one looks like it’s 3d and has a pretty unique style:
https://web.archive.org/web/20160112060328/http://jonathanwh...
what am i up to with it? creating hardened vanilla base servers (no mods) and ensuring it gets compiled in a way that doesnt impact lightsaber combat. everyone has failed to do this for 22+ years because there's lots of subfactions in this game who fail to prioritize this as they have other priorities. tons of people who enjoy the prospect of modding the game or making it something different but the tiny remaining competitive player base has only ever needed the base game and what shipped by ravensoft in 2003. generally the guys who are competitive players arent.. coders. the game is ultra sensitive to mathematical FPU differences and virtually all recompiles of the game in the past decades completely failed to guard this, so every game mod and attempt at creating something better hasn't stuck for competitive players _except_ for something called ybeproxy which was an attempt to hook the original game engine binary and add some security/anticheat layer.. this was the best attempt to date but it still negatively impacts the fragile lightsaber mechanics.
I love seeing people try to revive old games and improve them for players. I've made a couple of contributions to VCMI, an open source implementation of heroes of might and magic 3 that I used to play as a kid and it's so rewarding seeing people use those.
Unlike, say, Linux programming where C is the standard, almost all games have been written exclusively in C++ for a long time now, probably three decades.
Also, three decades is going a bit too far back, I think. In the mid nineties, C was still king, with assembly still hanging on. C++ was just one of several promising candidates, with some brave souls even trying Java.
Which is why after so much resistance not wanting to use the NDK for Vulkan, and keeping using OpenGL ES from those devs, Google is bringing WebGPU to Java and Kotlin devs on Android.
Announced at last Vulkanised, there is already an alpha version available, and they should talk more about it on upcoming Vulkanised.
My memory was wrong: I was thinking of the Quake 1 engine, but I just looked it up and it’s C with some assembly code, no C++. The reason I remember it being C++ was because Visual C++ was the compiler tooling required on Windows.
So? Their interface is via C, just like OpenGL was.
Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.
For eg. In very embedded contexts where we were not using any big data structures like struct of strings, not doing any memory allocations etc... C might be easier to reason about than C++. (No hidden code paths). Just allocate something on the stack, pass the pointer to a function to do the computation, done.
In any desktop apis (gui, web servers etc..), where you deal with collections of objects, need to spin up thread pools and rely on results from the future etc... The standard library data structures (vectors, maps etc...) alone makes C++ code a lot more easy to read and review than C. When raw pointers are forbidden, Ownership of memory becomes very clear. Granted my opinion of desktop development comes mostly from very few libraries (Qt vs. Gtk, gstreamer's C API vs. C++ wrapper, http libraries etc...), but there are some problem domains for which C is just insufficient.
Say more with less.
linux attracted 2,134 developers in 2025
that kinda weakens your argument a little bit
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.
Well, this should be reformulated a bit. Using C is not the norm, but it once was and many people are still using C to write games, myself included.
I'm no Go fan, to be clear, but GC isn't the problem with Go. It has a pretty decent GC with sub-millisecond pause times. People who complain about GC pauses while extolling the virtues of manual memory management are running on a set of prejudices from 1999 and are badly in need of a mental firmware update.
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, GPU kernels, and cache misses. If Go could add these features, it would be a performance monster.
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.
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.
I didn't know this, thank you. That's a solid approach.
Yeah, this is from 2016. I don't think choosing C over C++ was defensible even back then, but the critique of Go makes more sense now.
https://web.archive.org/web/20160109171250/http://jonathanwh...
Very useful if you don't want (or need) surprises anywhere. Or if you want all the surprises (exceptions, errors, etc) all better tied to the hardware that provides such.
It's also fairly easy to write unit tests for everything.
But I find string management in C awful and would like to borrow it from C++. Only the string management
I spent about a year trying to sort out that mess and then quit.
To be clear I would still always pick C++ over C because C makes simple stuff (strings and containers mainly) waaaay more painful than they should be. But I also don't really agree with the "C++ is simple - just don't use the complex bits!" argument.
Anyway it's kind of academic now because 99% of the time Zig is an obviously better choice than C and Rust is an obviously better choice than C++.
Things I noticed are inconsistent coding styles, overly complex processes, unused(!) functions, inefficient data use, nothing surprising with a project worked on by various people in their spare time and their own ideas on how to code. And this isn't even talking about later versions. To me it's an example of how unrestricted access to bling features causes a mess.
Eventually I want it converted to C (C23), split apart in seperate functions with a decent source code organisation, and simplified processes to make it easier to understand what's going on and extend fuctionality. For this I need it simplified as possible and weed out the layer of complexity caused by C++ first. Going to take plenty of time, but I'm still having fun doing it (most of the time anyway :-p ).
I'm not advocating anything, but it's satifying to me to bring clarity to code and see small improvements to performance during the process at the same time. It also gave me an opportunity to develop a unique syntax style that visualises parts of the code better for me.
That said, "I am dead" is a very real video game indeed... and his arguments are very sound. I also can't stand C++. I disagree with him on Java though. The core language of Java is actually super simple, like C.
I agree on C++ being the worst of both worlds for many people. You get abstraction, but also an enormous semantic surface area and footguns everywhere. Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admit. The productivity gains mostly come from the standard library, GC, and tooling rather than clever language features. For games, the real disagreement is usually about who controls allocation, lifetime, and performance cliffs, not syntax.
Not only that, but who even knows C++? It keeps changing. Every few years "standard practice" is completely different. Such a waste of energy.
> Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admit.
I know. I used to be a Java hater, but then I learned it and it's alright... except the whole no-unsigned-integers thing. That still bothers me but it's just aesthetic really.
I like the lack of unsigned integers in Java. It simplifies the language while only removing a tiny bit of functionality. You can emulate almost all unsigned math using signed operations, whether you use a wider bit width or even the same bit width. The only really tricky operations are unsigned division and unsigned parseInt()/toString(), which Java 8 added to smooth things over.
https://www.nayuki.io/page/unsigned-int-considered-harmful-f...
Not being facetious, but couldn't you say that about almost any language? What makes you say it about Java?
It's an ongoing struggle!
Time escapes me before I get a chance to type Hello World. Working in front of a screen eight hours a day leaves me exhausted that the least things I want to do is code more on my day off.
Although wanting to dive in to WASM has been a priority and checking Odin for wasm their 3D model example is super cool.
May just have to take a poke. TCL for web frontend; Erlang for DB and potentially Odin for wasm? This could be a cool mix.
Did a bit of game dev in Odin last year and it was a wonderful experience. It's very much game dev oriented and comes batteries included with many useful libraries. And the built in vector stuff is very helpful there too.
Then Watcom C/C++ made it quite easy to use C++ for game development on PCs, PlayStation 2 introduced support for C++, quickly followed up by XBox and Nintendo, and that was it.
the core of games tend to be a 'world sim' of sorts, with a special case for when a select entity within the world sim gets its inputs from the user.
where C becomes a chore is the UI, probably has to do with how theres many more degrees of freedom (both in terms of possibilities and what humans consider appealing) in the visual plane than there is in the game input 'plane', which might be as little as 6 independent inputs plus time.
Try Clay!
Even if you're using C you don't need to implement your own renderer or do half the things he does. Get a library like SDL3 to handle the basics, maybe use Lua/LuaJIT for scripting. Learn OpenGL or Vulkan. Stay away from HH and Casey Muratori until you're experienced enough to tell the difference between his wisdom and his bullshit.
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 it?"
> C++ covers my needs, but fails my wants badly. It is desperately complicated. Despite decent tooling it's easy to create insidious bugs. It is also slow to compile compared to C. It is high performance, and it offers features that C doesn't have; but features I don't want, and at a great complexity cost.
C++ is, practically speaking, a superset of C. It being "complicated"? The "insidious bugs"? It being "slow to compile"? All self-inflicted problems. The author of this article can't even fall back on the "well, my team will use all the fancy features if I let them use C++ at all!" argument pro-C-over-C++ people often lean on: he's the sole author of his projects! If he doesn't want to do template metaprogramming, he... just doesn't want to do it.
I don't read these sorts of article as technical position papers. 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. Nah. Nobody's impressed by using it over a modern language. It really is like a fixie bicycle.
The fixie example wants to make the comparison that using C instead of C++ is deliverately done just to brag about doing something in a way that is more difficult than in should be. In reality the issue is that C++ might not offer you any benefit at all and it could potentially bring you issues later on for things such as interfacing with other languages.
I personally do not see the point of using C++ if you do not use any of its features.
Of course you should use std::unordered_map instead of std::map because the latter is actually a treemap, but you probably don't know that when you first learn it...
(Which quite frankly isn't much of a "standard" when there's about a dozen different real world interpretations of the code depending on which flavor of which compiler from which year that you're using.)
I also don't have to wait eons for my code to compile. Really, the mental and computational load of C has got to be 1/10 of C++.
What a nightmare C++ is, and it just keeps getting worse every year thanks to the incompetent standards committee.
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.
I do.
> People say, out loud, "I use C and not C++" to say something about themselves.
Just like you are telling us something about yourself right now.
> ISTM that certain circles there's this perception that C is somehow more hardcore.
That's not why we use it.
There are certainly many noobs who think C is hardcore. That just goes to show how low the bar has fallen since the masses rushed into computing.
Many of these people also think of changing their own oil or a flat tire as being a superpower. Some could not identify the business end of a screwdriver if their life depended on it. Their opinion on the relatively difficulty or impressiveness of anything is to be taken with a huge grain of salt.
There are many good reasons to use C. If nothing else it demonstrates that the user is a free thinker and not a fucking muppet. It's the sort of thing that attracts me and drives you away. That's valuable.
> Nobody's impressed by using it over a modern language.
1) The word "modern" is not a magic talisman that makes anything it's attached to automatically worthy.
2) "Nobody" does not mean what you apparently think it means. Free clue: others exist in the world beside yourself and your self-absorbed clique.
3) Nobody with a brain is impressed by whatever the midwits are doing. Anyone who can fog a mirror can follow the herd off the nearest cliff. It's the outliers who are impressive.
4) Technically anything since the 1500s is "modern." It's such a vague, useless word that serves no purpose other than "virtue" signalling.
C++ is fucking garbage. Always has been. Keeps getting worse and worse every year. Enjoy your PAGES full of indecipherable gibberish ("error diagnostics"), your miserably slow compile times, and your closet full of footguns and decades old sticks of sweating dynamite. Slowest language by far, other than the so very modern abomination that is Rust. You can keep it.
I know I could do C++, and you could argue that's better, but I find C++ to be exceptionally irritating to use. Every time I've used C++ I get people telling me I'm using it "wrong", sometimes in contradictory ways. Sometimes I should use a "friend" function, sometimes "friend functions are evil". Sometimes multiple inheritance is fine, sometimes it should be avoided like the plague. Sometimes you should "obviously" use operator overloading, sometimes you should avoid it because it's confusing because you don't know which functions are being called.
I'm sure someone here can "educate" me with the best practices for C++, and maybe there will be some reasoning for it, but ultimately I don't really care. I just found the language annoying and I don't enjoy using it. I know that I could "just write it mostly like C and use the C++ features when I need it", but I have just found that I have more fun thinking in pure C, and I've kind of grown to enjoy the lack of features.
Maybe it's just a little bit of masochism on my end, but I like the fact that C gives you so little. You kind of have to think about your problem at a very fundamental and low level; you have to be aware of how memory is allocated and deallocated, you don't get all these sexy helper functional-programming constructs, strings aren't these simple automatic dynamic things that you have in basically every other language. You have a dumb, simple language that will give you exactly what you need to write programs and very little else.
Most stuff I write uses a garbage collector, but the safety and easy of writing stuff with garbage collectors like Java makes it very easy to be lazy. I've grown to appreciate how much C makes you actually think about problems.
That is because you are looking at Design in C++ wrong. Language features and low-level abstractions are just mechanisms. You have to put them into a coherent framework for modeling a problem domain via commonality & variability analysis (aka domain engineering) onto a solution domain consisting of language features, idioms and patterns.
For a very good explanation, see the classic book, Multi-Paradigm Design for C++ by James Coplien.
The above can also be found in his PhD thesis Multi-Paradigm Design available in pdf form here - https://tobeagile.com/wp-content/uploads/2011/12/CoplienThes...
What languages compile fastest?
I can't remember how fast D was but iirc it was fairly fast. Actual fastest is my compiler which I don't work on anymore and isn't ready for production. It's the only compiler I know of that hit millions of lines <1s in a non trivial language https://bolinlang.com/
It does make me wonder why Pascal never became more popular. Fast compiling is a big advantage.
Because they use Typescript.
>The stop-the-world garbage collection is a big pain for games
There is a number of languages that allow manual memory management: Zig, Nim, Rust and few others
Nim not only has support for manual memory management, but there're several gc modes that are not stop-the-world.
Also, since Nim 2, the stdlib now is using ARC by default, which is deterministic and has advantages over conventional garbage collection.
because You know C