3 ms·

It's not fair to pin this on the ambiguous collective "developers." The real issue is likely that there is simply too much inertia behind C and C++ for systems

It's not fair to pin this on the ambiguous collective "developers." The real issue is likely that there is simply too much inertia behind C and C++ for systems and performance-critical programming. There are other languages like Rust that provide a technical alternative but not necessarily a cultural one. Obviously, the pain of severe software defects is not yet high enough to warrant switching to memory-safe systems programming languages.

dvfjsdhgfv 8y ago
This is probably the problem of the title, he obviously doesn't mean all developers. In any case, I hope articles like these help us to overcome the inertia you mention, although, realistically, I don't think a project like the Linux (or BSD) kernel will ever be rewritten in a language different than C and* be complete enough to gain widespread use.
- delinka 8y ago
  put space around the * characters to prevent them being interpreted as formatting
- dpg23 8y ago
  Redox has made way more progress than I ever thought it would, so who knows?
mamcx 8y ago
> It's not fair to pin this on the ambiguous collective "developers." Why not? Is not as if the majority of us are much into fix things, instead of continue along. Developers are very much the main problem here. Neither is a problem of resources, suposely developers earn well and some of the biggest corporations of the world work on software. But each time is even hinted "why not ACTUALLY fix things?" the answers is "nope, too much work", but for create chat apps and more tools for surveilance and privacy invasion the money pit is bottomless.
- detaro 8y ago
  I can name quite a few people who'd love to work on this stuff, but the companies that pay them rather would they make yet another chat app or move buttons on a shopping site around. Large movements like this are hard to do on the side, especially since replacing existing software piece-by-piece is often a harder proposition than doing a full replace.
  - mamcx 8y ago
    Is interesting, because maybe budget a 10% of time doing this will yield a lot of progress. Also, taking in consideration than certains tools (programming languages, OS APIs, shells, etc) have a large surface area of impact and many developers actually not care if the tools is made on C/C++, care that solve a certain problem. (Of course, this demand that the c-call conventions stay because that wire A LOT, but that is small and contained).
- weberc2 8y ago
  > Developers are very much the main problem here. > But each time is even hinted "why not ACTUALLY fix things?" the answers is "nope, too much work", but for create chat apps and more tools for surveilance and privacy invasion the money pit is bottomless. You're blaming developers but citing product/economic/business decisions. In all likelihood, the problem is as much organizational/economic as it is technical. For example, consider the manager who was warned about the security risks by the engineering team, but decides to ship the product on schedule and get promoted long before any serious vulns are discovered. Or the case where engineering raises the issue, but fails to effectively communicate the severity of the concern. Or the case where engineering _assumes_ management understands the risks. I'm sure there are lots of developers who do think they should just use C because it's what they've used forever and _lesser developers_ might make mistakes but _they_ don't, but I'd be surprised if these folks are the primary driver of the situation.
  - mamcx 8y ago
    > You're blaming developers but citing product/economic/business decisions This is a big part of it. But here, the kind of "developers" that could cause the big impact come from MS, Google, Apple and a few others. That certainly how normal people will look at this, IMHO. But also, open source developers. Here is where is weird... what could be the reason to not build better tools?
kpcyrd 8y ago
> Obviously, the pain of severe software defects is not yet high enough to warrant switching to memory-safe systems programming languages. The decision to rewrite in a memory-safe language would create a lot of work for the developers, the decision to stick to unsafe languages creates a lot of work for the people handling security incidents. These aren't necessarily the same people, in the open source world you usually have dedicated teams that are having trouble keeping up with the number of severe software defects discovered every other day.

dvfjsdhgfv 8y ago

This is probably the problem of the title, he obviously doesn't mean all developers. In any case, I hope articles like these help us to overcome the inertia you mention, although, realistically, I don't think a project like the Linux (or BSD) kernel will ever be rewritten in a language different than C and* be complete enough to gain widespread use.

delinka 8y ago
put space around the * characters to prevent them being interpreted as formatting
dpg23 8y ago
Redox has made way more progress than I ever thought it would, so who knows?

mamcx 8y ago

> It's not fair to pin this on the ambiguous collective "developers." Why not? Is not as if the majority of us are much into fix things, instead of continue along. Developers are very much the main problem here. Neither is a problem of resources, suposely developers earn well and some of the biggest corporations of the world work on software. But each time is even hinted "why not ACTUALLY fix things?" the answers is "nope, too much work", but for create chat apps and more tools for surveilance and privacy invasion the money pit is bottomless.

detaro 8y ago
I can name quite a few people who'd love to work on this stuff, but the companies that pay them rather would they make yet another chat app or move buttons on a shopping site around. Large movements like this are hard to do on the side, especially since replacing existing software piece-by-piece is often a harder proposition than doing a full replace.
- mamcx 8y ago
  Is interesting, because maybe budget a 10% of time doing this will yield a lot of progress. Also, taking in consideration than certains tools (programming languages, OS APIs, shells, etc) have a large surface area of impact and many developers actually not care if the tools is made on C/C++, care that solve a certain problem. (Of course, this demand that the c-call conventions stay because that wire A LOT, but that is small and contained).
weberc2 8y ago
> Developers are very much the main problem here. > But each time is even hinted "why not ACTUALLY fix things?" the answers is "nope, too much work", but for create chat apps and more tools for surveilance and privacy invasion the money pit is bottomless. You're blaming developers but citing product/economic/business decisions. In all likelihood, the problem is as much organizational/economic as it is technical. For example, consider the manager who was warned about the security risks by the engineering team, but decides to ship the product on schedule and get promoted long before any serious vulns are discovered. Or the case where engineering raises the issue, but fails to effectively communicate the severity of the concern. Or the case where engineering _assumes_ management understands the risks. I'm sure there are lots of developers who do think they should just use C because it's what they've used forever and _lesser developers_ might make mistakes but _they_ don't, but I'd be surprised if these folks are the primary driver of the situation.
- mamcx 8y ago
  > You're blaming developers but citing product/economic/business decisions This is a big part of it. But here, the kind of "developers" that could cause the big impact come from MS, Google, Apple and a few others. That certainly how normal people will look at this, IMHO. But also, open source developers. Here is where is weird... what could be the reason to not build better tools?

kpcyrd 8y ago

> Obviously, the pain of severe software defects is not yet high enough to warrant switching to memory-safe systems programming languages. The decision to rewrite in a memory-safe language would create a lot of work for the developers, the decision to stick to unsafe languages creates a lot of work for the people handling security incidents. These aren't necessarily the same people, in the open source world you usually have dedicated teams that are having trouble keeping up with the number of severe software defects discovered every other day.