[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.
(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
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.
compiling...
(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
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.
compiling...
(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
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.
compiling...
(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
type safety that bugs me...able 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.
compiling...