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."
Don't know enough about programming languages to recognise a reference to the ML language, even in a tweet that also describes some of its features? Just elide the references you dont understand and replace ML with "machine learning" and you too can be a Slashdot submitter! Don't worry, there are no editors checking that your summary reflects the contents of your links.
Well, his zombified hoarde of brainwashed language fanbois terrifies me, so I guess we're even.
The summary say "machine learning" but if you read this feed you'll see it's "ML". ML is programming language.
I know some people are excited about it but Rust is just the language de jure until it gets an actual spec that other people can implement.
Anons need not reply. Questions end with a question mark.
DeWalt doesn't sell power tools that go out of their way to make sure you don't cut off your fingers.
Unfortunately, they do. That's why when I get a new power tool, I have to make modifications to pare it down to an elegant C-style device:
I remove the blade guard. I cut off the grounding prong and file down the ears on the neutral conductor. I permanently glue down the little trigger interlock button. I put a lock washer on the blade arbor so that it can't ever slip and reduce my torque. None of these annoying things even matter so long as I never make a mistake.
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.
He is terrified of other language because, being a Social Justice Warrior, his group finds the terms "master" and "slave" to be "problematic."
No, I'm not kidding, though I wish I were.
When a language is gleefully throwing away well understood, well used terms because of someone's misguided feelings, then quite frankly I wonder what other decisions - truly important ones - have been impacted by the same toxic SJW attitude.
I have recently performed a relatively simple development by using programming languages on which I had low-to-to-no experience: Perl (low), Ruby (no), Rust (no) and Go (no). Note that I am quite adaptable on the programming language front and that this small experiment was precisely meant to showcase these adaptability skills. Rust was, by far, the most difficult-to-learn, difficult-to-research, counter-intuitive, unfriendly, constrained, unappealing, etc. of all of them. Warnings and errors appeared systematically and, despite their verbosity, were rarely helpful. I had problems even to find an editor/install it! (relied on Visual Studio Code in both Linux and Windows, an editor which I rarely use; and had to struggle with my Visual C++ installation on Windows, which was working fine until Rust came in).
The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one. Being so concerned about making sure that the generated code is extremely safe no matter what by sacrificing flexibility and user friendliness is far from ideal. Restrictions and prohibitions have always to be seen as an in-the-worst-case-scenario resource, not as a primary solution; much less when dealing with something as complex as programming, a very powerful tool supposed to be managed by knowledgeable individuals. The higher the freedom, the better the results delivered by a sensible/knowledgeable person. Unless Rust changes a lot, I don't see it going anywhere. It might get some support from theoretical/academical/inside-whatever-bubble circles, but seriously doubt that developers with real-world experience can like or even accept most of what this language represents.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Something that I find disturbing is that I actually saw this exact comment before. Why are you copy-pasting this over and over again?
Avantgarde Hebrew science fiction
To keep a long story short
Wow - I'd hate to see your long ones!.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I went back to C++, because even if it isn't a perfect language, at least it's a decent language with a honest, open, friendly community.
C++ is arguably the most complicated, the hardest to learn, general purpose programming language in use today. And, in the last seven years, with the last three major revisions, C++ has become, I would estimate, three or four times harder than it was before. If you were to start from ground zero, it would take you much longer than 2-3 years in order to be fully versed in all the arkane features of it. I would say that to become fully proficient in C++, when starting from absolutely nothing more than general knowledge of computer programming, will take at least 5-7 years, maybe even ten.
Because of that, experienced C++ developers tend to be older, and with many many years of experience under their belt. They've outgrown the phase of their lives where they think themselves to be #1 hot-shit masters of the universe. We're older now. We know better.
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