Forking is a foolish idea. The core principle of computer-science is that we need to live with legacy, not abandon it.
what a crazy thing to say. The core principle of computer-science is to continue moving forward with tech, and to leave behind the stuff that doesn’t work. You don’t see people still using fortran by choice, you see them living with it because they’re completely unable to move off of it. If you’re able to abandon bad tech then the proper decision is to do so. OP keeps linking Joel, but Joel doesn’t say to not rewrite stuff, he says to not rewrite stuff for large scale commercial applications that currently work. C clearly isn’t working for a lot of memory safe applications. The logic doesn’t apply there. It also clearly doesn’t apply when you can write stuff in a memory safe language alongside existing C code without rewriting any C code at all.
And there’s no need. Modern C compilers already have the ability to be memory-safe, we just need to make minor – and compatible – changes to turn it on. Instead of a hard-fork that abandons legacy system, this would be a soft-fork that enables memory-safety for new systems.
this has nothing to do with the compiler, this has to do with writing ‘better’ code, which has proved impossible over and over again. The problem is the programmers and that’s never going to change. Using a language that doesn’t need this knowledge is the better choice 100% of the time.
C devs have been claiming ‘the language can do this, we just need to implement it’ for decades now. At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
this has to do with writing ‘better’ code, which has proved impossible over and over again
I can’t speak for C, as I don’t follow it that much, but for C++, this is just not fair. It has been proven repeatedly that it can be done better, and much better. Each iteration has made so many things simpler, more productive, and also safer. Now, there are two problems with what I just said:
That it has been done safer, that doesn’t mean that everyone makes good use of it.
That it has been done safer, doesn’t mean that everything is fixable, and that it’s on the same level of other, newer languages.
If that last part is what you mean, fine. But the way that you phrased (and that I quoted) is just not right.
At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
Surely not for everything. Of course I see great value if I can stop depending on OpenSSL, and move to a better library written in a better language. Seriously looking forward for the day when I see dynamic libraries written in Rust in my package manager. But I’d like to see what’s the plan for moving a large stack of C and C++ code, like a Linux distribution, to some “better language”. I work everyday on such a stack (e.g. KDE Neon in my case, but applicable to any other typical distro with KDE or GNOME), and deploy to customers on such a stack (on Linux embedded like Yocto). Will the D-Bus daemon be written in Rust? Perhaps. Systemd? Maybe. NetworkManager, Udisks, etc.? Who knows. All the plethora of C and C++ applications that we use everyday? Doubtful.
The core principle of computer-science is to continue moving forward with tech, and to leave behind the stuff that doesn’t work.
I’m not sure you realize you’re proving OP’s point.
Rewriting projects from scratch by definition represent big step backwards because you’re wasting resources to deliver barely working projects that have a fraction of the features that the legacy production code already delivered and reached a stable state.
And you are yet to present a single upside, if there is even one.
At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
You are just showing the world you failed to read the article.
Also, it’s telling that you opt to frame the problem as "a project is written in C instead of <insert pet language> instead of actually secure and harden existing projects.
And you are yet to present a single upside, if there is even one.
This is a flippant statement, honestly, as it disregards the premise of the discussion. It’s memory safety. That’s the upside. The author even linked to memory safety bugs in OpenSSL. They might still exist elsewhere. (I realize there is a narrow class of memory bugs that C compilers understand, but it’s just that, a narrow class). We have scant way of knowing whether or not they exist without significant testing effort that is not likely to happen. And it would be fighting a losing battle anyway, because someone is writing new C code to maintain these legacy systems.
This is a flippant statement, honestly, as it disregards the premise of the discussion. It’s memory safety.
You’re completely ignoring even the argument you’re supposedly commenting,let alone the point it makes. You’re parroting cliches while purposely turning a blind eye to the point made in the blog that yes C can be memory safe. Likewise, Rust also has CVEs due to memory safety bugs. So, beyond these cliches, what exactly are you trying to argue?
what a crazy thing to say. The core principle of computer-science is to continue moving forward with tech, and to leave behind the stuff that doesn’t work. You don’t see people still using fortran by choice, you see them living with it because they’re completely unable to move off of it. If you’re able to abandon bad tech then the proper decision is to do so. OP keeps linking Joel, but Joel doesn’t say to not rewrite stuff, he says to not rewrite stuff for large scale commercial applications that currently work. C clearly isn’t working for a lot of memory safe applications. The logic doesn’t apply there. It also clearly doesn’t apply when you can write stuff in a memory safe language alongside existing C code without rewriting any C code at all.
this has nothing to do with the compiler, this has to do with writing ‘better’ code, which has proved impossible over and over again. The problem is the programmers and that’s never going to change. Using a language that doesn’t need this knowledge is the better choice 100% of the time.
C devs have been claiming ‘the language can do this, we just need to implement it’ for decades now. At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
I can’t speak for C, as I don’t follow it that much, but for C++, this is just not fair. It has been proven repeatedly that it can be done better, and much better. Each iteration has made so many things simpler, more productive, and also safer. Now, there are two problems with what I just said:
If that last part is what you mean, fine. But the way that you phrased (and that I quoted) is just not right.
Surely not for everything. Of course I see great value if I can stop depending on OpenSSL, and move to a better library written in a better language. Seriously looking forward for the day when I see dynamic libraries written in Rust in my package manager. But I’d like to see what’s the plan for moving a large stack of C and C++ code, like a Linux distribution, to some “better language”. I work everyday on such a stack (e.g. KDE Neon in my case, but applicable to any other typical distro with KDE or GNOME), and deploy to customers on such a stack (on Linux embedded like Yocto). Will the D-Bus daemon be written in Rust? Perhaps. Systemd? Maybe. NetworkManager, Udisks, etc.? Who knows. All the plethora of C and C++ applications that we use everyday? Doubtful.
I’m not sure you realize you’re proving OP’s point.
Rewriting projects from scratch by definition represent big step backwards because you’re wasting resources to deliver barely working projects that have a fraction of the features that the legacy production code already delivered and reached a stable state.
And you are yet to present a single upside, if there is even one.
You are just showing the world you failed to read the article.
Also, it’s telling that you opt to frame the problem as "a project is written in C instead of <insert pet language> instead of actually secure and harden existing projects.
This is a flippant statement, honestly, as it disregards the premise of the discussion. It’s memory safety. That’s the upside. The author even linked to memory safety bugs in OpenSSL. They might still exist elsewhere. (I realize there is a narrow class of memory bugs that C compilers understand, but it’s just that, a narrow class). We have scant way of knowing whether or not they exist without significant testing effort that is not likely to happen. And it would be fighting a losing battle anyway, because someone is writing new C code to maintain these legacy systems.
You’re completely ignoring even the argument you’re supposedly commenting,let alone the point it makes. You’re parroting cliches while purposely turning a blind eye to the point made in the blog that yes C can be memory safe. Likewise, Rust also has CVEs due to memory safety bugs. So, beyond these cliches, what exactly are you trying to argue?