8 ms·
The headline is misleadingly focusing on a soundbite out of the full quote. "It's a shame, but what can we do? There really isn't anything we can do to prevent
by mjevans 2y ago
The headline is misleadingly focusing on a soundbite out of the full quote.
"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner." -- Some (uncredited?) C programmer.
Does C have more footguns as a low level language? Of course. That's part of the freedom of bringing only the baggage a project needs. Sadly, like many dangerous or sharp tools, incorrect use will lead to harms.
If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
- ChrisMarshallNY 2y ago> a safer more modern language can accommodate less skilled practitioners. That’s really what it’s all about. SV is absolutely obsessed with hiring bad programmers, treating them like crap, so they don’t stick around, and somehow, magically, forcing them to write good code. We have this belief that if we just use the “right” tool (in this case, a particular programming language), all of our products will be good. Couple that, with the belief that we should be able to build our stuff on someone else’s code, for free, and you have a recipe for disaster. People like Linus Torvalds are living proof that it is quite possible to write amazing stuff, in old languages (he is a C guy), but people like that, are rare as hen’s teeth, and may be difficult for today’s tech managers to handle. There really is no substitute for running a good shop, hiring good people, training them well, treating them well, paying them well, and keeping them around for significant lengths of time. Also, we need to be able to hold ourselves accountable for the Quality of our own work -regardless of the tools we use. Torvalds is notorious for being a tough taskmaster, because he’s serious about the Quality of his work, and casts that onto others. “Treating people well” does not mean using kid gloves. It can mean expecting people to act like grown-ups, produce grown-up work, and not accepting less. I worked in an environment like that for decades. It was often quite stressful, but was also personally rewarding. It isn’t the tools that are broken; it’s the management culture, and no one wants to fix that.
- voidUpdate 2y agohttps://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
- benjaminl 2y agoThe story is satire. But the satire is illustrating true problems and attitudes.
- croes 2y agoA safer language accommodates every programmer. Nobody writes flawless code.
- tialaramex 2y agoIt's a deliberate echo of the famous Onion headline about America's absolutely disgraceful pretence that it couldn't do anything about all the shootings. https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_... > If someone has a choice, a safer more modern language can accommodate less skilled practitioners. This is the usual mistake. It's not a "skill issue". Footguns are a design mistake, they're much more dangerous than necessary hence the name. As a result the practitioners accomodated by a better language are all those capable of mistake ie all humans.
- pjc50 2y agoRather like the school shooting issue, the C issue is bound up with people at the identity level; they insist on the danger because they cannot stand the possibility of the danger being taken away from them. Their ability to use guns or C safely must not be questioned. They percieve it as an insult to take that choice away from them. They are the safe C programmer that never ships a CVE. They know that they themselves would never shoot up a school, so what the problem? Oh it's bad people. Well, that's happening somewhere else to other people, so it's fine and they can carry on. (edit: someone was helpful to provide an example in this thread; https://news.ycombinator.com/item?id=40438716 https://news.ycombinator.com/item?id=40438716 )
- jimwhite42 2y agoHere's an attempt to explaining the irrational part of programmers deciding which programming language to use. Part of it goes into more detail on ideas like C programmers insisting 'on the danger because they cannot stand the possibility of the danger being taken away from them'. "The Pervert's Guide to Computer Programming Languages" https://www.youtube.com/watch?v=mZyvIHYn2zk https://www.youtube.com/watch?v=mZyvIHYn2zk It's pretty out there, but I thought also interesting.
- pdimitar 2y agoCongratulations, you just landed in my very small number of favorite comments.
- danuker 2y ago> only the baggage a project needs What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think. RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocation.
- Xeamek 2y ago>What projects need manual memory management Games. Big/specialiased games to be precise, as for smaller projects managed language offer good enough performance.
- p_l 2y agoIn practice I found C/C++ "manual memory management" fans to know surprisingly little about memory management, or even how much manual memory management costs them in performance. High end games programming sometimes knocks the love of malloc()/free() (and naive RAII) out of them.
- l33t7332273 2y agoWhat does knowing a lot about memory management look like? Is it like being familiar with heap allocation, the structure of fastbins and co., and some knowledge of lifetime and ownership?
- p_l 2y agoIn addition to that, also knowing at least basics (a bit like "classes of algorithms") of automated memory management, memory pooling, understanding and using the knowledge of allocation and mutation patterns in one's program. A funny story related to all that from one of my previous jobs includes a high performance C++ code base that used forking to utilize preloaded code and data and to easily clean up after itself. Turned out that naive-ish (even with jemalloc dropped in) memory management in C++ code resulted in latency spikes not because of allocation/freeing, but because they put no control over where things got allocated which resulted in huge TLB and pagetable thrashing as copy-on-write got engaged after forking. To the point that using something like Ravenbrook's Memory Pool System (a GC) with threads quite possible would let them hit performance targets better.
- superb_dev 2y agoWhat’s missing from Rust? I don’t care if you use C, but don’t pretend like there isn’t another option
- pico303 2y agoMy problem with Rust is that it’s a hammer, and every nail is memory safety. If I’m writing a TLS library or kernel module, yes, memory safety is paramount. But if I’m writing pretty much anything else, Rust isn’t worth the slog.
- superb_dev 2y agoHow is that a problem with rust? Like any language it's a tool with strengths and weaknesses. Don't use it when it doesn't make sense
- pico303 2y agoSorry, should have been clearer. I was thinking in the context of every online discussion I’ve run across around “Rust vs. any other language,” where the diehard Rustaceans insist that we should just rewrite everything in Rust. Totally agree with you: use the best tool for the job.
- JonChesterfield 2y agoSimplicity.
- deleted 2y ago[deleted]
- yetihehe 2y agoSimple | Fast | Safe. Choose two.
- jamesdhutton 2y agoExactly this. It's all about trade-offs. You need to pick the right tool for the job. Sometimes the right tool is dangerous. Knives are dangerous tools, but you need them if you want to cook a meal.
- CJefferson 2y agoI'm trying to decide if this is a good satirical response to a satirical article? If so, well done! Because at this point, where can we find programmers who aren't 'less skilled practitioners'? Because it's clear Microsoft, Google, Apple, and major open source projects, have failed to find them based on memory corruption issues in the Linux, Windows and Mac kernels, chrome, and firefox.
- astrange 2y agoThe lack of memory safety is a property of C implementations, not the language itself. You can have an implementation that reliably crashes on memory errors if you want, though it does get easier if you leave out a few features like casting pointers to ints and back.
- cornholio 2y agoThere is a multiple decade long history of coaxing a memory safe C embodiment. If it was possible to simply implement memory safety without fundamentally changing the language, you would have a compiler flag that would give to you, requiring no source modifications. No compiler gives you that memory safety flag (aside from very specific security features, ex. -fstack-protector) because it's not possible in C.
- rini17 2y agoIt is totally possible for pointers with bounds checking to exist in C. Turbo C did that 30 years ago. However, why bother trying when whole culture is biased against it and you can use any of the other languages?
- akoboldfrying 2y ago>Turbo C did that 30 years ago. I used Turbo C++ (not C) back in the day, and recall near pointers, far pointers, based pointers, but I don't recall bounds-checked pointers. Do you remember any details? >However, why bother trying Because it would immediately make the large amounts of C code still in the wild safer for the users, who do care?
- rini17 2y agoI remember it as an compiler otion.
- baq 2y agoFor the sake of the example let's assume you make a C to Python compiler/transpiler which uses native Python arrays for every stack or heap based allocation and every pointer arithmetic would be replaced by a checked operation, you'd quite likely get a memory safe language in the 'shellcode impossible unless you really set the program up for it' sense.
- polotics 2y agoThis "accommodate less skilled practitioners" you wrote is something that never fails to puzzle me from C/C++ practicing colleagues: the idea that in the problem space there is a high-risk high-reward zone of top performance where only the heroes dare tread. I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C without the footgun baggage. Sometimes it is good to find a way to move on.
- Xeamek 2y ago>I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C This is just false. Sure, they probably are 'close enough', but you can't claim the performance is 'the same' simply because those languages inherently do more to achieve the same results.
- p_l 2y agoC inherently does spend more CPU time on memory management than some GC systems. The fact that a lot of C/C++ fans do not properly profile those areas of their programs does not mean they do not pay for them. Or that defensive coding (assuming they do not want to introduce a happy little accident of CVE into the world) is free compared to having compiler lift necessary asserts outside of hot loop. Some memory-safe languages even provide a faster feedback loop on exact instructions that will be executed for all code you write (probably most famous example is Common Lisp, which mandates that DISASSEMBLE is accessible to developer at all times)
- deleted 2y ago[deleted]
- xena 2y agoI 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 agoFine, 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 agoC 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.
- l33t7332273 2y ago>If someone has a choice, a safer more modern language can accommodate less skilled practitioners The implication here is thoroughly debunked. We’ve seen over and over again that memory safety bugs will happen in every C codebase(ignoring toy or small codebases). Even for the mythical and infallible “skilled practitioner” spending time re-solving the solved issues inherent to C just isn’t a good use of developer time.