5 ms·

I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes: We should not be developing new projects in C, an

by xena 2y ago

I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes: We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for unsupervised use. I wish that we didn't have to make such hard-line stances about this, but people have continuously proven that this tool is unsuitable for modern development and it's only going to get worse as time goes on.

WesolyKubeczek 2y ago
[flagged]
- pjc50 2y ago
  Fine, but there's no reason you should be allowed to ship C in devices which have safety critical consequences to the public, including unnecessary risk of data security breaches through allowing buffer overruns. You can write in a nice safe sandbox over there. (maybe this will eventually be part of the UL/CE requirements, "contains no C code")
  - WesolyKubeczek 2y ago
    C and C++ have another brand of safety "safe" languages du jour don't have: it's an ISO standard. Granted, it's not a very good standard, but the upside is that everyone and their dog has a C compiler for every new architecture, and I bet C++ too. You are not, strictly speaking, beholden to any single compiler implementation out there, they all have their idiosyncrasies, but C won't disappear overnight. It's more even than having a single foundation oversee it. C and C++ are largely immune to, say, a foundation dissolving because one day it turns out its members cannot comport themselves as responsible adults and a big enough drama ensues. The fact that C and C++ have no singular "community" to speak of is a very strong side. So when there are at least two (or better three) fully independent implementations of your C alternative, we'll talk about gatekeeping C. Now, if you are a vendor and capital owner, nothing forbids you from forbidding C within your company and devices you produce. That has been your prerogative since forever, predicated on your ability to afford it. I'm more wound up about activists and evangelists trying to impose their hobby horse upon others. You do you. Show, don't tell.
- xena 2y ago
  Thank you for demonstrating why I haven't written that longer post yet. I'd just be torn apart and berated for bothering to express nuance.
- Xeamek 2y ago
  That's not how society progress. At some point you just disallow horses to go onto the high-speed road, and aren't waiting for literally every last farmer to sell their horse over a car.
  - WesolyKubeczek 2y ago
    High-speed roads are a low percentage of all roads.
maeln 2y ago
> We should not be developing new projects in C I would give at least embedded development a pass, since you rarely do have a choice there
- p_l 2y ago
  Mostly because you often get shipped half-broken pile of C-based SDK as your blessed environment. Not because there's no other options (and long before Rust had its name coined)
- pjc50 2y ago
  It's difficult, because "embedded not networked" is an environment where security risks are low, but "embedded networked" is a really nasty environment of haunted routers and abandoned IoT devices. Is it acceptable to risk buffer overruns on the HTTP server running on an insulin pump?
- selfmodruntime 2y ago
  I agree. I regularly use Rust on embedded devices and what many advocates like to leave out is that you're just using regular old C under the hood anyway. It's bindings all the way down.
- xena 2y ago
  Well, yes. I'm more focusing on user space applications here. This is why that nuance post would have to be so long. People here would probably misconstrue it to be that I want to "kill C" though. That's part of the reason why I haven't written it yet lol
immibis 2y ago
If your distribution refuses to package useful free software, I'll use another distribution. I think this is true for most people.

by xena 2y ago

WesolyKubeczek 2y ago

[flagged]

pjc50 2y ago
Fine, but there's no reason you should be allowed to ship C in devices which have safety critical consequences to the public, including unnecessary risk of data security breaches through allowing buffer overruns. You can write in a nice safe sandbox over there. (maybe this will eventually be part of the UL/CE requirements, "contains no C code")
- WesolyKubeczek 2y ago
  C and C++ have another brand of safety "safe" languages du jour don't have: it's an ISO standard. Granted, it's not a very good standard, but the upside is that everyone and their dog has a C compiler for every new architecture, and I bet C++ too. You are not, strictly speaking, beholden to any single compiler implementation out there, they all have their idiosyncrasies, but C won't disappear overnight. It's more even than having a single foundation oversee it. C and C++ are largely immune to, say, a foundation dissolving because one day it turns out its members cannot comport themselves as responsible adults and a big enough drama ensues. The fact that C and C++ have no singular "community" to speak of is a very strong side. So when there are at least two (or better three) fully independent implementations of your C alternative, we'll talk about gatekeeping C. Now, if you are a vendor and capital owner, nothing forbids you from forbidding C within your company and devices you produce. That has been your prerogative since forever, predicated on your ability to afford it. I'm more wound up about activists and evangelists trying to impose their hobby horse upon others. You do you. Show, don't tell.
xena 2y ago
Thank you for demonstrating why I haven't written that longer post yet. I'd just be torn apart and berated for bothering to express nuance.
Xeamek 2y ago
That's not how society progress. At some point you just disallow horses to go onto the high-speed road, and aren't waiting for literally every last farmer to sell their horse over a car.
- WesolyKubeczek 2y ago
  High-speed roads are a low percentage of all roads.

maeln 2y ago

> We should not be developing new projects in C I would give at least embedded development a pass, since you rarely do have a choice there

p_l 2y ago
Mostly because you often get shipped half-broken pile of C-based SDK as your blessed environment. Not because there's no other options (and long before Rust had its name coined)
pjc50 2y ago
It's difficult, because "embedded not networked" is an environment where security risks are low, but "embedded networked" is a really nasty environment of haunted routers and abandoned IoT devices. Is it acceptable to risk buffer overruns on the HTTP server running on an insulin pump?
selfmodruntime 2y ago
I agree. I regularly use Rust on embedded devices and what many advocates like to leave out is that you're just using regular old C under the hood anyway. It's bindings all the way down.
xena 2y ago
Well, yes. I'm more focusing on user space applications here. This is why that nuance post would have to be so long. People here would probably misconstrue it to be that I want to "kill C" though. That's part of the reason why I haven't written it yet lol

immibis 2y ago

If your distribution refuses to package useful free software, I'll use another distribution. I think this is true for most people.