Holy Language Wars, Batman!

Published 2020-04-13 on A Heroic Pixel

I mentioned in my post about Zig (which was titled “Programming Languages” because I wrote that post at around 3 in the morning and 3 AM me is about as creative as your typical… thing that isn’t creative) that I prefer C to C++, especially for systems work. That apparently bothered some people who are under the impression that C++ is vastly better in every area than C, so I decided to publish a rebuttal.

I’m currently on a mini-vacation from my SourceHut internship for Passover, so I decided I’d finally take the time to write this article that’s been half-finished in my drafts folder for at least four months.

I’m going to start by reiterating what I mentioned in my last post: language wars are dumb. I’m not ever going to try to convince you that one language is better than another, and I’ll never put up with such broad claims (I’m likely to just ignore you). I won’t be bothered if you disagree with me on which languages are good and which are not; I realized early on that what programming language you use is almost entirely arbitrary (and yes I know I’m inviting a lot of flames with this). A skilled engineer can legitimately write a fully-fledged operating system in JavaScript (though they would also be aware why they shouldn’t). Part of being an engineer is being able to work with your tools, even when those tools aren’t really up to the job; there’s a reason Duct Tape is the solution to all of life’s problems.

In that vein, I firmly believe that there is no such thing as a perfect language - or, I would even argue, a great language. I do not think C is some sacred language free of flaws. I do not think C++ is an evil pile of cow dung placed here by Zanthil, Lord of Elsewhen, to test my faith in the Great Cee. C has plenty of problems, and there are a number of things Rust/C++/Go/Zig/Nim/etc. do better.

Just a quick note before I get into the meat of this article: there were a couple of mistakes I made in the previous article, but I don’t like the idea of editing what I originally published (just a personal thing, the idea of “fixing” my mistakes and putting on a facade of perfection bothers me; I’m not perfect and I refuse to pretend to be), and while they’ve been left as is, I have noted them down at the bottom of the article. Literally just now. Feel free to inform me if you find mistakes in this post, I’ll try to point them out in a more timely fashion.

Okay, now that that’s over with: here’s why C++ sucks and C rules languages aren’t perfect and to assert that one language is better than another is a form of public indecency (so, crustaceans, if you attempt to tell me to “rewrite it in rust!!!” I’m going to press charges. Just sayin’. To the non-extremist Rust users: I’m sorry about the bad reputation you get from a minority of your community, and I’m not targeting you). This post will remain mostly generalized (though it uses a few practical examples), I’ll do a follow-up on why I prefer C and Zig to C++.

First, some definitions:

  • Better: the comparative form of “good”.
  • Axiom: a general truth, fundamental principle, or rule of conduct widely accepted on its intrinsic merit
  • Objective: expressing or dealing with facts or conditions as perceived without distortion by personal feelings, prejudices, or interpretations

When people say that one language is better than others (LOJBAN forever!), they almost always mean that it is objectively better. That is, it is a fact of reality (and not an opinion or preference) that a language is more good than another. If I say that “C++ is better than C”, I’m saying that C is factually more good than C++ - which seems obvious, but is important for this next point.

Who defines good? Well, the dictionary would say “of a favorable character or tendency,” which is helpful - but also, not really. A concrete example is Rust. Fair warning: going to be shitting on Rust a bit here. It’s not personal. Rust is mainly celebrated because it’s a relatively practical (and honestly the work they’ve done on compile times is fascinating) language that is safe.

Therefore, when people say that “Rust is better than C because Rust is safer,” they are saying “Rust has more good than C because Rust has more safety,” and furthermore, no other factors matter. Safety is the only ideal that matters. Safety = good, everything else is irrelevant. Obviously, there are people who make more nuanced claims; I’m talking specifically about this sort of broad overgeneralization.

The claim that they are making is that Rust is better than C, because safety is axiomatically the most important factor, and Rust is safer than C.

The problem with this sort of claim is exactly the lack of nuance I mentioned earlier: safety isn’t the only difference between Rust and C. Rust isn’t just “C + safety.” You don’t write down some sigil in goat chalk or something and suddenly have your C become safer. There’s plenty of other differences as well. Here are a few:

  • Rust is newer
  • Rust is less stable
  • C supports many many more platforms than Rust ever will
    • There’s plenty of small C compilers (such as SDCC) that can target systems that Rust does not and likely never will support, such as the z80. SDCC alone can target at least half a dozen targets that Rust can’t (probably more).
    • C supports more esoteric platforms (platforms which will only ever support C because the e.g. manufacturers are out of business, source is destroyed)
  • Rust has longer compile times by a significant margin
  • C has multiple compilers (GCC and Clang, for the most common platforms)
  • It’s easier to formally prove that Rust code is correct
  • The syntax is different
  • Rust has a package manager (crates)

There’s plenty more, those are just a few offhand.

Now, you might not think these differences matter, but to many people they do. People disagree on these sorts of axioms. Not everyone thinks that safety is more important than:

  • Stability
  • Age
  • Platform support
  • Compatibility
  • Compiler competition
  • Compile times
  • Syntax
  • Distribution method
  • Project authority
  • Simplicity

The problem that many people have with such extreme axioms is that they prioritize a single factor (in this case, safety, but many other claims exist that are equally bad: simplicity, platform support, etc; different languages / communities tend to make the same claim about different characteristics) over any of the others. Well, that’s not entirely fair: it prioritizes a single characteristic over all of the others put together. You’re saying that safety, or simplicity, or compatibility are not just means to an end, they are an end in and of themselves.

Now, you might believe that; you’re more than welcome to whatever beliefs you want. However, these axioms aren’t universally agreed upon. I’d contend that compile time is more important than safety (as long as you have e.g. GDB/valgrind; I’m not saying safety isn’t important at all), as studies have found that even millisecond delays can add up and cause us to lose our trains of thought. I’d insist that it’s more important for the programmer to be able to keep working, as I’d rather have a mostly safe program with a vastly shorter iteration span than a completely safe program with a longer one (as that means more programmer time to spend on for new features, bug fixes, and so on).

So, who’s right?

Well, the answer is quite simple: yes. You’re correct in the sense that if you hold the axiom “nothing is more than safety” to be true, Rust is better. Someone who says “the only important factor is simplicity” can reasonably argue that JavaScript is a better language, because it’s simpler. The problem is with objectivity: there’s a human element involved!

What people always always miss in these discussions (JS vs Lua; Zig vs C; C++ vs Rust; Go vs Forth; whatever else you can imagine) is that the real discussion they’re having isn’t about the language at all, it’s about their axioms.

Now, these axioms aren’t like mathematical ones; it’s literally impossible to prove one is more correct than another, because axioms are, well, axiomatic. They aren’t true or false; they’re personal. There is nothing truly objective about them. I believe that compile times matter because I spent a lot of my formative years (programming wise; from the seventh grade I believe until the middle of ninth) on a 2003 Pentium, and in ninth grade I upgraded to a $150 laptop with an Intel Celeron (if you’re unfamiliar with Celerons, they’re sorta like demonic rituals, except that the demon would probably take less time to answer your summons and help you with your problems) and so I’m intimately acquainted with how long compile times harm the programming experience mentally.

However, I also did this on Linux, so I never had to deal with BSoDs (I’ve never experienced a kernel panic outside of one incident where I accidentally distributed a -march=native busybox to laptops that didn’t support the extensions used when I was using an automated SSH script to speed up setup of a bunch of laptops in my school’s lab). Someone who’s spent more time dealing with issues caused by safety issues in code might reasonably think safety is a bigger issue.

I’ve said a number of times that what language to use is personal. Now, I can explain why I think that: what language you should use is pretty simple contextually. Obviously, it’s Zig. Jeez, I explained that in my last post! Switch now before the end comes!

Jokes aside, there’s a pretty simple formula, which I’ll write in pseudo-code so that everyone is equally annoyed at the syntax.

IF PROJECT OWNER IS NOT SELF THEN USE PROJECT LANGUAGE END IF PROJECT OWNER IS SELF THEN USE PREFERRED LANGUAGE END

There. It’s that simple.

If I’m contributing to a project in C++, I follow the project’s style and I use C++. I also try to make sure that other contributors / reviewers are aware that C++ isn’t my forte so that they know to pay more attention to what I wrote. If I’m contributing to a project in Python and I don’t know Python, I don’t ask the dev to port it to a language I know, I don’t offer to do that myself, I learn Python and contribute in the native language. When I made that patch, I had never before looked at Python. Fortunately, general programming proficiency carries across regardless of the specific language, so I was able to quickly learn it (I spent maybe an hour browsing the docs?) and get to work.

That’s just common courtesy. Don’t enforce your axioms on others. This is true in computing, in which specific Outsider you worship, your preference for pizza toppings, how you flourish your Sindarin, and any other aspect of normal life. If you are asking to work on a slice of pizza with me, you have no right to demand that I put pineapple on it. It’s really not that complicated. As I said earlier, exposing your axioms is a form of public indecency.

If you’re working on a project of your own, then go wild! Like Smalltalk? Use it! Always thought writing in assembly would be a fun retro thing to do? There’s modern tools that make it easy and fun! Your project, your rules! Want to integrate XML, LuaJIT, C++, and an ugly glue layer to make a shitty game engine that uses XML files to portray scene info and embed scripts for the JIT engine resulting in self-modifying XML files? Well, I’ve done that hyper-specific thing, so I definitely can’t tell you that you shouldn’t (I had good reasons)!

It’s entirely possible to have reasonable discussions on the merits of various languages. I can concede that there are advantages to be had in nearly every language. However, don’t try to tell me that any language is better in every way than what I’m using; it’s always wrong, and just makes you sound like an asshole. You can say, for instance, “C++ makes it easier to write high-level abstractions than C does!” I wouldn’t disagree with that. What I want anyone I’m engaging in a debate on languages to understand is that what you consider a huge deal and grounds to switch languages just doesn’t matter to me, and vice versa. I don’t think safety is a reason to switch to Rust. I don’t think Objects of Power Object-oriented programming is worth switching to C++. You might think lower compile times are worth switching to C. It doesn’t matter. The fact that we have a philosophical difference isn’t an excuse to make a big stink out of what language is used. The very idea is, frankly, absurd. You probably have more important things to worry about than what programming language someone you’ve never met is using, and vice versa.

When I wrote my post on Zig, I wasn’t trying to convince everyone to switch. That’s not something I would want, honestly, and that would be a waste of my time. I was trying to showcase it’s advantages and it’s downsides so that people who like what it has to offer are aware of it, and can make informed choices.

I’ve been shitting on Rust this whole post, I know. I apologize; it’s the easiest example simply because its proselytization is so prevalent. If you want to talk to me about what advantages Rust has to offer, and are clear on the downsides, I would honestly love to discuss it; Rust looks quite interesting to me, and I might play with it for some projects.

That said, I could honestly have used any language as the victim here: every language has some form of glaring flaws. No exceptions. If you come away from this post with the takeaway that I hate Rust, then you missed the entire point.

Thanks to Drew DeVault for helping me revise this!

Correction: I wrote that “If I say that “C++ is better than C”, I’m saying that C is factually more good than C++.” Is this indication that I shouldn’t be writing at 3 AM? Yes. Am I going to do it again anyways? Probably.


Articles from blogs I follow around the net

Fix tests with block sizes [2..5]

Ensures that the JIT and interpreter correctly run in tandem. Block sizes 2 through 5 now work correctly for the first test without any issues.

via ~pixelherodev/spu-ii log July 27, 2020

The falsehoods of anti-AGPL propaganda

Google is well-known for forbidding the use of software using the GNU Affero General Public License, commonly known as “AGPL”. Google is also well-known for being the subject of cargo-culting by fad startups. Unfortunately, this means that they are susceptib…

via Drew DeVault's Blog July 27, 2020

Status update, July 2020

Hi all! It’s time for another monthly status update. Yesterday I’ve released wlroots 0.11.0 and Sway 1.5! This is a pretty big release, with lots of new features and bug fixes. New features include headless outputs that can be created on-the-fly (one use-cas…

via emersion July 21, 2020

Generated by openring