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: https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
@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.
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.
@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.
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.
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.