Tek resources? Yipe!
I’m convinced no one on Earth is smart enough to write C.
“All you’ve got to do is…”
“As long as you remember to…”
“Just be sure to always…”
“Make sure you never…”
And yet, stuff like PwnKit is still the rule, not the exception.
While I like Rust, I don’t think it’s going to be the final language humanity develops. That’s the direction of programming, though. C should be dead. There’s zero chance I’d start a new project in C today.
Tek resources? Yipe!
@docskrzyk For the tiny embedded stuff, C actually is probably the right answer. I dunno, maybe something like D would fit there, too. I think tiny systems where the code *can’t* grow large enough that a single “normal” person can’t hold the whole source in their brain at once are reasonable uses for it.
Nothing bigger, though. I’ve seen no evidence that large, correct systems can be written in C, even though brilliant people try.
________
@tek So for lower level stuff (thinking embedded projects that need something higher level than pure assembly) is there anything good as an alt?
But yeah, we seem to have gotten so handwavy about C that we're using AI to point out busted code rather than actually porting stuff.
feld
Tek resources? Yipe!
@feld I hope that’s what the future looks like.
feld
feld
Tek resources? Yipe!
@feld Yeah, it’s large C-the-ecosystem that makes it impossible. A tightened up C with far less UB, and maybe a libc built on modern programming principles, would be a different animal. But if you’re doing *that* much rebuilding, then there’s Rust/Zig/D/whatever which are starting over from lessons learned over the last 50 years.
Vertigo #$FF
@tek To be fair to C, a lot of the reason why PwnKit still the rule is because programmers, when told "all you got to do is..", reacts almost violently to the advice, and promptly ignores it with the usual tech-bro bravado that comes with them thinking they're perfect and can do no wrong.
That said, compilers exist to automate away human monotony, so I'm all for their use. The more a compiler can help me write clean code, the better for me and everyone else.
Tek resources? Yipe!
@vertigo Oh, that never happens! "I'll code around the problem by developing a memory safe system implemented in C macros!" is something no one would ever do. /s
f.rift :fire_blue:
@tek
There is a huge amount of energy I'm not spending on a checklist of cliffs I could be falling off of when I'm not writing in C.
Santa Claes 🇸🇪🇭🇰🎅
Vertigo #$FF
@tek @docskrzyk I would argue that Pascal/Modula-2/Oberon are excellent choices here, since they are designed to be safe languages by default. Unsafe operations are made explicit via performance optimization pragmas or via special syntax constructs like "IMPORT SYSTEM". The only disadvantage to using these languages versus Rust is that they aren't always zero-cost (e.g., if a compiler cannot prove it can elide bounds checking, then it will include bounds checking on every array access, which obviously imposes a small runtime hit).
Tek resources? Yipe!
@lmemsm I’m not saying it’s a moral failure to write C code or anything, just that it’s impossibly hard to get right. Many more experienced devs than you and me have tried and failed.
And honestly, C requires so much mental bookkeeping to use correctly that it slows development down. Think about something like Rust which makes use-after-free almost impossible, and how the compiler will stop you from doing it. You can spend more time thinking about logic than bean counting.
LM
@tek I start most of my new projects in #C. Unless there's a logistical reason (like when a company has a group project in a chosen language), developers should be allowed to program in whatever languages they feel most comfortable with and/or most prolific with. I feel that's especially true if it's a personal FLOSS project. Just because one developer may not like or may not be efficient with a language, does not mean all developers will have those same issues.
Tek resources? Yipe!
@lmemsm Re-read what I wrote. There wasn’t an insult in there.
I like C. My Coverity stock made a nice profit because people paid us a lot of money to analyze their professionally-written code. I think the OpenBSD team are some of the best software engineers on the planet, and they still use static analyzers and their own secured libc functions to try to catch and prevent errors that newer languages would help avoid in the first place.
LM
@tek You don't know my experience level. I find developing in C faster than the other languages I've worked with (and there have been many). If I thought another language was a better fit to develop with, I'd be using it. I happen to know and correspond with other developers who also prefer C. It's a matter of opinion and not everyone feels the way you do about working with the language. Please try to keep an open mind and not insult people who do not agree with your language preferences.
c a i s a
@tek (;
William D. Jones
@tek Not to get on my bootstrapping rant again, but I haven't seen any indication that a Rust compiler as exists today is actually implementable in a language less powerful/complicated than Rust.
I.e. there's just too much code to write that only a language with lots of features- with a compiler that would take a lot of time to write- can offset the cognitive bandwidth required to impl a Rust compiler. Also applies to C++. Even mrustc is written in C++.
And that scares me.
William D. Jones
@tek Rust isn't portable enough for me to completely abandon C (add backends besides LLVM and GCC- maybe something targeting SDCC, for instance- and then we'll talk). But sadly, to most ppl, the only two archs that exist are x86 and ARM :/.
But if my Rust portability gripes were fixed, I still think Rust is too complex a language to be the "minimal viable no-GC programming language".
You can't write safe C, but C is still simple enough that a single person can write a crappy compiler.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.