Linus Torvalds to Hector Martin: 'Maybe the problem is you'
Linus Torvalds to Hector Martin: 'Maybe the problem is you'
48 comments
-
No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.
Jesus fucking insufferable Christ... Saying shit like this, given C has been in use for 50 years and is still in very wide use today, and given the vast number of languages that have come and gone over this period, it's just incredible.
-
I do not agree with the Dev who stepped down.
But on the topic of C, I wouldn't measure the quality of a language based on its adoption. C is a relatively old language and therefore benefits from getting wide-use before other languages were born. It will never die because who would ever want to rewrite every project in existence in another language.
Memory safety is very important since it has consistently been one of the largest sources of vulnerabilities throughout software history.
C is not a bad language, but it has flaws. Performance at the cost of safety is not a good trade-off in most scenarios. There is no such thing as a "perfect programmer" who won't make mistakes.
-
I don't disagree with these points in general. However this isn't simply about the tools. Tools go along with people and their skill and experience. There are developers and developers. There are people with lots of experience who create much higher quality C code than others. Personally I'd never touch C if I can avoid it as I don't trust myself as much. I'd always go for C++ instead. Modern C++ with RAII is great. It's what most of the software at our corpo is written in. Maybe Rust would end up becoming the default standard at some point. Maybe something else would. I would never go shit on a coworker who has produced tons of well functioning code that they better reskill in something that may or may not stick around, or that they may not become as productive with for a long time. A team skilled in C or C++ may be able to produce higher quality software, quicker than a less skilled team Rust. Rust might be better for teams that just start in native programming. I don't know. If it grows enough in use, reskilling people and reworking software to cooperate with it might become an obvious choice. For now, as I see it, it depends on the team.
-
And I dont deny that. There are a lot of programmers, and not all had eduction on designing secure software. Even with the knowledge and experience, what if the programmer is tired or makes a similar mistake. Only one mess-up away from a potential vulnerability or instability of the app and system as a whole. I need more experience with C to form a better opinion.
-
This is why security is usually multi-layered - decrease the chances of a single fuckup compromising everything. And yes using a safer language adds a layer. But typically it won't be the only layer.
-
-
-
Memory safety at the expense of complicated interfaces is also not a good trade-off, even in terms of security.
-
-
Probably what all the horse people said when cars were invented.
-
I would't trade a good horse for an early car. Maybe a model T.
-
The horse-car analogies rarely achieve what you want them to, especially in situations where we don't have the benefit of hindsight.
-
More akin to Elon insisting the cybertruck is the way of the future, and people just keep buying Rivians and internal combustion vehicles.
-
Especially as there's D, a language that when used in betterC mode, is on-par with C, minus the archaic precompiler, which is replaced with very powerful metaprogramming capabilities.
-
D didn't catch on for many good reasons... And it never will. Zig has way more momentum (and it better!) as a "better C", and obviously the main draw of Rust is memory safety without GC which D doesn't have.
-
D has a way for GC free operation, the easiest way is by using it in BetterC mode. The harder way is writing your own runtime without a GC.
-
Yes but that isn't memory safe.
-
-
-
-
-
-
48 comments