Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming Software

Rust Creator Graydon Hoare Says Current Software Development Practices Terrify Him (twitter.com) 353

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."

Rust Creator Graydon Hoare Says Current Software Development Practices Terrify Him

Comments Filter:
  • by Anonymous Coward on Sunday February 04, 2018 @12:39AM (#56064665)

    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.

    • by WarJolt ( 990309 ) on Sunday February 04, 2018 @12:50AM (#56064681)

      ML means Meta Language

    • Not being a programmer, I thought it meant 'markup language'. I think they should come up next with RustML, a safe alternative to XML.
  • Terror (Score:4, Insightful)

    by Anonymous Coward on Sunday February 04, 2018 @12:55AM (#56064701)

    Well, his zombified hoarde of brainwashed language fanbois terrifies me, so I guess we're even.

    • by Anonymous Coward

      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... [wiktionary.org]

      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

  • Facepalm. (Score:5, Informative)

    by Gravis Zero ( 934156 ) on Sunday February 04, 2018 @12:56AM (#56064707)

    The summary say "machine learning" but if you read this feed you'll see it's "ML". ML is programming language. [wikipedia.org]

    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.

  • by kfsone ( 63008 ) on Sunday February 04, 2018 @01:02AM (#56064713) Homepage

    ... making the difference between "return the evaluation of this expression" vs "don't" is such an improvement in software development practices.

    Rust is interesting, the way that that wreck on the 101 is "interesting".

    • ... making the difference between "return the evaluation of this expression" vs "don't" is such an improvement in software development practices.

      Really? You think that's all there is to Rust?

      I love how people here love to diss stuff from a position of utter ignorance.

      • by Megol ( 3135005 )

        Maybe the ignorance is on your side? Because kfsone didn't claim that was the _only_ problem he(?) have with the language...

        So instead of thinking and replying you react.

      • So how much time did you waste going deeper? Joke's on you, AmiMoJo.

  • by Anonymous Coward on Sunday February 04, 2018 @03:31AM (#56064897)

    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 [github.com], 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.

  • by CustomSolvers2 ( 4118921 ) on Sunday February 04, 2018 @03:59AM (#56064935) Homepage
    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.
    • Re: (Score:3, Interesting)

      by Viol8 ( 599362 )

      "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 don't know rust so I can't comment on it directly, but I'm a C++ dev and a lot of that applies to C++ which - it pains me to say - has become a designed-by-commitee dogs dinner with some appalling, borderline unreadable, syntatic hacks and yet they still just can't

      • I don't know rust so I can't comment on it directly, but I'm a C++ dev and a lot of that applies to C++

        Rust is certainly worse. C++ is a difficult-to-master language, not a difficult-to-get-started one. C is much more difficult to get started than C++, at least for someone with a modern-language background. But even with C, you have options which are a bit less problematic on which newbies might rely at least to perform the relatively simple development I did (just a simple application calling an external program and parsing the simplistic output which it generates). The four languages I mentioned might be q

      • by serviscope_minor ( 664417 ) on Sunday February 04, 2018 @06:28AM (#56065139) Journal

        I first learnt C++ 2 decades ago and even I have given up trying to keep up with the latest pointless additions to the language that no one outside a small circle of language geeks was asking for.

        I'm having a hard job thinking what those are.

        Just about every new addition to C++11 saved major ball-ache at many points in the code, even the somewhat botched initializer_list.

        C++14 basically fixed all the weird "WTF this doesn't work" bits from C++11 where the features weren't quite complete in obvious ways (e.g. auto lambdas, return type deduction for normal functions and so on).

        Except for binary literals and digit separators. Those were new. and holy-o-fuck are those useful if you're hammering on an SPI bus.

        I feel sorry for anyone trying to learn it from scratch today as the learning curve eventually gets as close to vertical as you can get in a programming language.

        It's vertical if you try to learn modern C++ as 20 year old C++ with extra features. That's not the optimal way to learn it, because then you're stuck with all the misdesigns of the old features with a whole pile of new ones. It's the way we learned it of course, because we learned C++ then C++98 then C++11.

        It's bad in the same way that it's bad learning C++98 as C with a bunch of new features. You get the worst combination of complexity overload and feature overload. Again we did it, but I wouldn't teach someone new that way.

        Stroustrup has a book on learning modern C++, and it's very well written and makes the curve much gentler.

        I very much doubt you need it to learn C++, but I think it's a good read if you're in the position of teaching or mentoring since it sheds a whole new light on how it comes together for new programmers.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          I have to agree with the earlier post about so much being added to C++ and how much of it is useful. When looking over my C++ code what I see repeatedly is that I've never needed much more than C with Classes.

          The RAII capability, operator and method overloading and basic container classes seem to provide all of functionality I generally use. I more often prefer object orientation using composition to inheritance so I do make use of interface design. But I'm fine with very basic template usage for things

        • During the summer I wrote a game in C++11, about 70K lines of code, and one thing I noticed was holy cow how many fewer crashes I had than with the usual non-RAII C/C++98 code. It was less maybe a handful surprising access violations. It could be partly to the VS 2017 IDE, but it can't explain it all. Some things were hard to get right, but they were mostly hard to compile right. And once I got there I was floored by the cleanliness and robustness of it all. Empty destructors, no need for matching closing A

      • by DrXym ( 126579 )
        C++ has been moving in the same direction as Rust towards safer programming but thanks to the need to be backwards compatible, it is still unsafe by default and using some of these new features is very clumsy and verbose. e.g. if you want to do move semantics in C++ you have to add weird && constructors and if you thought the rule-of-3 was bad, wait until you see the rule-of-5. Stuff like implicit keywords and deleted constructors just adds to the mess.

        And even if you do make use of the new featur

      • All the newest additions makes things more readable. Variadic templates are much easier (and faster) to use than the old hacky way of having dummy parameters. constexpr if is much better than using the SFINAE trick or #defines. lambdas are a godsend for using algorithms, or for callbacks or dependency injection. And auto is much better than having to remember the exact type of an object.

        These aren't the stuff of language geeks. Beginner C++ programmers find that stuff more easier.

        The problem is you. I
    • by DrXym ( 126579 ) on Sunday February 04, 2018 @06:19AM (#56065137)
      Rust definitely needs better IDE integration but you can find plugins that work for VS Code, Atom, IntelliJ/Clion, Eclipse, Dev Studio. The IntelliJ plugin in particular is excellent but VS Code's is good too. Seriously I could write code all day in IntelliJ and it has all the niceities you would expect from a plugin - refactoring, code cleanup, reformatting, find usages, inspection, code completion etc.

      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.

      • Thanks for the info regarding editors and debugging (BTW, I used VSC without the plugin, by debugging directly via compiler and generated warnings/errors; in case of having decided to use a proper IDE, I would have most likely chosen Eclipse or Visual Studio), but I don't agree with most of what you say. I usually rely on other languages, but eventually use C/C++ and have no problem with them (unlikely with Rust).
    • Currently Rust has set a priority to make the language more approachable. It could be worse, it could be Haskell: even people who use it every day don't understand it.
      • Currently Rust has set a priority to make the language more approachable

        They definitively need to do that. I personally might not mind using it in the future in case quite a few things are improved. There are a relevant number of programming languages which had a very important evolution. I also understand that this is a brand new language and that any feedback, even negative, is helpful. The higher the number of good alternatives, the better for everyone.

      • Haskell and C++ are actually very similar languages with wildly different syntax and defaults.

  • by lucasnate1 ( 4682951 ) on Sunday February 04, 2018 @07:07AM (#56065191)

    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.

  • by geoskd ( 321194 ) on Sunday February 04, 2018 @01:15PM (#56066617)

    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.

Stinginess with privileges is kindness in disguise. -- Guide to VAX/VMS Security, Sep. 1984

Working...