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?
Yeah.... That's a source i'm gonna listen to...
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.
Can I compile Windows PE binaries properly yet? Serious question, last I checked it seemed very immature.
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
Ad hominem attacks because you can't actually address the issue; thanks for actually confirming the statement.
i guess all the "hard" programming problem have been solved. all the important algos have been invented/discovered.
so it amounts to: the less people learn "C" the more the salary of remaining "C" programmers goes up, non?
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
This seems to come up over and over.
I like to paraphrase Wiston Churchill. "C is a terrible language to program in, until you look at the other languages available"
Yes there are cases where specific languages have strengths and weaknesses. But instead of bashing a specific language and promoting another as a "complete replacement" lets look at why each language is used in a given niche and see if there is a better choice for that niche.
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
just by changing the file names and making a couple of basic changes. You can't play fast and loose with function arguments with C++, which is a good thing. This was a port of quite a bit of code, nothing that worked and compiled was changed. Pretty painless really, and we're ready to use all the nice C++ stuff (although most of our code is OO already, most functions get a context pointer as the first argument). New stuff will be able to use the nice stl:: templates.
"Rust" isn't a name that inspires confidence. Nor is "Corrosion," "Decay," or "Flatulence."
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.
Couldn't the job of proving a C program is "safe" be a job for an AI? If the AI can't figure something out, it could flag it for review. I guess what I'm saying is we don't need another language, we need verification tools.
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.
Wrong story, numb nuts.
systemd is Roko's Basilisk.
thank fuck at least it's not python!.
Go eat a dick.
Go to any construction site and you will be surrounded by tools that can quickly kill if not used properly or mishandled. Somehow buildings still get built and the mortality rate is shockingly low (given what they're doing and what they're working with). This is possible because they don't let you play with the dangerous tools until you've proven you know how to use them and if you f*ck around and do something stupid that endangers yourself or others you're going to get kicked off the job site (and your ass beat depending on where you are).
As with anything since we first figure out that flint is sharp and that is useful, you pick the right tool for the job. Sometimes that's C, it isn't always and quite often Rust, Java, .NET, etc. is a much better choice for a variety of reasons. But you don't stop using nail guns because dumbasses can't be trusted with them... you hand it to someone competent who knows how to use it and let them do their jobs.
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.
One of the best, most popular, and most powerful languages of all times sucks, so let's replace it with a shitty language no one uses and everyone hates! What a great idea.
Your choice of language should be context dependent.
C is used in some situations that spring readily to mind where Rust would not be appropriate:
1) Codebases that are elderly, dating back to the 1990's or earlier. Back then we used C for most things. Compiled languages were required for most types of programming, because interpreted languages were too slow for most things. [I know that Rust is compiled, but it also didn't exist until 2010. To me, something was either written in C, rarely in C++, or scripted.] You don't want to monkey with old codebases. If they're written in C, keep them in C.
2) Low-level programming. The kernel is written in C, and it should stay in C.
3) The command line. Shells and utilities are written in C and they should stay in C. There are so many utilities that you can use to lint these programs (from memory checkers to fuzz tools to any of the many versions of lint to output from both of the major compilers) that there really is no point in using anything else.
Rust and other, newer languages, including and especially interpreted languages should be used for new programming. Maybe if you have some things that are 10 years old or less then maybe you can convert them bit-by-bit to Rust or something else but it would be hard for me to justify this, either. I just don't see rewriting existing code piece by piece in another language to be a good use of programming time.
Oh, and by the way: Rust is ugly. No matter how safe or nice your language is in terms of security, the closer your language reads to English or another Western language the more successful it will be. All programmers (Western programmers anyway) have spent their lives since age 4 or 5 learning to read English or their native language. It's no surprise that the closer a programming language is to written language syntax, the more popular it is. I've been writing about this for a long time. C works, PHP works, and other languages work because they're extensions of the language of math, which is written in Latin. English is written in the Latin way, with Latin letters and similar syntax. Syntax, not just features, is important! Why do people both love and complain about Perl? Because people love Perl when it's written like English (French, German, Dutch, ...) and hate it when it's written cryptically, unlike English (French, German, Dutch...)
Go. /done
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
Well, Erlang, is not a general purpose programming language (built for signaling software in the telecoms); PL/I pre-dates C; and Ada does pretty well in embedded systems and flight control systems. All of these languages have taken root.
You are probably reacting to the straw man concept of "Correct Compiler for the Unbreakable Language", which are two different concepts. Partially correct compilers are proven to adhere to their language specifications on their target platform. And unbreakable languages are a straw man concept meant to discourage progress in the programming language design. However, there are those of us who want something better than C/C++, and we use better languages for our jobs, and thus, we get most of our life back from the endless develop/debug/maintenance cycle that dominates the life of C/C++ developer when they dare to do as simple as design their own data structures.
Rust as a programming language is not stable; does not have a specification; and it does not . That is the primary reason to not use it. There are much better languages than Rust.
Use modern PLs and get rid of bad developers. If you do these two things, you will out perform shops that only hire "competent C developers".
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.
Just wait until this guy hears what assembler lets you do...
One can write in C, Lisp, Rust, or straight machine code and still write software rife with security vulnerabilities. One can write in each of these languages and write software that is, for all intents and purposes, not likely to be exploited. The difference isn't just language features. It's a matter of proper analysis and proper testing.
Analysis *must* include formal methods for anything that has an attack surface. Proper analysis and architecture should minimize attack surfaces and build code in which critical parts are smaller and more easily scrutinized than less critical parts -- from the perspective of threat. The language is secondary to this analysis. When I hear people claim, "Rust is more secure", I laugh derisively. At the point of implementation, ninety percent of security analysis should already be sorted.
Daniel J. Bernstein demonstrated proper security architecture with qmail. He wrote the system in a combination of C and shell scripts, but he architected the system with defense-in-depth and process separation in mind. There were and very well may still be vulnerabilities in qmail, but the extent of these vulnerabilities were minimized through proper analysis and architecture. This is a real-world example, but it is imperfect. The point is not that qmail is secure -- it is not -- but it had better security architecture, *despite* these language level flaws, than most naively written Rust programs are likely to have.
The call to arms should not be to replace one language with another. This is missing the point. The call to arms should be to teach people how to properly architect software with security in mind, and then based on this, make language decisions that reflect this architecture. If this means using Rust for the more critical code and legacy C for the remainder of the system, then so be it. However, treating Rust or any other language as a silver bullet simply smacks of ignorance and wishful thinking.
Holy fucking $&!<:' worst delimiters EVER CHOSEN. It's like a hyperactive aspie found a way to marry to the worst aspects of C++ templates, Visual Basic, PERL and Brainfuck.
This is how you do ($string == "!important") in faggotass Rust:
This guy obviously hasn't heard of C++
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]
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.
I like the gratuitous extra slash, to help *distinguish* Rust from other languages that use doubleslash comments. And just look at those dangling commas. Sick.
WTF is "<(), ()>" ?? Some kind of code Emoji ?
> 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
Pffff Rust. Come one. Who is using that? Besides - it's oxidised as it is. If you really want to replace C code with something more palatable, then consider Swift.
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
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...
my C code has plenty of rust already why should I touch it?
Comments like this are why we still have a social stigma that programmers are childish idiotic nerds, good only at making people's sub-par crashy software.
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.
Is it possible to learn Rust without learning C first ? The numerous pointer types of Rust look quite complicated if you do not understand basic pointer bugs in C. And to understand them, debugging numerous segfault seem the shortest way to me.
M. Torvalds, do you agree with this statement : "if it's made with C, it's nothing but a bunch of security issues ?".
Totof
Replace dozens to hundreds of C compilers (ok ok, many don't work on the same codebase/different architectures without changes...) with a single source rust compiler, which requires a signing chain of predecessor compilers to generate the current one, trusting that chain to have been secure the whole way. OR trust any of the dozens to hundreds of C compilers, which would make it much harder to inject malicious code into the compiler to in turn inject into future compilers/compiled binaries, as well as ensuring if development stops on your favorite compiler, that some other compiler can take up the slack.
Furthermore: given up the ~20 years of ABI stability that C has managed to attain on the majority of still meaningful operating system platforms.
Tell me again how Rust makes sense from any of these points of view. Additionally, while C has lots of security failings given commonly used syntax, we have tools which can root out most of these bugs today. Does Rust have a sufficient analysis tool base to catch the same level of security errors across Rust? And furthermore: Does Rust offer support for a diverse enough set of platforms that you can 'compile anywhere' (whether or not the code needs other modifications to 'run' there.)
Every time the tech gentry is reminded that Rust is a thing they empty their bowels.
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!
... you probably shouldn't trust them with a keyboard.
While this might sound silly, at the moment you're dealing with a single source Ada compiler from GNAT, and almost all the open source Ada compilers available are derived from it. Furthermore it has its own build system gnatmake or something which is used for compiling modules, both for itself and the majority of ada packages compiled against it. FURTHERMORE there is no BSD/MIT licensed standard library for it, meaning people are less likely to trust it for non-GPL'd software which adds another checkmark against it.
Having said all this, if someone gets the old NYU Ada interpreter (written in C!) fixed up so it can support Ada95 or newer and output to a format that can be natively compiled and add an mit licensed standard library (maybe a C to ada redesign of musl-libc), I think that GNAT-GCC/ADA-LLVM could take off again and offer many of the security advantages people are asking for.
That said, my personal belief is we need a *NEW* language that isolates in-memory structures/datatypes from storage/network datatypes, so for example if an int64 is called for in a database, but the processor architecture only supports int32 or int16, the program function (which thanks to some dev assuming everybody has a 64 bit int datatype) would normally break on the other platforms, can now provide feedback that the function code would violate the on-disk format without changes or an 'overloaded' arch-specific function/code block. While C allows some nice low-level code development, it never really got the engineering necessary to help provide the level of portability it should have had for all code constructs. Having said that: I much prefer its efficiency and traditional/ansi c's 48k RAM compiler implementations. You are lucky to find a compiler that doesn't require hundreds of megs of disk space and 32+ megs of ram minimum (not including optimization passes bloating things up for a fractional percent performance increase.)
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!
It's honestly amazing to me that a language with such horrifically ugly syntax is taken seriously. And that's coming from someone who doesn't mind Erlang's syntax.
Some people will claim syntax doesn't matter, and there is some amount of truth in that, but it's also a marker for the quality of a language design, and in the case of Rust it doesn't look good. At all.
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.
Yeah comments requiring three ///'s definitely are childish and could only come from nerds.
The parent comment is completely correct.
Rust has an absolutely abysmal syntax that has been built with no thought to the programmer. How you expect anyone to want to use such gibberish is beyond me. It's frankly a language that goes out of its way to disrespectful to "humans".
Much like the Rust community themselves who seem to have painted themselves into a corner, realize that their utopian vision has become a steaming turd and are afraid to do a File|New.
The Rust community would do the works a much bigger favor by working with the C++ standards committee to add safe section support within the industry standard professional language, rather than spending time shilling on newsgroups and feeling hurt when there is legitimate pushback.
take a hike jon. people will be saying the same thing about rust in another 20 years.
Doesn't strike me a rant at all - a reasonably thought about the underlying question IMHO
sPh
Would you be so resistant to a surgeon using a robotic arm during surgery in order to compensate for their own potential faults in motor control or finesse? I doubt it. So even though that surgeon is no longer using the complexity of all 10 of their own that doesn't make them less of a surgeon.
What you're proposing is the technological equivalency of the Luddite. Move forward to newer languages and embrace them if they actually fit the need, don't just hang on because you don't like the change.
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.)
That is what Trump is doing too, replace the freaking free.... :) :)
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.
Besides, we all know Evans isn't up to the job of replacing any C code, so it's likely not going to happen.
Rust is shitty
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.
Censorship has worked so well in English.....
Because it's a problem with the language and not the idiot.... oh, my dad.
In another 50 years programming will return to a science. Until then designers will continue to put their opinions where they are not correct.
id10t errors like this are why the 21 century has ruined technology and its user.
I love this idea, Rust is so kewl!
I'm totally going to get started on this after I finish my killer golang project and my ruby on rails app.
If there is nothing better than C, why not fix the bad specs/behavioral parts of C(which in turn changes the compiler behaviour). Call it C-2020. I guess one probably need to recompile the code and fix the issues, eliminating a class of issues like buffer overflows.
Yes, tools matter. Yes, it's been a while and maybe we have learned a thing or two and perhaps we could cobble up a "better mousetrap" programming language that has most of the advantages and perhaps fewer disadvantages than C.
But that better mousetrap language is not rust. So, before we leave C behind, we'll have to find that actually better alternative. Best keep looking, eh.
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.
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.
No, languages like C are for people who actually know what they are doing and don't need a crutch.
When Pundits suggest things, they usually have political motivations, and I for one am not going to let politics dictate to me the language I will use because they think I have too much firepower.
let rust just rust away. I will stick to C and assembly.
How is this not just a glorified personal opinion of someone who prefers one language over another?
Security holes don't go away just cause you write code in a new language. Anyone who believes they do, should realize that the new language is just hiding the security holes from you.
Now, quite possibly, the new langauge makes it easier to re-design for fewer security problems. But I don't see that C is automatically Bad and some other language automatically Good.
Most C programs are bad cause most ppl stink at programming (overall, not specifically in C). But leaving those aside for a minute -- most of the other C programs are bad, because they were designed to be FAST. When C was created, the bandwith and CPU power was minicule compared to today, and the number of hackers, as well as the financial incentives driving those hackers, were tiny.
So sure, in that enviornment, security was barely on the table. Speed was king.
What's important is redesign, not language. sheesh Adding a new language to the problem, reminds me of this old joke....
quote
"Curse these personal computers!" cried the novice in anger, "To make them do anything I must use three or even four editing programs. This is truly intolerable!"
The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.
The novice thought for a moment. "I will design a new editing program," he said, "a program that will replace all these others."
Suddenly the master struck the novice on the side of his head.
"What did you do that for?" exclaimed the surprised novice.
"I have no wish to learn another editing program," said the master.
And suddenly the novice was enlightened.
-- The Zen of Programming
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.
Rust is not standardized nor is it supported through multiple implementations. Sorry but it is still too soon to rewrite my C libraries. I really need to wait for a winner to appear, and so far it is not clear that Rust is it.
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
Why not Swift - it is type safe and almost as fast as C.
I mean, wasn't ADA the be-all and end-all, and was provably correct?
While you're at it, why don't you do like Jack Williamson's Humanoids, and take away our power tools, and give us ones suitable for 10-yr-olds, and don't let us drive....
Or - I know this is a totally outrageous thought, horrifying to upper management and HR alike - you might HIRE MORE EXPERIENCED PROGRAMMERS, AND PAY THEM WHAT THEY"RE ACTUALLY WORTH, instead of offshoring or hiring "lead" programmers who are on their first or second job out of college.
Nahh, that'd be a waste of money.
The guy didn't suggest formal verification. The OP didn't propose government involvement. Where is the bloody reading comprehension around here!?
The proposal is actually rational and modest. Slow, incremental replacement, as the opportunities present themselves. Lots of code will never get replaced. We do it as an IT imperative precisely because management will never ask for this and if you separately did a budget ask, you'd never get approval. Well, most places.
I view this as akin to switching from an interpreted environment to a compiled environment. The compiler can help you! Proactive bug finding and quality control is better than reactive QC.
The big ask here is, you have to learn a different language (OK, that's not such a big ask), but you have to shift over all your libraries, your deep knowledge of the language ecosystem. The mitigating factor is, you don't have to do it all at once. You can start small and build your comfort level as you go.
Personally, I like the concept. It would take years but it adds value and moves us forward in a non-disruptive way.
You are veering dangerously close to the "No True Scotsman" fallacy.
For example: If an "expert" C programmer (a true expert!) knows they cannot making mistakes, what is their response to that? "C'est la vie?" "Sucks to be the user?" "QA will catch it?"
Seems to me that an "expert" C programmer (by your definition) felt this was an important issue, they ought to proactively switch to Rust, or at least away from C. And that includes even knowing that all non-trivial systems have bugs.
What can we hope, or not, from formal verification? For instance, can we hope that quality labels soon require internet connected things to be sandboxed in a formally verified core system that guarantees they can't be used as cyber weapons? /. and raise the awareness.
I was very excited a few years ago when I read about the "unhackable" drone involving seL4 and DARPA; I thought formally verified systems had made incredible progress and would be making more and more headlines in the years to come, as more and more bad behavior would be prevented in more and more sandboxed systems. But nothing came, and whatever google/wikipedia searches I've done since then didn't let me see the big picture.
Thanks a lot for your post, it's the first time I really learned something since then.
Is there any place where I can read a layman overview of the state of the art, current actors and practices, and research directions?
It looks like many slashdotters are as clueless on this as I am, so perhaps an IT guy (which I'm not) could just ask
Thanks again! -- Jean-Marc (yeah, this post's accent was French)
Like most of TechCrunch, Jon Evans is clueless. C++ does *all* of the things he is complaining about, still manages to hit bare metal (when done right), AND its template system can even outperform C in several areas (again, when done right). Proclaiming Rust as superior is stupid when it doesn't run everywhere. Of course, C++ doesn't run everywhere either but it runs in a LOT more places than Rust ever will.
Also, things that have rust are things that people generally try to avoid. What you name your programming language or software application matters. Rust brings to mind cars from the American midwest where salt hits the roads every winter to destroy both the roads and the cars riding on them. Defunct factories and trains just sitting around, slowly succumbing to the environment. And, finally, Tetanus. Lots and lots of Tetanus.
Does formal verification really prove correctness?
Or are there likely oversights and bugs in the formally verification processes and tools?
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
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.
The problem isn't the language but the idiot at the keyboard - classic PEBKAC.
C problems occur as much due to lack of planning as the language allowing dangerous code.
Rust won't solve anything by itself - again: lack of planning and groking the problem space is going to cause just as much fail as if you'd done in C!
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".