Slash Boxes

SoylentNews is people

posted by cmn32480 on Monday June 27 2016, @01:13PM   Printer-friendly
from the get-the-sand-blaster dept.

[Ed. Note: The first link seems to have been pulled from the web after this story was accepted. We apologize that we have been unable to find a link to replace it.]

Arthur T Knackerbracket has found the following story about the progress of the Rust programming language and its growing usage:

"The Results are in! Thank you to all 3103 of you who responded to our first Rust community survey. We were overwhelmed by your responses, and as we read your comments we were struck by the amount of time and thought you put into them. It's feedback like this that will help us focus our energy and make sure Rust continues to grow the best way. A big reason for having the survey was to make the results available publically so that we can talk about it and learn from it together. In this blog post, we'll take a first look at the survey responses, including themes in the comments, demographics, and quantitative feedback.

Do You Use Rust?

We wanted to make sure the survey was open to both users of Rust as well as people who didn't use Rust. Rust users help us get a sense of how the current language and tools are working and where we need to improve. Rust non-users give us another perspective, and help shed light on the kinds of things that get in the way of someone using Rust. I'm happy to report that more than a third of the responses were from people not using Rust. This gave us a lot of great feedback on those roadblocks, which we'll talk about in this (and upcoming) blog posts.

But first, let's look into the feedback from Rust users.

Rust Users

How long have you been using Rust?

Almost 2000 people responded saying they were Rust users. Of these, almost 24% were new users. This is encouraging to see. We're still growing, and we're seeing more people playing with Rust now that could become long-term users. Equally encouraging is seeing that once someone has become a Rust user, they tend to stick around and continue using it. One might expect a sharp drop-off if users became quickly disenchanted and moved onto other technologies. Instead, we see the opposite. Users that come in and stay past their initial experiences tend to stay long-term, with a fairly even spread between 3 months to 12 months (when we first went 1.0).

There is much more to be found in the full story for Rust aficionados.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Touché) by VLM on Monday June 27 2016, @03:58PM

    by VLM (445) on Monday June 27 2016, @03:58PM (#366468) []

    My experience with this mindset:

    Sometimes, when writing certain kinds of libraries, you’ll need to get around Rust’s safety guarantees for some reason.

    Is if you permit programmers to write bad C in Rust you'll get people writing bad C in Rust and shooting themselves in the foot.

    Its a variation on the theme of everyone who actually codes (as opposed to manages) agrees gradual typing is a complete loss because people will only implement types where its very easy to implement and therefore bug free and not where its hard to figure out, slow to compile, and therefore right where its necessary to catch the most weird bugs. So if you want the benefits of types then use a typed language and if not then do not because the security blankie of gradual typing has a hold big enough to drive a truck thru (to march an army of bugs thru? Leinengen, is that your ants?)

    I also don't like that Rust is medium power. If you need high power for a very complicated thing just use Clojure and some libraries. If you are doing something low power then if its ultra low level like a micro controller go C or assembly, or if its a low level thing on an advanced system use a hundred lines of C or two lines of perl/CPAN. And in between, well, there isn't much but if there's something there then I guess put rust there.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Touché=1, Total=2
    Extra 'Touché' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Interesting) by The Mighty Buzzard on Monday June 27 2016, @05:05PM

    Eh, you see an assembly window, a huge C window, a huge high-level-language-of-choice window, and possibly a narrow Rust window in between the last two. I see Rust taking most of C's window and a bit of the high-level language window.

    Here's my reasoning... If you don't need to do inline assembly (not from a library) or explicitly tell something it should stay in a register rather than getting pulled from ram, there're very few valid reasons not to use Rust instead of C. So, yeah, I could see Rust being ill suited for video encoding or other speed-critical applications but for anything where being dangerous-bug-resistant is more important than speed-at-any-cost, C is likely to end up being a foolish choice once Rust is a bit more mature. But pretty much every single executable that runs with root privileges that is currently written in C, for instance, should eventually be either ported to something more shoot-yourself-in-the-foot-resistant or undergo formal verification.

    Yeah, I know good C coders can write a program in C without making noob-assed errors. I also know that given a large enough codebase or long enough time spent on a project, they're will make them anyway.

    My rights don't end where your fear begins.
    • (Score: 2) by RamiK on Monday June 27 2016, @11:09PM

      by RamiK (1813) on Monday June 27 2016, @11:09PM (#366666)

      It's not about what C has, it's about what it doesn't have. C doesn't have object-orientation, generics and lambda-calculus that get in the way of electrical engineers who write kernel drivers. When a physicist, statistician or even sys-admins pick up a binding library that interacts with C in their interpreted language-of-choice, they don't need to invest more then a few minutes to figure-out how it all works.

      Overall, Rust is too cumbersome for plumbing and too low-level for casual user-land work. I think Rust could challenge C++, Java and D. But it's no substitute for C in the systems-language space.

      • (Score: 2) by The Mighty Buzzard on Monday June 27 2016, @11:42PM

        Teach EEs to write code with guaranteed zero overflows and I'll totally agree with you. Otherwise they need to be banned from using C. Leave that to the people who at least in theory know what they should never be doing.

        My rights don't end where your fear begins.
        • (Score: 2) by RamiK on Tuesday June 28 2016, @01:28AM

          by RamiK (1813) on Tuesday June 28 2016, @01:28AM (#366734)

          But EEs aren't going away anywhere. They're the people who write drivers since they're the people who design the hardware. At the very least, they're going to be documenting, debugging, maintaining and reviewing the code as part of a team. So, you have to accommodate for their inability to acquire and use advance language features.

          • (Score: 2) by The Mighty Buzzard on Tuesday June 28 2016, @02:14AM

            Oh nobody's saying they have to use them. Just teach them to grok memory ownership and borrowing and they'll be able to write secure code in Rust just fine. Doesn't have to be Rust even. Pick any language that forces you to jump through special hoops to write buggy code and is nearly as close to the metal as C. Just do not let someone who can't explain how to overwrite the next instruction on the stack, and prevent such in their own code, play with C.

            My rights don't end where your fear begins.
            • (Score: 2) by RamiK on Tuesday June 28 2016, @09:26AM

              by RamiK (1813) on Tuesday June 28 2016, @09:26AM (#366961)

              Well, I can tell you right away that C won't be substituted just for the sake of type safety. Otherwise, I would be procrastination working on a pascal driver instead of a C driver right now... :D

              At the same time, I can also tell you that deviating from that high-school math function syntax towards lambda calculus and generics is simply asking too much from none-CS scientists and engineers. They're just too preoccupied with their own field to be able to learn anything but the basics of structured programming.

              I guess Go could fit the bill. It's a very easy and small language that, at least in theory, can be used for safe system-programming. But it will still need a huge corporate push.

              • (Score: 2) by The Mighty Buzzard on Tuesday June 28 2016, @10:00AM

                Yeah, it's not really type safety that bugs me, though I suppose that's important as well. It's being able to easily, hell with gusto, stuff user input past the end of an array and start overwriting memory the programmer didn't intend to be user editable. Or any form of race condition that can achieve similar pwnage. Rust prevents all three out of the box unless you specifically mark a block of code using the "unsafe" keyword. Even EEs should pause long enough after having to type that to think "is doing it this way wise?"

                As for the math? I'm not sure why you think math in Rust has to be done that way; I haven't been doing anything but highschool level math that looks exactly like highschool level math, except for dealing with bitmasks which looks pretty much exactly like dealing with bitmasks in C. Occasionally I've had to cast a signed int to an unsigned but that hardly makes highschool math into lambda calculus.

                My rights don't end where your fear begins.
                • (Score: 2) by RamiK on Tuesday June 28 2016, @11:53AM

                  by RamiK (1813) on Tuesday June 28 2016, @11:53AM (#366997)

                  type safety that bugs to easily, hell with gusto, stuff user input past the end of an array

                  That's all under the type safety umbrella implementation wise. When you check for bounds, your types are safe. When they're safe, you can't overflow them.

                  Regarding the math, I wasn't talking about actual math. I was talking about math-like syntax. Declarative vs procedural. Monads, closures and generics. Object orientation and functional programming... All those fancy advance topics that take a couple of extra courses the none-CS never pick up.

                  Another point-of-view worth mentioning: The reason we have all these new safe languages is thanks to the advances in precise, embedded and real-time garbage collectors. Alone, Pascal style checking bounds just for safety isn't worth it. But if you're also keeping track of heap and freeing memory automatically and without pauses like Java, Go and Rust do, it suddenly make sense to have everything type-safe and garbage collected.