Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existing software, as rewriting it at any reasonable cost or time frame is simply not an available option. A possible solution could be something like sound C static analysis tools that can guarantee no overflows etc. without a significant rewrite. The question we should be asking is how easy it is to use those tools, how scalable they are etc.
The memory safety problem isn't bad coders
91–100 of 225 posts
Re: The memory safety problem isn't bad coders
#92Earlier quoted context omitted.
C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)
How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.
Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.
Re: The memory safety problem isn't bad coders
#93What is it with these people and controlling the choices of other, quite possibly more experienced, programmers? Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be? The more of this bullshit I'm confronted with, the less inclined I am to…
In what way is this aiming to control programmers? This person is explaining how they would have experienced a difficult bug but a certain technology helped them avoid it. Seems like it's just "offer[ing] better tools".
Re: The memory safety problem isn't bad coders
#94In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…
Formal specifications can do all that if you build thetoing for given language and platform. Static typing is a subset of formal specifications. I suggest using the other phrase so they find more interesting stuff. Meyer's Design-by-Contract is an easy one you can do in basically any language.
Re: The memory safety problem isn't bad coders
#95What is it with these people and controlling the choices of other, quite possibly more experienced, programmers? Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be? The more of this bullshit I'm confronted with, the less inclined I am to…
Because ecosystems are driven by mindshare (popularity), convenience, adoption potential barriers, public shaming (eww, that's nasty, but .. people are people), and other psychological micro-foundations. Basically it's a cold war of persuasion. Sometimes leading by example works, sometimes by showing how awesome, cool, fast, safe your shiny stuff is, sometimes it works by appealing to people's sense of the "greater good" (how many Korean, Chinese, Iranian, Saudi, etc. democratists are in secret prisons, because broken C code).
And of course there's some truth to it. Look how Py2 is still not dead, because rewriting twisted is hard. (Which no one said it was easy.) And how long it took for distros to make it the default, and how long it took for anyone to not default to it. And of course there were people even complaining about how Py3 broke all their nice code that worked before by accident.
So if collectively everyone had made a push some years ago, we would be long over. But of course organizing these things is an even bigger problem than just sitting down and firing off PRs to twisted.
Re: The memory safety problem isn't bad coders
#96TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors." I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just…
There are several quasi-related variations. Arguments against higher level languages and abstractions. Examples: If you have to use a garbage collected language (eg, just about any modern language) it's because you're too stupid to know how to manage memory properly. [ various arguments against type safe languages, turning runtime errors into compile time errors ] Higher level languages and abstractions are just bloa…
> I'm optimizing for DOLLARS.
From the outside looking in, I mostly do firmware and test stuff. I see two things that seem to be mistakes developers are constantly making.
Lack of consideration for the how much cash flow each transaction represents. Selling clicks for ad revenue is orders of magnitude less than selling machine tools. And the number of transactions are if anything even more unbalanced. Low transactions high revenue per transaction usually means scale is unimportant and you shouldn't be paying for it.
And a quote from Robert C. Townsend's Up the Organization. Big companies didn't become big by acting like big companies. Trying to emulate GM is a path to failure. When the book was written people thought of GM the same way people think of google and facebook. The subsequent history is potentially a warning as well.
Personally I think 'scale' is important in early stages if and only if you're building a 'bomb' a company that's designed from the start to grow orders of magnitude in five years. So really people should ask where are we really honestly going to be in five years and target that.
Re: The memory safety problem isn't bad coders
#97> This wasn’t caught when I finished writing the code. It was caught weeks later, when rebasing against the other changes of the codebase. The invariants of the code I was working with had fundamentally changed out from underneath me between when the code was written and when I was planning to merge it. Aside from the wider question about bad coders, I don't understand why he didn't catch this when he wrote the code.…
I believe the implication is that when he wrote the code it compiled just fine. There were no reentrant mutexes, so one can assume the database connection he was working with conformed to Send at that point, and it was only with the addition of the reentrant mutexes that the connection lost the conformance to Send.
Re: The memory safety problem isn't bad coders
#98In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…
The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.
In C# var is always a place holder for the actual type which the compiler only accepts if it can figure out the type. If you do anything to the var that you can't do to the actual type it will still give you a compile time error.
Re: The memory safety problem isn't bad coders
#99Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existi…
No, it is the issue. Before one can even consider the proposition that it might not be wise to write X in C, you first need to convince people that the tool (that is, C) is actually a problem. That's what the OP is targeting: people think the problem isn't the tooling, but the programmer.
The task of figuring out how to actually use the language is an entirely separate, though valid, problem. But it's not some giant mystery. The folks working on Firefox haven't set out to rewrite the entire thing in Rust. They're choosing targeted places where it works. Insomuch as I know, this has been a success.
Re: The memory safety problem isn't bad coders
#100I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral. It was not until an early aviation s…
[drifting off-topic…] This article about early aviation covers what you're talking about and I found to be a great read: https://www.theatlantic.com/past/docs/unbound/langew/turn.ht...