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."
I've seen it all. DevOps guys who can't deploy kubernetes, build a docker container or setup a decent CI pipeline. Software Engineers that still can't master the to fundamentals of Object Orientation after decades of practice. They have no hope learning ML or functional programming. Typesafe languages are viewed by senior technical leadership as cute academic stuff with absolutely no practical purpose.
At this point, I'll probably join a startup just to get away from charlatans.
One extreme is the overuse of layers and abstractions wrapped around abstractions, which makes for nice diagrams that make it look like you worked hard. The other extreme that I see are the self taught low level programmers who didn't get a lot of mentoring along the way, that don't see what's wrong sharing globals across all the files. I have to explain the basics of simple abstraction to a 50 year old programmer who should know better, who complains that it's stupid to put split code into layers or modules because it's easier to understand if it was in one big file.
I want something in the middle, ability to think at a low level and get stuff done efficiently but also able to use the obvious abstractions that makes code easy to change and adapt in the future.
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.
I want something in the middle, ability to think at a low level and get stuff done efficiently but also able to use the obvious abstractions that makes code easy to change and adapt in the future.
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
You're right though, just the right mix of layering and abstraction with practical code getting the work done, nicely cut up in parts by general function, and code written in response to an emerged need for it, not the "we'll write it just in case because the logic of the framework demands it" fluff code. It's one of those things I've been thinking off and on again about for years, because, well, it interests me. I can just feel there should be a logic to it, but how to express it?
And no, a "methodology" is just about guaranteed to not be the right vehicle to express it, though it might be the usual vehicle attempted.
Me, I could do damn near everything from laying cables to running the sysadmin shop, likewise programming from assembler to quite on high (though not GUI, never GUI), but I don't have a job and I probably never will again. If I didn't get rejected for the big large gaps in employment from a burn-out 12 years ago, I'd still get rejected with fibs, as a wide skillset also tends to not imply that "smell of success" that is the only thing most "tech" recruiters know how to select on. And then there's the government requiring me to have paperwork it refuses to issue me when asked though by rights they cannot refuse me. None of that ought to be my core business, yet perforce battling idiocy for no pay is all there is for me. This is about the worst possible jobmatch for me, and it shows. Thanks, recruiters, thanks, officials.
These are but a few of the reasons, and minor ones at that (the major ones don't deal with me specifically, TYVM) that I think we need better people selection.
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
As a technical lead, this phenomenon has been a source of great frustration in getting candidates. I'm only allowed to even know about a prospective candidate after 2 or three layers of non-technical folks have "helped" me by making an assessment of the candidate's technical chops. Similarly they "help" in the requirements by padding things out so that a candidate will have everything needed to "hit the ground running", because of course there would be no ramp up needed if they *just* have the right resume...
No recognition that there is always going to be a ramp up period, that you want flexibility more so than existing directly relevant experience.
XML is like violence. If it doesn't solve the problem, use more.
What the fuck is Rust? Never heard.
Rust is a relatively new programming language.
I looked into using it a little while ago. On the surface it sounded appealing. It sounded like it would give me a lot of what C++ offers, but without some of the headaches that C++ suffers from.
To keep a long story short, Rust, as a language, did not meet my expectations. The syntax is C-like, but it's also quirky in some ways. The performance was mediocre. The borrow-checking approach to memory management is a pain in the bottom in practice, even after you understand it and have worked with it. There was only one compiler implementation, and I found it to be buggy and slow, even compared to a slow C++ compiler like GCC. The standard library was pretty bad, and the string handling was atrocious. Third-party libraries often didn't compile, and many were woefully incomplete. It was a really bad experience.
But the worst part, in my opinion, was the Rust community. I've dealt with a lot of programming language communities over the decades, but Rust's was by far the worst I've ever experienced.
The whole Rust Code of Conduct thing is kind of weird. I mean, programming language communities got along just fine without codes of conduct for ages. At first I though it was just a symbolic thing, but I soon realized that the Rust Code of Conduct was much more than that. I'd classify it more as a religious text, or even a behavioral script. It was like the Rust community worshiped it. In my experience it turned what should have been friendly discussion among collaborating colleagues into a highly controlled, flow-chart-like, courtroom-like, overly-formal, totally-artificial, robotic-like ritual. You literally had to walk on eggshells the whole time, out of fear of accidentally violating the Rust Code of Conduct in some obscure and non-obvious way.
The Rust Code of Conduct itself is contradictory. For example, there's a paragraph that says, "we don’t tolerate behavior that excludes people", yet that same paragraph starts with, "We will exclude you from interaction if ...". They basically would be violating their own Rust Code of Conduct when they try to uphold it!
I later found out that they even have a Rust Moderation Team that goes around and enforces the Rust Code of Conduct! I can't think of any other programming language community that I've dealt with that has a formally organized hit squad whose sole purpose is to take out community members who are deemed to be "undesirable". It's absurd. It's really, really absurd.
Something else I found disturbing was the extreme leftism that permeated the community. Now I don't think that programming and politics really need to mix much. They're pretty separate, for the most part. But in my experience the Rust community was very heavily into promoting "diversity" and "tolerance" and all of those other left-wing buzzwords, even when they really had nothing to do with programming. It's like they're more focused on "social justice" than they are on creating a usable programming language.
Another thing that bothered me was the smugness I kept encountering from Rust's contributors and supporters. They kept portraying Rust as being this great savior, when in my opinion it's rather mediocre, and actually has some pretty serious flaws and problems. If you questioned these Rust supporters, they would basically belittle and insult you, assuming they didn't try to censor you through down-modding or banning, if the discussion venue supported such things. I found it strange how they often ridiculed C++, yet when it came to the same functionality or features Rust was often much worse than C++.
I've been programming for a long time, and I've used a lot of different programming languages, but my experience with Rust was perhaps the worst I've ever experienced. No programming languag
Graydon Hoare sounds like the SIGSEGVs he got from his crappy C++ code triggered him.
Then, in classic SJW form, he completely overreacted. And keeping with the SJW "thought" process, it wasn't his fault: a bad workman always blames his tools...
Rust is the intersectional racist victim-mongering language - we are all victims of RAAAACIST C and C++ - languages that allow you to think for yourself - and therefore you are responsible for your code.
Rust is the perfect SJW language - it tells you how to think and absolves you of any personal responsibility for your code.
He's a hardcore SJW, then employed by a hardcore social justice company that's still the major sponsor of the language, so the answer pretty much has to be "yes".
I am a consulting real-time systems engineer.
I created the paging and hand-off algorithms which made it possible for cell phones to receive phone calls anywhere and to keep them while moving.
I created the integrated on-line inventory accounting system for McDonalds.
I created the software used by major refineries to make gasoline and distillate from crude oil.
I created software that runs steel mills.
My programs had to work properly, or people died.
I used ANSI C for my work. I created libaries to handle I/O and Memory Management including Garbage Collection.
I mostly worked alone, often with a small team of 6 - 12, and toward the end with 97 at McDonalds and 45 at Home Shopping Network.
By the end of my career, I designed systems using a CASE tool set, then pushed the button and the tool generated the code.
Rust, like C++ and C#, is an academic's desire to get tenure via publications in journals. It, like the others, is a memory hog, snd over hyped.
The problem with C is it will let you do anything the machine is capable of. good, bad, or ugly. It is up to the engineer to specify the desired functionality.
The Functional Specification............
To specify the program architecture.......... The Architectural Specification....
To specify test conditions, and success criteria.. The Test Specification
To specify transformations performed by each and every routine.......... The Detailed Design Specification
To specify data architecture...... The Database Specification
To specify data definitions and constants........... The Header Files...............
Then to write the code in conformance with the above.
It matters not whether you are using COBOL, PL1, ALGOL, BASIC, FORTRAN, ASM, C, C++, C#, JAVA, or RUST.
The professional engineer, thinks, specifys, writes, and tests..... in that order.
INDY