Slashdot Mirror
Rust Creator Graydon Hoare Says Current Software Development Practices Terrify Him (twitter.com)
An anonymous reader writes:
On Monday Graydon Hoare, the original creator of the Rust programming language, posted some memories on Twitter. "25 years ago I got a job at a computer bookstore. We were allowed to borrow and read the books; so I read through all the language books, especially those with animals on the covers. 10 years ago I had a little language of my own printing hello world." And Monday he was posting a picture of O'Reilly Media's first edition of their new 622-page book Programming Rust: Fast, Safe Systems Development. Then he elaborated to his followers about what happened in between.
"I made a prototype, then my employer threw millions of dollars at it and hired dozens of researchers and programmers (and tireless interns, hi!) and a giant community of thousands of volunteers showed up and _then_ the book arrived. (After Jim and Jason wrote it and like a dozen people reviewed it and a dozen others edited it and an army of managers coordinated it and PLEASE DESIST IN THINKING THINGS ARE MADE BY SINGLE PEOPLE IT IS A VERY UNHEALTHY MYTH)." He writes that the nostaglic series of tweets was inspired because "I was just like a little tickled at the circle-of-life feeling of it all, reminiscing about sitting in a bookstore wondering if I'd ever get to work on cool stuff like this."
One Twitter user then asked him if Rust was about dragging C++ hackers halfway to ML, to which Hoare replied "Not dragging, more like throwing C/C++ folks (including myself) a life raft wrt. safety... Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos. I want to help programmers sleep well, worry less."
"I made a prototype, then my employer threw millions of dollars at it and hired dozens of researchers and programmers (and tireless interns, hi!) and a giant community of thousands of volunteers showed up and _then_ the book arrived. (After Jim and Jason wrote it and like a dozen people reviewed it and a dozen others edited it and an army of managers coordinated it and PLEASE DESIST IN THINKING THINGS ARE MADE BY SINGLE PEOPLE IT IS A VERY UNHEALTHY MYTH)." He writes that the nostaglic series of tweets was inspired because "I was just like a little tickled at the circle-of-life feeling of it all, reminiscing about sitting in a bookstore wondering if I'd ever get to work on cool stuff like this."
One Twitter user then asked him if Rust was about dragging C++ hackers halfway to ML, to which Hoare replied "Not dragging, more like throwing C/C++ folks (including myself) a life raft wrt. safety... Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos. I want to help programmers sleep well, worry less."
Well, his zombified hoarde of brainwashed language fanbois terrifies me, so I guess we're even.
Most professional power tools have quite a few safety features. Are you retarded?
To prevent casual accidents. Nothing is stopping someone from sliding the guard out of the way and jamming their hand into it. Programmers should know how to use their tools so they don't do the equivalent of sliding the guard out of the way and jamming their hand into it.
To prevent casual accidents. Nothing is stopping someone from sliding the guard out of the way and jamming their hand into it. Programmers should know how to use their tools so they don't do the equivalent of sliding the guard out of the way and jamming their hand into it.
You'd think so. And yet here we are with buffer overflows still causing havoc, Intel's best and brightest allowing your CPU to get pwned at the hardware level, Apple allowing anyone with local access to authenticate as root with no password, Adobe still shipping Flash Player update after update, Oracle releasing patch upon patch for Java and Microsoft being forced to un-patch systems that have just been patched due to a higher than expected number of reboots. Even OpenBSD which is secure by design and runs fully audited code isn't immune from remote exploits in the base install.
We have spare CPU cycles today, we don't need to code for the bare metal to get the performance we need. What we do need are safety nets and liferafts to prevent human errors from becoming security vulnerabilities. Humans make mistake. Maybe the top 5% of programmers would never make these kinds of errors, but not every programmer writing code for a major (or not so major) corporation is an International All-Star Programmer. By definition, 95% of them are not in the top 5% of coders.
Even with safer languages these errors can, and will, occur - but there are whole classes of errors and vulnerabilities that are able to be prevented by using a suitable language. There are other errors that can still be made in safer languages, but you need to go out of your way to do so.
It's the same with tools. There's a guard on my circ saw, but I can slide it out of the way if I try. It does mean however that after I've made a cut, if I put the saw straight down, it's not going to drive itself across my workshop floor, or cut my toes off.
Speaking of ML, I once had an interview at Bell Labs and they sent me off to another guy after they saw I had some SML experience. Then I told him that I preferred Lisp and listed some of the stuff I disliked about SML. I just got a funny look. Later that evening it dawned on me that the "New Jersey SML" might have something to do with Bell Labs, and I looked it up and found out I had just dissed the language in front of one of its chief designers...
I hate to break it to you, but the early power tools were very dangerous, they lacked handguard etc, and they lacked automatic cut-offs in case you cut yourself. You had to actually turn the power off manually to stop them cutting your fingers off, instead of having something you need to constantly hold down to make them work. Those safety features came about in the 1970s mainly, because when power tools started being used by home handymen in the 1950s, they were cutting too many fingers off.
Good tools take into account the range of people who need to use them, and add in ALL the safety that you can, which doesn't sacrifice performance. A few simple changes to C/C++ can reduce many of the common typos and bugs, by turning them into compiler errors. More errors picked up by the machine is a good thing. For one, if less bugs creep through, the cost of code and time wasted on code checking is reduced. This means even good programmers become more productive, while bad programmers get more feedback from their tools.
Unfortunately, Rust doesn't have any way of constraining the side effects of unsafe code, and most nontrivial Rust programs end up using unsafe in at least some places.
I am TheRaven on Soylent News
Unfortunately, Rust doesn't have any way of constraining the side effects of unsafe code, and most nontrivial Rust programs end up using unsafe in at least some places.
This is unfortunate: it would be ideal if there was graduated unsafety. Rather than havina an "unsafe" block with everything off, it would be cool if you could specify what you want relaxed.
On the other hand, it's a lot better than nothing. Having 99% of the code safe and spending extra attention on flagged unsafe blocks is better than having to look for pitfalls everywhere.
SJW n. One who posts facts.
I'm more concerned by trying to debug Rust than the editing aspect. Rust can be debugged through cdb, gdb, lldb etc. but none of that comes "out of the box" on Windows. It's much easier to get going on Linux since you only have a gnu backend and gdb is easy to install but even so you need little scripts to pretty up some of the data inspection. It would be nice if rustup or whatever had a simple way to install the debugger on Windows.
Concerning difficulty I think many of the same difficulties would be encountered if you chose C++ instead of Rust and came from a higher level language background. Both languages force you to think in terms of stack, heap, memory allocation etc. It's just that Rust will kick your ass up-front if you get it wrong while C++ will happily let you write errors into your code and you'll just have to discover them (or not) later when things break. Personally I would take that pain simply because it reassures me that code that comes out the other side has a lot less errors in it.
That might make the language seem more painful to use but its doing you a favor by making your errors obvious now, not later and to write safer code. I think the error messages from Rust are very useful. They tend to be descriptive and usually provide a suggested fix which is often right. Certainly far easier to work out what the error relates to than many C++ errors. It's not uncommon in C++ for a trivial code error to throw up a wall of impenetrable garbage thanks to templates and static typing.
An anecdote - I've been programming Rust for about 18 months now and do you know how often my compiled program has crashed because of a null pointer, dangling reference or some addressing error in all that time? Once. And that crash was in a C library I was calling from Rust! In other words the code I've written has never crashed a single time.
I see nothing major about Rust the language which needs to change. I think the biggest hurdle for people coming from C++ is understanding that stuff moves on assignment and there is no inheritance. So they have to unlearn stuff and think about doing things another way. It's certainly a hurdle but I don't think it's too tricky. The payoff is less bugs and ultimately that means better quality software, less support calls and happier customers. If I were developing for IoT or mission critical software I'd definitely choose Rust over C or C++ unless there was a reason I could not.
It's a bit hard for me to trust someone whose webpage had a banner proudly suggesting voluntary human extinction to make a programming language that is more secure.
Avantgarde Hebrew science fiction
Rust aims for thread safety only through the blunt tool of object lifetime management, but people make it out as though it performs magical compile time checks for deeper threading issues.
Those who do not learn from commit history are doomed to regress it.
This seems to be one of those unfortunate things (for both applicants and existing technical staff) that comes from bureaucracy as an organisation grows. As soon as you're big enough to have HR and Legal running the show in terms of recruitment, they're putting their own filters in between potentially good candidates and potentially interested technical teams within the business. That does avoid a lot of the time-wasters, but it also gets in the way of an efficient hiring process for qualified applicants.
I don't play in that playground any more, but my view when I did was that HR should restrict its screening to formalities (for example, can this person legally work here?) and objective facts about the candidate. And even then, since the objective facts most likely to be interesting are about the candidate's technical skills and experience, you still need someone who doesn't confuse Java with JavaScript and who realises that a candidate with 10 years' experience using SQL Server and MySQL can probably handle the Postgres skills you're asking for.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
To paraphrase Al Capone, "You can get much farther with a book and a community than you can with a book alone." To someone today who's looking to learn a new language, the community matters a great deal. Back the day when I learned C, it was more than the book (which to my memory, in its first edition had a poor introduction to pointers), it was the local community that for example allowed me to procure a copy of the Lions book that helped me learn it. This really makes a difference for the harder languages, compared to e.g. FORTRAN and BASIC which I learned before C.
PLEASE DESIST IN THINKING THINGS ARE MADE BY SINGLE PEOPLE IT IS A VERY UNHEALTHY MYTH
It is absolutely true. There is no myth to it. I have been involved in dozens of projects from the tiny, to the absurdly huge. On the small projects I have worked on, they were almost without exception, single developer projects. A single guy building the hardware (for that type of product), and a single software / firmware guy doing the programming. For more medium sized projects, You might break the software into UI and server type setup where each piece is handled by a separate person, but they are essentially separate programs with an API in between. I have also worked on larger projects where I was the sole developer. I had one where I was the sole developer and produced a system that had 50k lines in it. (I was replacing a 250k line product that was written by committee and sucked a fat nut). Took me about a year to reproduce the entire thing complete with learning about the requirements and documenting the new codebase.
I am currently working on another large product (high performance database implementation). We have 4 developers on the project, plus two people who perform code reviews only. Of those 4, only two of us actually produce code in any significant quantity, 1 is an entry level guy that produces what you would expect form an entry level guy, and the other produces not much. The biggest stumbling block is the reviews and documentation process. We do peer reviewed designs and peer reviewed code. The problem is that one of the two review only team members is hopelessly out of his league, and we spend huge amounts of time and effort arguing with him about the designs and review because he simply doesn't get it. He used to be a code contributor to the project, but most of the code he produced has had to be replaced (It was accepted before there was a review process).
The original team for this project consisted of two people, the reviewer mentioned above, and one other person that is no longer with the company. They hired more developers to increase the performance of the "team", when all they needed to do was get rid of the problem and replace him with a competent person, and the project would have moved along just fine. By keeping him on, they are simply slowing down the entire team. I would estimate that he is contributing about -70% of a developer worth of work because he creates so much more work for others than he actually contributes to the project.
TLDR: more developers rarely gets the project done faster or better. You need high quality devs and you need to get out of their way. The biggest challenge is that there are many times as many mediocre or bad devs as there are good devs, and it can be very difficult to tell the difference in an interview. Experience doesn't always mean better either. The problem guy above has been programming for at least 15 years that I know of, and if you give him a hundred more, he still won't be any good.
I wish I had a good sig, but all the good ones are copyrighted
I have never looked at Rust and never participated in Rust's community.
But when someone posted a clear, well-written comment with some very specific points, and then I see only people either agreeing with or attacking the messenger, but no one refuted the specific points raised... The only reasonable take away is that the points were valid and that got some people pissed.
It might be a copy/pasted post, so what? One can repeat a lie a hundred times, but one cannot repeat the truth?
Oliver.