Slashdot Mirror
TechCrunch Urges Developers: Replace C Code With Rust (techcrunch.com)
Software engineer and TechCrunch columnist Jon Evans writes that the C programming language "gives its users far too much artillery with which to shoot their feet off" and is "no longer suitable for the world which C has built." An anonymous reader shared Evans' post:
Copious experience has taught us all, the hard way, that it is very difficult, verging on "basically impossible," to write extensive amounts of C code that is not riddled with security holes. As I wrote two years ago, in my first Death To C piece... "Buffer overflows and dangling pointers lead to catastrophic security holes, again and again and again, just like yesteryear, just like all the years of yore. We cannot afford its gargantuan, gaping security blind spots any more. It's long past time to retire and replace it with another language.
"The trouble is, most modern languages don't even try to replace C... They're not good at the thing C does best: getting down to the bare metal and working at mach speed." Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust... we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time."
He also suggests other fixes -- like using a language-theoretic approach which conceptualizes valid inputs as their own formal language, and formal verification of the correctness of algorithms. But he still insists that "C has become a monster" -- and that we must start replacing it with Rust.
"The trouble is, most modern languages don't even try to replace C... They're not good at the thing C does best: getting down to the bare metal and working at mach speed." Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust... we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time."
He also suggests other fixes -- like using a language-theoretic approach which conceptualizes valid inputs as their own formal language, and formal verification of the correctness of algorithms. But he still insists that "C has become a monster" -- and that we must start replacing it with Rust.
Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?
Why now? Why rust? What about Ada? They're not so different that somehow the argument becomes that much better than it was for Ada. I just don't get all this rust hype. But, then again, I'm a C programmer, and I am 100% certainly I won't see C replaced in the systems I work on (cars), so it's a moot point. I would, however, support a move to Ada. My industry would never consider Rust. Pushing it over Ada is actually counterproduction, because it primes the C-suite to see languages pushed as a replacement for C as immature. Rust is still immature, way too immature for a conservative industry. Ada, though... maybe not.
Well ain't that a self-confirming statement...
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I can't see CPython being replaced by RustPython anytime soon.
Or Erlang. Or Ada. Or PL/I. Or... or any of the 23 languages/environments that have been proposed since the Ada/Pascal/C split circa 1975. Yet none of these proposals have taken root. Why not? Seems to me that is just as important a research question as developing Yet Another Correct Compiler for the Unbreakable Language.
sPh
Basically, this is an admission that the average programmer is fairly shitty. Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Rust has one of the most aggressive fanboy cultures since the Ruby hey days. Those kool-aide drinkers infest every corner of every programming language forum (notably Reddit's C++ forum) repeating their mantras and echo chamber memes.
But yes, sure, let's start refactoring a kajillion lines of C that are out there working perfectly well. Let's replace working C with an immature, untried, untested language that is still largely under active development. As another poster said, what can possibly go wrong?
The world doesn't need more proof that these characters live in their own pink marshmallowy world of poofy clouds and fairies and wood sprites where reality can never intrude.
LOL@vword: astute
Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.
The usual PR stunt of "use my new language that is so good and so simple even a stupid high school teen with an IQ somewhere between stone and plankton in the phylogenetic tree could use it without wrecking anything" is not going to convince anybody here. It's boring at best, and no-one cares about your "advice".
The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe. Oh, maybe it's because they are written by competent guys.
Video of some good progressive thrash music
C was one of the most influential languages the world has ever seen, but all things reach a point where time moves and and they are not good ideas for new projects any more. I don't think we should necessarily go replace every line of C code out there - couldn't if we wnanted to - but for new projects we should use better tools now.
Tools do matter. It's just way way way too easy to write buffer overflows in C, even for highly experienced programmers. History shows that clearly. We need better tools that are not so dependent on the human being doing the checking. That isn't to argue you can't write bugs in Rust, just that it helps the programmer avoid some classes of problems. Slashdot readers tend to think "if it isn't 100% perfect and can't guarantee bug-free code then it must be worthless", but that's autism thinking at its finest.
People get attached to "the way things have always been done", but sometimes it really is best to move on. Yes, there is still COBOL code out in the world but that's not a language people use very often now for new projects. It did its job decades ago but we have learned lessons since then and we don't have to repeat the mistakes of the past.
It's time to leave C in the past.
Sorry I am not discussing the anonymous coward behind it, but the statement itself...
"They just show up to post random nonsense and exhibit absurd biases" - that's exactly how I perceive the GP.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
How about training developers on security policy, training mgmt on the need for secure code and the balance between acceptible risk and convenience, proper requirement and tests.
"Gentlemen, you can't fight in here! This is the War Room!" -- Dr. Strangelove
If something needs to be done in C because it talks to hardware (and everything operation that computes eventually talks to hardware), then having another layer in front of it that still needs to talk to C code doesn't necessarily get rid your chance to make mistakes; it might in fact leave you even more rope to hang yourself with. And it won't look like the same kinds of errors you're making now, which is why you don't foresee it.
One is data structures: in C there are no data structures. Any memory can be treated any way you like. So you can pack different bits and bytes together on one end and have them make sense on the other. At the cost of a potential security hole. But sometimes that's how you need to talk to hardware and for speed's sake, the thing that talks to the thing that talks to the hardware speaks the same language. Now if you impose a type-safe bounds-checked language anywhere in there, then one of three things will happen:
1. You can't do in the type safe language what you used to be able to do in C because you can't specify the necessary data structures anymore.
2. You can do it, but it costs you a ton of extra execution time, because even though you can *specify* an analogous variable-length data structure in your type safe language, the newer and better language makes no guarantees about how that data actually resides in memory, so when it gets to the C layer, there's a bunch of gathering and reconstructing and recreating that packed data from various places, all with bounds check overhead. This is what happens in Java.
3. You can do it, but you have to write a language extension to support what you're doing. And guess what language you have to write it in? C!
"Did you build it right?" is easy to answer. "Did you build the right thing?" is not. Language choice has nothing to do with that.
I have recently started a quite demanding development by fully relying on C and this experience has being quite eye-opening. One thing is knowing that C is really fast (and dangerous), but a completely different story is getting in there from a modern-language background.
C can certainly be extremely problematic in bad hands (increasingly careless attitudes in the programming world, anyone?). Also I don't see the point of using it other than under very specific conditions. But completely replacing it? I don't think that this is neither possible nor logical.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
The Rust community really worries me. It's far too tyrannical for my tastes. For example, they apparently aren't capable of acting like civilized adults on their own. They need a Code of Conduct to tell them how to behave, and a Moderation Team to act as what is effectively a judge/jury/executioner role.
What's worse is when they use these tyrannical apparatuses to attack others. For all of their bragging about how they value "tolerance" and "inclusivity", they so often exhibit the opposite behaviors. Just look at any Reddit or Hacker News discussion about Rust. Anyone who doesn't post a glowingly positive comment about Rust will quickly become the victim of downvote attacks. It worries me when people offering valid, correct and relevant criticisms of a technology are attacked, censored and silenced.
I've used a lot of languages over the years, from C to C++ to Java to Perl to PHP to Erlang to Haskell. But none of them have had communities as hypocritical, contradictory and tyrannical as I have found Rust's to be.
The Cheri CPU does pointer bounds and 'const' qualifier checking and some protection of C++ private member variables in hardware, sufficient to replace the security properties of virtual memory (with the caveat you can't unmap a page without killing the process), but without any idea of a "context" so security can apply to each pointer.
It's implemented in FPGA and only requires a few gates over a standard MIPS and is working with comparable performance without any exotic kinds of cache memory.
Buffer overflows aren't the only problem with C, but some of the other problems are fixed by C++. I think Cheri CPU would let us execute C++ with langsec approaching garbage-collected languages without pointer arithmetic like Java, Rust, Haskell, OCaml, Erlang, Go, etc. It's only "approaching" because I don't think it can solve use-after-free (there is some help from CCall/CReturn), but still it covers many bug classes. This could be particularly helpful for IoT stuff, $1 CPUs with 32 - 256kByte of RAM for the whole system: Cheri has the gate count and space efficiency to work, while virtual memory and garbage-collected language runtimes are probably both too expensive in both data memory and code size.
Security is the job of the Operating System, not applications, or users. When you run the program, and tell the OS which files it should use, that should be it. The program shouldn't have the authority to access anything not specified. This has worked in the mainframe world for decades, as you specified which virtual disks a system had access to when loading the run-time system. This works in virtualization, when you specify the disks the virtual machine is to use.
It's going to be a few more years for the technical community to finally wake up to the insanity that is ambient authority, then a decade or so to finally shift to systems that implement the principal for least privilege, like Gnu Hurd and/or Genode.
Rust is very tied to Mozilla. And Mozilla's only remaining "successful" product is Firefox. But Firefox's market share is dropping. It was only a few percent, last I saw, while Chrome is over 50%. Mozilla reportedly gets a lot of funding from Yahoo, due to a Firefox search deal. So here we have an organization with one major product, but this project is being rejected by consumers, and what might be this organization's most significant source of revenue comes from this failing product and is paid for by another company that isn't doing so well. I fear for Mozilla's future if, say, the Yahoo deal wasn't renewed and they couldn't find a replacement.
If Mozilla goes the way of the dodo bird, then I can't see the Rust project really going anywhere. I don't think it has a robust independent community like Python or C++ has, for example.
I think it is too risky to adopt Rust, especially for important long term projects. The tech industry moves fast. Rust could plausibly be gone in 3 years, while languages like C, C++, Python and PHP are far more likely to be going strong.
In the early 90s, I led a team of 10 that took on the task of re-engineering a working code base to eliminate a pervasive intermittent fault problem caused by many race states in the system and resultant dangling pointers and buffer overflows. The system contained over 180 devices, mostly custom, working together via messages on buses on a real-time task, simulating the rest of an A/C to an avionics computer under test.
The code was so bad that we decided to do a complete from-scratch rewrite of all software and firmware including programmable logic.
We switched from Intel PL/M (a simpler language with all of the problems of C) and assembly to ANSI C. We wrote custom language extensions for some of the code that was very patternistic and used ANTLR to compile to pure ANSI C. We religiously used a commercial Lint and Perl-based custom code checkers. After two years, on-schedule and on-budget, we shipped 30 revamped systems that worked like never before. There were only 5 bugs reported in the first year of extensive use.
Here's the kicker, we wrote over 3 million lines of ANSI C code in those two years, all new, with 5 bugs. It can be done.
That will go well. Especially as Rust is nowhere near the "silver bullet" it is claimed to be. No. Just no.
The actual fix is to hire competent coders. Incompetent ones will make their code just as insecure in Rust as they do in C. Sure, the insecurities will be different ones, but that is it. Software quality never has been a question of the language used. The only influence the language used has is how long coding takes. Software quality (and in particular security) is solely a question of the skills of the coders used and the time they are given.
My take is that this is just another cretin that mistakes "new" for "good" and "old" for "bad".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
To be able to code effectively in C you need to have been doing so for at least 3 years and, preferably, spent 6 months or more writing in assembler. I am not saying that without this people cannot write good C, but I believe that this is what is needed to provide you with the level of insight that is necessary to be a competent C programmer. To be a great one, add a few years experience.
C is not a language for every one, it is not a language for all problems. But for some it is a good language. The trouble is that some people use it when the, perhaps, should be using another language and then when they get problems blame the language and not themselves.
Anyway: how can you call a language complete if it does not have a GOTO statement ? I'm not saying that I use it a lot, but it is useful for handling errors & similar. I will doubtless now be flamed by those who have heard Dijkstra's complaint about GOTO and not understood it. I remember programs where one in every three statements was a GOTO - yuck, that is what he was complaining about; not about the single GOTO in every 1,000 to 3,000 lines that I seem to write. Yes: I could eliminate those GOTOs but either by making the program less clear (by introducing extra state variables, or similar) or by making it less efficient. His complaint was about excessive use of GOTO, many who have not read the paper, or do not have enough real programming experience, forget that important qualification.
I'm sorry but I don't see the security problem, at all. All I see is a bunch of hyperbole.
First thing one learns in security is that as long as humans are involved then you have a problem. RUST only addresses one aspect of human involvement, operator error. RUST does not address backdoors of design. The recent IOT attack the created the largest DDOS attack was such a back door.
If the past is any indication of the future then RUST will find its niche and that's it. Safe malloc libraries have been around a long time. But, and here's the but, protection comes at a cost. Kernel developers care about that cost. RUST is being put out there as a free lunch, security without cost. We know that is not true. Instructions need to be run to secure things. Kernel calls that are called orders of magnitude far more than user space calls require bare metal performance.
It would be interesting to see the statistics on the security attacks over the years so as to compile a percentage of types of breaches. Password hacks are far more common the buffer overflow attacks. So, the question is how much so? The Sony attack was a password attack. If an analysis is done whereby the security breaches due to human error of C coding are minuscule relative to the total then RUST needs to be accounted for: the cost of replacing C with the risk of C breaches. I'm guessing that calculation has already been made.
Finally, my advisor at UC Berkeley sat on the Board of VISA in the 1990s. In one class he invited students to breach VISA's network protocol. And guess what, someone did. The student's analysis was that security protocol wasn't of the highest order and known breaches existed on the Internet. This was the lesson for the day. The cost of loss for VISA due to security breaches was lower than the performance cost using better security.
The RUST advocates need to make a better business case than just "RUST is better security". What the RUST advocates such as the one are doing is spreading FUD. The sky is falling! The sky is falling! But if you ask security experts what their top security priorities are, human error due to the C programming language is not in the top of the list.
For the sake of discussion. I haven't used but worked with people who did. They said it was much better than C or C++. Can anyone weigh in on the pros and cons of Go?
putting the 'B' in LGBTQ+
I believe that we are about a decade away from a disruptive change that will obsolete all of this. The refactoring would probably take longer.
At some point, we are going to change to a system in which neural networks are the system and a swarm of traditional processors running very small, tight, calculator-like algorithms are tied within the neural network. This merging of calculators, memories and artificial minds will occur long before any intensive augmentation of biological minds - likely in the next couple of decades. Most of our computers will be grown up versions of Google's assistant, Alexa, Siri, etc.
These computers will defend themselves with intelligence, not good coding. The main danger will be from snakes with convincing arguments, not buffer overflows.
Ah, yes. Python, the language that pretty much requires its users to know what they are doing. Just like C, come tho think of it. All the hate against these languages comes from one corner only: Those that cannot hack it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Not anytime soon. As in certainly not in the next 50 years. The little problem is that current AI is exclusively "weak AI". and that is the AI without intelligence. All it can do is statistical classification and that is not enough. So for the foreseeable future, the only thing that can make code secure is competent coders. "Pay peanuts, get monkeys" is the main problem that causes insecure code.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Erlang was originally developed to facilitate the creation of provably correct real-time communications systems. The argument (all the way in the dim depths of 2014 here on Slashdot IIRC) is that in today's world all software will eventually be connected to the Internet and both its interactions and its databases may be located at multiple remote unreliable locations/links, and hence all systems can be (and then proceed to should be) modeled as real-time communications systems requiring provably correct software.
I'm not saying that Erlang has the features needed to create general-purpose business systems, nor am I an advocate of the language, but that's the argument that is out there. Or was 3 years ago; now we have moved on to Rust. Somewhere down at the bottom of the pile is poor old ALGOL...
Yes, PL/I was out there in the 1965 time frame. Many of what we consider "modern" languages were developed in part to avoid the horror and expense of using PL/I. (keeping in mind that most of the programming language design guys and gals from 1955-1975 knew and interacted with one another). Also similar to Ada in that the in retrospect it is hard to see what the perception of horror was all about. [disclosure: I personally always liked PL/I]
And that is just it. A C coder needs to be competent, or the code will be horrible. But the same happens in other languages, just that it is less obvious and that is a problem in itself. The problem are not the languages used, it is that there are far too many bad coders.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's almost like the rest of us are more interested in the future of systems programming than casting decisions on some television show. If this bothers you, maybe you're on the wrong site.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
That seems to be a very defeatist attitude. Formal verification doesn't need to be a huge burden. After all, we enforce many useful properties of our programs automatically all the time just by using strongly typed languages. (Obviously less so with needlessly dangerous languages like C and C++, which seems to be the fundamental point in this particular discussion.)
It's true that it might be prohibitively expensive to formally prove every conceivably useful property of every line of code using the best known methods. Indeed, just figuring out how to specify exactly what you do want to prove isn't always straightforward.
However, this isn't a black and white issue. We could do much better than we actually do in everyday software development, and the savings could be substantial. The fact that we don't use more powerful tools and more powerful methods routinely is more down to some mix of developer ignorance and hubris than anything else. Most working developers probably don't even realise what is possible or know roughly how the tools and processes work, because unfortunately this remains a relatively low profile field for now. Too many working developers would rather just play with the latest libraries that came out this week in their painting-by-numbers languages anyway, or listen to consultants who've never written a piece of critical software in their entire careers offering the false promise of good code without having to spend much time on things like proper design or documentation.
We could do so much better with even a modest investment in developer education and a willingness of management to look beyond the current quarter's accounts. Ironically, given the savings from better quality code both due to lower maintenance costs generally and particularly in areas like security or regulatory compliance where failures might also have $$$ fines attached, it might even work out cheaper in the long term to develop in a more careful, considered way. Just some robust analysis of the different possible cases and data flows and so on would probably turn up all kinds of lurking bugs in everyday software, and this is hardly beyond the abilities of an average developer if they have some awareness of what is possible.
Now, if our priority is to build throwaway web/mobile startups that can TDD an MVP in ten seconds and don't care much about long term maintenance or quality because they're going to either flip or fold the business within a year or two anyway, or if we're interested in in-house business admin systems that need to be as cheap as possible right now because it will come from someone else's budget if we have to fix any screw-ups later, none of this matters. But if we actually want to build good software, then at some point we have to start playing the long game and looking at options that aren't the quick, easy path all the time.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
> disclosure: I personally always liked PL/I
Are you kidding?
Ok, serious question: is PL/I still being used somewhere?
I remember the thing from back in the late 80s but never bothered to learn it. I met the wife of a colleague in 95 and she claimed to be working it, which surprised me a bit, even then.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Unfortunately, not everyone can play Premier League football or win Formula 1 races.
The real issue for most managers is "how to use the bunch of plonkers HR have hired" - its all very well saying "sack 'em and get some new plonkers" but the new plonkers will probably not be better than the old ones, and will have even less experience of your project.
Reality is a bitch
The issue is not how do you get good ones - that is easy - have a recruitment process that can tell the difference and pay more. Now, go on, just do that!
This also applies to teachers in schools and colleges (subject of griping in previous posts) - and politicians.
Sent from my ASR33 using ASCII
i've recently converted from C++ to Swift — better modern native unicode string handling, and scales really well from beginner semantics all the way to system level stuff. its a great language to work in — and written by chris lattner (who wrote the clang and LLVM compiler/architecture) — so its well fitted for performance optimizations/very fast.
swift is the first language that i'd say i feel comfortable replacing C++ with.
2cents from toronto
john p
The whole point of this posting is that you should rewrite NetBSD in Rust. Without losing any portability. It is really quick and easy with such a modern and trendy language - you might even finish by next Thursday.
I expect it to work fine on a 6809.
Any failure will be punished by a lifetime PHP project.
Sent from my ASR33 using ASCII
IBM still sells/supports their compiler, or at least did the last time I checked a couple of years ago. I doubt it is used for anything other than support of very old legacy code. All the PC compilers are gone now I think. I wonder if anyone at Cornell even remembers PL/C?
There you go: available for both z/OS and AIX!
http://www-03.ibm.com/software...
As long as we allow bad coders to write mission-critical code, the problem is not going to go away. Sure, there are other problems as well, as the one you describe, but the core problem is that people that have no business doing so are writing code. And this "code boot-camp" madness is making things worse.
For myself, I cant complain. While I usually do security consulting, I recently had a larger project coding some Apache modules in C (no other choice as there were both tight memory and speed constraints) and I did it at the full consulting rate. That boils down to around 2.3 times what that customer pays for a "coder" (Java monkey, really). Also, all the bad coders around assure my primary job. But the sheer stupidity of what is going on does offend me, in particular all those morons (this time "Rust morons") charging off screaming "Hurrah!" in the _known_ to be wrong direction.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
my C code has plenty of rust already why should I touch it?
The day TC can write this in Rust i'll spray WD40 all over my screen. main(int c,char**v){return!m(v[1],v[2]);}m(char*s,char*t){return*t-42?*s?63==*t|*s==*t&&m(s+1,t+1):!*t:m(s,t+1)||*s&&m(s+1,t);} Jake.
In order to form an immaculate member of a flock of sheep one must, above all, be a sheep.
If only there was a language that was mostly compatible with C, to the point where you could slowly migrate an old and massive C project to that language and then slowly replace thigs with more modern features that make correctnes much easier.
SJW n. One who posts facts.
Because people are stupid. Yes I include me in that category. Oh the myths of how gods own language with the dangerous (=unchecked) but powerful design was so fast and nice and ... Yeah I bought into that idea. The fourth language I learned. And was soon let down. It was a primitive language with few features. The compilers were obviously bad if one ever had used assembly language, in some cases interpreted Forth was faster(!). The big thing was that is was portable. Or so "they" claimed. In practice that was limited to a subset of machines and even then most c code was filled with defines to create some kind of meta-language to get that portability. Some skilled programmers could write beautiful portable and good code in C. Most couldn't.
But people like me thought that C was the good thing and alternatives were crap. A lot of code were created in C, a lot of people got C experience. That lead to increasing use of C in a lot of companies even when other languages would be the better choice. Some software actually said outright that it was written in C as if that would be a guarantee of performance or portability. It sure wasn't a guarantee of code quality or reliability.
Then the years passed, C++ became actually usable. The same idea of C/C++ as something superior still remained and more code was created in those languages. Some weaknesses of the C family were polished. C became the default standard and most other languages simply ignored.
So there is a mental (=developers, ex-developers in management, management that thinks C family languages is equal to portability) and physical (=a lot of code written in C) bias towards C, strong attractions of using C family languages even when they aren't a good fit. So now we have the standard tool but we don't have the skilled programmers that can actually write good code using it. It isn't systems programmers with good knowledge of the machine they are using that writes C code - it is application level programmers that use a polished systems programming language writing code on an abstraction level the language wasn't designed for in the first place.
Sorry for the ranting.
You don't want to monkey with old codebases. If they're written in C, keep them in C.
The developers of GCC made the opposite choice. They migrated it from C to C++ a while back. The first stage was to ensure it compiled and ran correctly on both. They are still migrating since GCC has crazy requirements on compatibility for bootstrapping, which is fair enough.
SJW n. One who posts facts.
M. Torvalds, do you agree with this statement : "if it's made with C, it's nothing but a bunch of security issues ?".
Totof
I love C. That's first. Second, I haven't read this TechCrunch person's post, but I am generally not inclined to believe anything on TC beyond their analysis of the industry (if I even believe that!).
HOWEVER,
I wanted to share this paper from HotOS 2017 about formalizing type safety in Rust:
https://www.ics.uci.edu/~aburtsev/doc/crust-hotos17.pdf
I thought it was interesting. In light of this discussion, I thought someone might find it useful!
Will
remove nospam. to email!
It is argued that formal verifications of programs, no matter how obtained, will not play the same key role in the development of computer science and software engineering as proofs do in mathematics. Furthermore the absence of continuity, the inevitability of change, and the complexity of specification of significantly many real programs make the formal verification process difficult to justify and manage. It is felt that ease of formal verification should not dominate program language design.
De Millo, Richard A., Richard J. Upton, and Alan J. Perlis. "Social processes and proofs of theorems and programs." The mathematical intelligencer 3.1 (1980): 31-40. (Reprinted from Communications of the ACM, Vol. 22, No. 5, May 1979.)
https://link.springer.com/article/10.1007/BF03023394
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices? Why is it that we need to replace the language at all? The whole point of putting logic in software is that it can be changed relatively easily.
HA! I just wasted some of your bandwidth with a frivolous sig!
Rust developers seem to think that Rust is the answer to everything when it is not. I recall getting into an argument with a Rust developer over the fact that I refuse to even look at Rust. I write low-level boot loaders with a mixture of C and some assembly language for embedded systems where size can be a real premium and I'm working close to the hardware where things like pointer checking would cause a lot of problems and I don't have space for all the extra overhead (i.e. bounds checking, garbage collection, etc.) when every byte of space counts. In addition, I am cross compiling using the GCC toolchain optimized and tuned for the particular chips I'm working with (MIPS64 and ARMv8). Rust would be a big pain in the butt for the stuff I deal with where I frequently rely on the features of C that are considered "unsafe" like typcasting pointers to specific memory addresses, allocating memory without garbage collection, etc. While you can do those things with Rust, all of those Rust features get in the way and require language overhead of a run-time library (I don't have the C run-time library in many cases). Then there's the fact that I know the C cross compiler is very well supported and optimized for our architecture (we have a team of compiler people where I work). On the side I'm playing with an ESP32 (Xtensa CPU cores) device and Rust is not supported. C and C++ are supported, on the other hand. I was just looking at TLS support for a project I'm planning on the ESP32 and found an open-source cross-platform C library for it that works within its constraints, considering the fact that it does not have a real operating system. As far as I can tell, Rust is not supported at all on the ESP32 since LLVM is not supported (but gcc is).
I can throw C at basically anything. In some of the MIPS bootloaders I've written I need only about a page of assembly code before jumping to C code. There's no way I could do that with Rust.
No language is good at everything. C has a very long track record and is supported by virtually every CPU out there other than some extremely limited micros that only support assembly language or other oddball languages. (I once worked with a processor that executed a functional programming pattern-matching language in hardware that was incapable of running C). The FPL was basically assembly to this processor.
I don't know Rust other than what I've read about the language and I'm sure it has its place. One other thing to realize is that a lot of languages come and go.
Look at Java, for example. At one point there was a huge rush to support Java for everything but that has died down. One doesn't see many Java apps any more and I must say that it's always a major pain in the butt every time I need to use one now (especially since Oracle's Java RPM is broken and won't install without a lot of hacking... they screwed up the alternatives settings). Also, Oracle refuses to upgrade their Java plug-in to work with Chrome and modern plug-in interfaces.
C and C++ are very well established and have long track records and they are not controlled or dominated by any one company or group. I've also lost a lot of respect for Mozilla. The Firefox browser has been a disaster for a long time, and don't get me started on how bad Thunderbird is... Thunderbird on all of my systems is so slow I can barely type to compose an email due to its horrible single-threaded nature. I dumped Firefox for the most part a long time ago and haven't looked back. The horrible memory leaks and bad single-threaded Javascript killed it for me and they ignored the major problems for years. There's a reason Apple adopted KHTML for Webkit.
There are plenty of other similar programming languages, i.e. D, Go, Swift, etc. Only the test of time will prove its success. C and C++ have withstood the test of time, warts and all.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
DB: HAL, I think I've detected a logic error in the main core.
HAL: I'll get right on that Dave
Doesn't strike me a rant at all - a reasonably thought about the underlying question IMHO
sPh
I remember this came up on Postgres mailing lists earlier this year: https://www.postgresql.org/mes... Perhaps someone can code some machine learning code-converter to do it :-p
The strength of Rust is that it has a great static analyzer. ... Use them. No need to rewrite everything.
But C also has great tools : linters, debuggers, test frameworks,
The real problem is that ADA has End If, and all the cool kids use {}. It also normally counts from 1 which is so archaic -- had a word about that to my kid's kindy teacher.
(Ada is also obsolete because it does not have garbage collection, which is the number one issue with C in practice (providing you write it very carefully). Ada is also rather facist. There is a place for the very occasional explicit unsafe array access (like .Net). C was obsolete when it was invented, and many people said at the time how horrible it was. But it grew prominant with Unix. And no, Java is not slower than C in practice.)
Well not a surprise actually. Peter Bright at Arstechnica.com made a similar pitch last year or so. Just as poorly thought out although more verbose than this piece.
New programmers are being trained in what language? Yep, Java (or worse java.script). Many of the code camp type of pushes appear (to me) as pitches to have everything run in the cloud/on the web/in HTML 5. None of which teach anything at all about systems, security and coding standards. How can you enforce a standard on crap? Just plop it down, see if it works.
The people making these pitches are not people that I would hire/trust. Sorry. If they aren't capable of doing the job, then don't hire them. I have a few people I would trust to write systems code. A few more that I would trust to write user level code. None of them were trained in Java. And we all write in C.
There is C.
There is no C++.
Hah!
Why do tech. people give things wacky names? Things that are rusty get thrown away. On the other hand, if they wanted a wacky name, why didn't they go all the way and call the Rust language "Feces"? Okay then, how about "Vomit"?
"Lisp" is a speech impediment.
"Gimp" is a person who limps or is lame.
But hey! Why voluntarily restrict technology names to only 1 alphabet? "LaTeX" LaTeX uses Greek letters, also, and requires two paragraphs in the Wikipedia article to explain the name.
There. FTFY.
Because before Rust there weren't any languages that let you incrementally replace C code and have safety.
Just type checking. If I take the time to define an enum, or even just a type, don't just mush them all into integers and let them all be the same. That one check would catch a lot of consistency errors. For example, I do a lot of Modbus programming with 1-based Modbus addresses which turn into 0-based offsets in tables. I would love to define some variables as OneBased and ZeroBased, and specify that my table index has to be ZeroBased, And don't compare with assembler, I worked in IBM assembler for nine years, I'd *rather* work in assembler because IBM assembler macros had more capability than C++ templates. I could have donw better type checking that way.
IMHO, C should be replaced by a better language. The most important peace of software that should be replaced is the OS. The new language shall be perceptibly optimized for this task so that you can convince Linus Torvalds to migrate. Once Linux is migrated, conquering the rest of the world will be peace of cake ;-)
People like this have no business developing software. Countless projects use C and have been able to use that artillery to make very stable software that runs systems Aircraft Systems to powering Word Processors. When someone suggests dumping C it hearkens back to the day when they passed legislation requiring all defense work be developed in Ada. I've looked at Rust, but definitely not a fan. Why use Rust when there is Ada? Not invented here syndrome is back in full force with the kiddies. C is a language for big boys that need and want that "artillery". I don't understand why people have such a problem with C. Memory management is not that difficult. Error handling is not difficult. I've found nothing is difficult in C, even Bjarne Stroustrup's claim you're unable to abstract is bogus. structs can have function pointers. I've been developing for 30 years and C/C++ both languages will be around longer than I'm alive. Rust and Ada are pretty much the same language. Why did someone spend the time developing another language called Rust? Learn C, C++, Java and Python and forget the rest of these pet projects. Oh, Learn Ada over Rust. Ada is far more advanced and extensible than Rust will ever be.
C++, or even Objective C... but mixing C and C++ is usually worse than either of them.
In your Apple-only world Swift might be an option.
For the rest of the world, it's far from being a C++ replacement.
And Has someone written comparable sized programs in rust ? I haven't seen them - have you ?
Linkedin http://in.linkedin.com/in/robinsaikatchatterjee
I agree! "C" is a letter, not a name for a computer language. Yuck.
Worse!!! C++ is a name spelled with a math symbol.
Then there is the D language.
Replacing all existing C code with rust is a wonderful idea. All those worries about hackers and safety-critical systems failing due to a surprising int/float conversion will be gone. The only danger we have to worry about from it any more is tetanus.
What's that? Rust is another programming language you say? Oh well, that's very different.
C++ can easily eliminate buffer overflows and dangling pointer problems. It isn't perfect, but it's better than C and very easy to move to from C.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Formal verification proves that the program corresponds to the specification. It doesn't prove that the specification is correct. It's really hard not to run into Goedel's incompleteness theorem and discover that the specification is actually more complex (and therefore error prone) than the program.
I am TheRaven on Soylent News
There's a lot of ongoing work. Some of it is in formal models of programming languages: we had a paper in PLDI last year on a model for C (which has to be parameterised, because it turns out the C standards committee, C programmers, and C compiler writers have almost totally disjoint ideas about what C means). We're looking at combining this with formal models of CPUs to allow black-box testing of compilers (if we can prove that the output corresponds to the input then we don't need to verify a few million lines of compiler). There's white-box stuff, such as the Alive project from Utah and MSR looking at proving correctness of a number of the peephole optimisations in LLVM (although, unfortunately, it's so far managed to prove incorrectness of a depressing number of them).
Beyond that, there's a lot of ongoing work improving the proof tools. Coq, Isabelle and HOL4 are still in active development and AGDA has gained an increasingly large following in recent years. The more that you can automate the proofs, the more feasible this kind of thing becomes and, in particular, the easier you can make it to write modular proofs the easier it is to maintain the code. The CEO of Intel just after the Pentium FDIV bug started to pour money into verification and made quite an insightful comment in this regard: He didn't care how much it cost to verify something the first time (it had to be cheaper than doing a full recall), but he needed it to be cheap to re-verify after some changes. Centaur (formerly VIA's x86 chip division) incorporates a lot of verification into their CI system: they're a long way away from full verification, but their verification tools help catch and pinpoint a lot of things that would otherwise (probably) show up in testing in the simulator as 'something is broken in the design'.
There's also a growing push towards proof-carrying code. The F* language (MSR and INRIA) is probably the best example in this space. It's a version of F# that allows you to write proofs in the same language that you write the code and only compiles when the code matches the proofs. Unfortunately, F* still has a very long way to go before simple changes are easy. For example, they have a talk where they walk through verifying a quicksort implementation. If you want to change the quicksort to a heapsort, then you have to throw away most of the proof (and the proof is more complex than the implementation, though at least the input / output specifications are simple and so you can be sure that the proof is correct if it compiles). They're also using an SMT solver (Z3) on the back end, so there's no guarantee that it will actually terminate: you will either get a counterexample, a success message, or a timeout in the solver and a timeout doesn't necessarily mean that the proof is correct or incorrect, just that it's too complex to machine check.
I am TheRaven on Soylent News
It is very very hard to create the sort of defects that cause the majority of cve in rust. Needs citation sure. But out of bounds by itself. Just look at cve for java vs c or c++. If there is a turkey carving knife that has a handle who cares if it is perfect as long as you can cut turkey with it? Put down the one that is all blade! Most of my 15yr career has been embedded c++ and I see what even good developers sometimes do. Most of which you couldn't compile in rust (or Ada).
refactor the law, its bloated, confusing and unmaintainable.
I'm not sure exactly to what "tools for debugging" you refer. But your operating system ought to be able to give read-only access to the log files to a particular ordinary user account. In GNU/Linux distributions based on Debian, users in the group adm have read privileges throughout /var/log but little else. Think of it as standing for "ADministrative Monitoring".
Thanks a lot for this overview. It looks like the only active giant is Microsoft, which I interpret as: there's no money to be made there soon.
It's more that Microsoft is the only big tech company that had its reputation hurt badly as a result of poor security. Android security is arguably worse than Windows XP (definitely if you consider how much better it should be given that they had a decade to learn lessons from XP), but Google doesn't yet have a reputation as a vendor of insecure software. Apple invests quite a bit in security, but if you read the list of fixes in the security update from a couple of days ago (including a privilege escalation in the library used for IPC between sandboxed and unsandboxed processes that allows sandbox escape), you can see that they still have a long way to go, yet aren't big malware targets yet. Companies tend to invest in formal verification after some expensive negative PR. Intel did after the FDIV bug, Microsoft after things like Slammer associated 'Windows' and 'insecure' in the minds of their customers.
The thing I don't understand is: how come we still live with internet connected things botnets (CCTVs and such) that can e.g. deal massive DDoS attacks?
Participating in a DDoS doesn't take much and is hard to prevent. If you have a million devices on a 1Mb/s connection, they can easily overwhelm someone on a gigabit connection, even using a sufficiently small amount of their available bandwidth that they won't be spotted at the endpoints. Being able to create a botnet out of these that can launch a DDoS requires a vulnerability and a monoculture. Most software will have at least one exploitable vulnerability, but finding a vulnerability in a thousand different things is prohibitively expensive. If there are a hundred million devices all running the same Linux version or the same network-facing application, then an exploit in that lets you build a botnet.
By the way, DARPA has been funding a lot of research in improving security, including the project that I work on.
I am TheRaven on Soylent News