C programmers need to effing stop writing C, but they also DOUBLY need to stop writing ridiculous, "I DON'T CARE ABOUT YOUR SECURITY ALSO SCREW RUST ❤️ GOLANG" screeds.

This is like, the pinnacle of being an unprofessional actor in a professional field:

@endomain Also, folks need to stop hating on C because a bunch of folks wrote shitty C. Particularly when most of the "better" languages are written in C.


I'm not sure I agree. Lots of languages are only written in C for a minimal bootstrap. Most languages self-host now.

@endomain Let's see. Python, Perl, Ruby are written in C. Go wasn't for a long time and a whole mess of its libraries need cgo to work. OpenJDK has a bunch of C. Rust bootstraps with Python which is written in C. Haskell has a ton of C. GNU Common Lisp even has C in it. Most build processes rely on having a sensible shell, which are often written in C.


Python, Perl and Ruby aren't really in scope here are they? We're talking about systems programming languages.

As for the others, other than GCL, they're mostly self-hosted and only keep the minimum required C for bootstrapping and OS compatibility.

Even if that's the case, the audit surface of an interpreter is smaller and tends to be fixed, and communities can focus carefully on them. Even then, it's a risk.

I'm not sure it's a refutation of the "C is unsafe" argument to say, "Well some languages are written in C."

@endomain My original statement was 'folks need to stop hating on C because a bunch of folks wrote shitty C. Particularly when most of the "better" languages are written in C'.

I did not narrow the scope to "systems programming languages", whatever that means for you.

I also did not attempt to refute that C is unsafe by default.

This has moved into "trying to argue about things I didn't say so I'm stepping away from the conversation.


The context was the article in question. I'm sorry, but when you replied to that I assumed the context of the document I was talking about.

That said, Python Perl and Ruby are all various flavors of terrible to me so, maybe that is indeed because of contagion.

Before the author of the post responds to you, I ought to say that tbh everything but the last 2 points seem pretty reasonable. I disagree with Drew on many things (and I think he might have me blocked even) but he's well above industry average in terms of professionalism.


Not if "I don't care about the segfaults and security issues I'd prefer them to learning some alternative" is his primary motive.

That's malpractice.

Also even he admitted the "cargo is required" and "they won't integrate with other build systems" points are made up.

Also why recommend Go if you think implemention concentration is bad, or concurrency is bad, or a mandatory GC is bad? 🤔

The whole thing strikes of someone being huffy about Rust and basically scratching around for anything they can to tie a defense of C to a refutation of Rust. But that's not actually the issue; there are lots of alternatives to C. Zim, Nim, C++, etc come to mind off the top of my head, I'm sure we can find more quickly.

I don't think the essay was a defense of C. It seemed to be a complaint that Rust doesn't optimize for what C programmers expect. His primary criticism is absence of a spec.

@enkiv2 @endomain That article is such an unbelievable pile of bullshit. It's not even worth addressing any of the incorrect points it fails to make.

@enkiv2 @endomain I like Rust and didn't think much of the article, but absence of a spec *is* an issue.

@neilgall @endomain @enkiv2 The language is evolving, as he points out. It's not uncommon to write the spec after the language has settled down a bit more than this.


@enkiv2 @neilgall

The argument is sorta weird because there is so much unspecified behavior in C, where "this is what GCC does" is the defacto expected answer. To the point where other toolchains try and preserve gcc-like behavior as they perceive it.

@endomain @freakazoid @enkiv2 @neilgall I don't think this is true. Neither gcc nor clang have monopoly on C wisdom. Sure, there are gnu extensions or folk try to maintain compatibility with gcc command line, but that's not the language itself.

@endomain @neilgall @enkiv2 @saper I think it makes more sense to say that the fact that certain behavior is undefined is part of the language spec. A language can't just abdicate responsibility for what happens when people use things in a way that aren't part of the specification. And leaving some behaviors undefined causes real problems, because programmers inadvertently end up relying on undefined behavior, which leads to bugs, vulnerabilities, and non-portability.

@endomain @freakazoid @uranther @neilgall @enkiv2 @saper
It's nice to have which behaviors are undefined be defined though. Like, it's difficult to write a C program that doesn't rely on undefined behavior, but strictly speaking it's not impossible (and when you can identify the implementation or platform you can clarify a lot of it). If you don't have a spec you can't avoid nasal demons.


@freakazoid @uranther @neilgall @saper

It's very difficult to write a C program that avoids undefined behavior. You can't call functions or do arithmetic on user input.

@endomain @enkiv2 @freakazoid @uranther @neilgall but it is possible to write a C program that does not depend on an undefined behavior

@saper @neilgall @uranther @enkiv2 @endomain Yup, and everyone assumes they're one of the few who can easily write programs without ever depending on undefined behavior. And they're always wrong.


@enkiv2 @freakazoid @uranther @neilgall

Yes, if you write something that never touches user input and only calls single or no argument functions and never casts values or pointers and never allocates memory and statically checks it's arithmetic for overflow... Then you've avoided most of the *common* UB in C.

Sign in to participate in the conversation

A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.