Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

Programming in Rust is Fun - But Challenging, Finds Annual Community Survey (rust-lang.org) 58

Respondents to the annual survey of the Rust community reported an uptick in weekly usage and challenges, writes InfoWorld: Among those surveyed who are using Rust, 81% were using the language on at least a weekly basis, compared to 72% in last year's survey. Of all Rust users, 75% said they are able to write production-ready code but 27% said it was at times a struggle to write useful, production-ready code.... While the survey pointed toward a growing, healthy community of "Rustaceans," it also found challenges. In particular, Rust users would like to see improvements in compile times, disk usage, debugging, and GUI development...

- For those who adopted Rust at work, 83% found it "challenging." But it was unclear how much of this was a Rust-specific issue or general challenges posed by adopting a new language. During adoption, only 13% of respondents believed the language was slowing their team down while 82% believed Rust helped their teams achieve their goals.

- Of the respondents using Rust, 59% use it at least occasionally at work and 23% use it for the majority of their coding. Last year, only 42% used Rust at work.

From the survey's results: After adoption, the costs seem to be justified: only 1% of respondents did not find the challenge worth it while 79% said it definitely was. When asked if their teams were likely to use Rust again in the future, 90% agreed. Finally, of respondents using Rust at work, 89% of respondents said their teams found it fun and enjoyable to program.

As for why respondents are using Rust at work, the top answer was that it allowed users "to build relatively correct and bug free software" with 96% of respondents agreeing with that statement. After correctness, performance (92%) was the next most popular choice. 89% of respondents agreed that they picked Rust at work because of Rust's much-discussed security properties.

Overall, Rust seems to be a language ready for the challenges of production, with only 3% of respondents saying that Rust was a "risky" choice for production use.

Thanks to Slashdot reader joshuark for submitting the story...
This discussion has been archived. No new comments can be posted.

Programming in Rust is Fun - But Challenging, Finds Annual Community Survey

Comments Filter:
  • by flightmaker ( 1844046 ) on Saturday February 26, 2022 @06:53PM (#62307249)

    Can somebody please explain why on my Linux Mint laptop the source code:-
    fn main() {
            println!("Hello World!");
            println!("I'm a Rustacean!");
    }

    with compiled with
    rustc hello.rs

    turns into an 11MB file?
    $ ls -l
    total 10720
    -rwxrwxr-x 1 dave dave 10955904 Feb 26 23:44 hello
    -rw-rw-r-- 1 dave dave 609 Jun 19 2021 hello.rs

    A sensible executable size might encourage me to go beyond Hello World.

    • I was reading Rust performance blogs recently... and they indicated that, by default, Rust compiles in debugging mode.

      try passing `--release` to rustc and see if you get something better.

      • The 0-th order reduction you get it compiling with --release. And IMHO it's a very sensible choice to compile with debugging information (which is much bigger in size than C's debbuging symbols but much more useful), after all most compiles are for testing software. However if you are really obsessed with (or in need of) exec size, here are several levels of complexity to achieve ever smaller executables: https://lifthrasiir.github.io/... [github.io]. Bare in mind that a blog post from 7 years ago is considerably dat
      • And a lot of things are statically linked in, and I think uses its own memory allocator. Whereas a simple C program dynamically links to libc.so.

    • I haven't programmed in Rust besides some hours doing some tutorial. But from what I've read, Rust binaries are always somewhat larger than their C counterparts. However, with considerable effort, you can make a hello world program a few KB in size. If you are wanting to learn the language, I'd recommend against focusing on exec size until it matters though.
      • by DrXym ( 126579 )
        Not really. Rustc uses the same backend as Clang and generated code size is about equivalent. Where you might see a difference is that Rust will default to statically link to its std lib so the binary may be larger than in C where it might dynamically link to the system clib. There is a prefer-dynamic flag to ask Rust to prefer a dynamic std if there is one but it's not the default. You could also say nostd and just call the C lib (e.g. for some printf) if you had little reason to pull in std. Embedded Rust
    • by Dwedit ( 232252 )

      If you want a sensible execution size, try Zig instead. On Windows, Zig can build really tiny executables that don't even bundle in any of the CRT, so Hello World is literally getting the file handle for stdout, then outputting a text string to that file handle, and there's absolutely no other code at all in your binary.

      • Zig dynamically links and is catered to that environment. If compiled static Zig would be like 4 times larger.

        • It's amazing that "programmers" now don't even know how compilers work, and think that languages, by virtue of being new, can somehow magically get better.
          • Well, Oberon was like that. It made the existing things smaller even when linked. Probably it was intentionally *made* to be smaller, I guess. Few people actually care about that nowadays, though.
        • Wait, what? From what I understand, Zig even doesn't support dynamic linking at the moment; its standard library is kept as source all the way until you actually build your binary, and then pieces of that library code are compiled into your binary "on-demand". If I compile the canonical "Hello, World!" program with Zig and "-O ReleaseSmall --strip", I get a 4624-bytes-sized binary on which ldd reports "not a dynamic executable". So what exactly are you talking about here?
    • by dremon ( 735466 ) on Sunday February 27, 2022 @02:13AM (#62307939)
      rustc -C strip=symbols -C prefer-dynamic hello.rs
      ls -la hello
      -rwxr-xr-x 1 user user 14504 feb 27 08:11 hello
      • That didn't work for me but gave me a clue to start looking, thank you:-
        $ rustc -C prefer-dynamic=yes hello.rs
        $ ls -l
        total 40
        -rwxrwxr-x 1 dave dave 18536 Feb 27 08:42 hello
        -rw-rw-r-- 1 dave dave 609 Jun 19 2021 hello.rs

        debuginfo appears to default to 0

    • by DrXym ( 126579 )
      Because it builds with debug / symbol info by default. Build the release version and strip it like you would for C++.
    • by nasch ( 598556 )

      Rather than being concerned about how big hello world is, I'd look for information on how big real programs are. It seems likely that there's a lot of overhead, and once that is accounted for the size is probably fine.

  • Fuck off (Score:5, Insightful)

    by backslashdot ( 95548 ) on Saturday February 26, 2022 @06:54PM (#62307253)

    I do not need challenging if I am trying to get some work done or goal accomplished. Fuck off and get me the path from A to B.

    • I do not need challenging if I am trying to get some work done or goal accomplished. Fuck off and get me the path from A to B.

      If you don't need the speed of Rust, C or C++, there are plenty of languages that are much less challenging.

      If you do need the speed, all three languages are very challenging, but only Rust makes that fact obvious up front.

      With the other two, you may be blissfully unaware of the challenges until your code is awarded its very own CVE number.

      • Re:Fuck off (Score:4, Insightful)

        by DamnOregonian ( 963763 ) on Sunday February 27, 2022 @02:49AM (#62307973)
        But with the Rust, you may be lulled into a false sense of security. [github.com], while you learn how unsafe C is within the first hour of using it (though not the extent, of course)

        Note, I have no beef with Rust. Cool language. Cool idea. I dig it.
        However, I am a veteran C programmer who has worked in kernel space most of my adult life, and know all too well that you can write vulnerable code in any language.
      • Almost all the programs I write are very simple and IO bound. Any performance improvements to be had come from reading about how the filesystem work or how some network protocol works. When I google for information on those things most of what I find is C-centric. Translating them to rust would of course work but seems a little gratuitous. Maybe that will change if more drivers get written in rust

        I also recently tried out elixir for doing a little data translation, I loved it. But then I had to show someon

    • Re:Fuck off (Score:4, Informative)

      by ljw1004 ( 764174 ) on Sunday February 27, 2022 @02:31AM (#62307957)

      I do not need challenging if I am trying to get some work done or goal accomplished. Fuck off and get me the path from A to B.

      If it was worth you going from A to B in the first place, then your successor (either you, or someone else at your workplace, or someone else in the community) will inevitably want to take it to C and D. If you're writing code for a job or because you care about community, you'll want to write your B in a way that will support that future. How? ...

      (1) Static typing. If you write your B in Python or Javascript, it'll just be too hard for future maintainers or developers to extend it safely. That's why you pick C or Java or Typescript. I read this blog which put the case very well: https://www.teamten.com/lawren... [teamten.com].

      Basically, you're putting the up-front extra investment to design a type system that reflects the structure of your problem+solution, because it will pay off in future.

      (2) Memory lifetimes. Do you ever read software development post-mortems at gamasutra? The successful projects usually say something along the lines "We started with base classes that track memory and worked from there", and the failed projects often say "we never got on top of memory bugs". Every successful projects has to deal with memory safety. Sometimes it's done with thousands of very smart eyes looking at the code and living with the inevitable memory-related CVEs (e.g. operating systems in C/C++). Usually it's done in a garbage-collected memory-safe language (Java/C#/Python, or your own framework for memory safety like in successful C/C++ games). If your code is simple enough then it can be done just with RAII in C++ or other languages. Rust provides a novel option in this space -- it gives you more sophisticated control than RAII since it works great with multithreading+immutability, and it lets you do it with zero runtime overhead.

      In all successful projects, you have to make an up-front decision: either you bind your successors to live with the inefficiencies of a managed language, or if you're a top notch developer you can lay down a runtime memory-managing framework for your project, or you can do something like Rust where the compiler forces you and all your successors pay the cost of thinking before they code about memory safety.

      Personally I reckon the inefficiencies of managed languages are small enough that they're the best choice for almost everyone. (For my team at work, we picked Rust because our business needs are performance and code quality. For my hobby one-off projects I don't care about the community and pick javascript or python).

      • BASIC was fun but it would be challenging to write a driver with it.

        • Data structures were challenging in BASIC, depending on the dialect. For drivers many of the dialects had hooks to call into assembler routines. Such as the USR function and CALL statement in GW-BASIC. While very limited they were usually enough to do the low-level business needed by a small program, game, or driver-like utility.

  • by splutty ( 43475 ) on Saturday February 26, 2022 @07:03PM (#62307271)

    Seems we get an article at least once a week extolling the virtues (real and imagined) of the Rust programming language.

    How.. Nice!

    • The marketing is strong in that one.

    • "Rust seems to be a language ready for the challenges of production, with only 3% of respondents saying that Rust was a "risky" choice for production use." It's correct in its correctness of correctitude. Wink! They say it. The more you know.

      And no pan or messy oven to clean up!

    • by PPH ( 736903 )

      We are looking forward to a workable "Hello World" implementation any day now.

    • by Shemmie ( 909181 )

      Please mod up. Slashdot comments are generally pretty dead these days (front page articles 70 unless COVID, Russia or culture wars).

  • by StormReaver ( 59959 ) on Saturday February 26, 2022 @07:40PM (#62307371)

    The survey was among the Rust faithful, so I'm taking the results with a block of salt.

    • Re:Biased (Score:5, Funny)

      by splutty ( 43475 ) on Saturday February 26, 2022 @07:43PM (#62307379)

      Painting your car is fun, found a survey among people from the Car Painters Association.

    • by DrXym ( 126579 )
      The rust "faithful" include the likes of Microsoft, Amazon, Google et al. They all recognize that it produces better quality & safer code than the same in C or C++, whether you're some programming guru in those languages or not. And most progammers definitely fall into the not category.
      • In my 37 years of software development, I have found a pattern with new, "safe" languages. They claim to have solved the issues with the "unsafe" languages, and do so by disallowing the "unsafe" practices. It turns out, though, that the "unsafe" practices exist for necessary reasons, and disallowing them results in certain needed features being impossible to implement safely. As a compromise, the "safe" language allows "unsafe" practices as an isolated exception.

        As time goes on, the isolated exception turns

        • by DrXym ( 126579 )
          If you want to program unsafely in Rust you enclose a section of code in an "unsafe" block. Then the compiler will let you do any crazy shit you like, presumably after you've had a think if this is a good idea or not. Even if you do have a couple of lines marked unsafe it means the vast majority of the code is safe by default and enforced as such.

          This is stark contrast to C or C++ where EVERYTHING is unsafe.

          It is also horseshit to say that Rust somehow encourages bad resource management. Quite the oppos

        • In a normal business application, no one needs anything unsafe.

          With your 37 years of experience you should know that.

          The only two things were something unsafe is useful are kernels and embedded software, and in the later case that should be not more than a few handful lines of code. (And that can usually be done with a library close to the VM in in any safe language anyway)

          No idea, why programmers - especially self proclaimed old school - claim languages need unsafe features. Since 1995 I mostly program in

    • by kackle ( 910159 )

      so I'm taking the results with a block of salt.

      That'll get you some rust, for sure!

  • by Anonymous Coward
    People can write semantically incorrect code in any language and no amount of hand-holding by the language will prevent that. e.g.: Rust might help with memory allocation and static index checking but will it stop programmers from storing a using plaintext passwords in a database? From constructing database queries from string parts that include user-supplied (tainted) data instead of forcing parameterized queries? From stupidly common race conditions like selecting the maximum ID in a table and then insert
    • So just because it canâ(TM)t solve everything it shouldnâ(TM)t even try to solve some things? Your argument is nonsensical.
    • by DrXym ( 126579 )
      That's right and Rust doesn't claim any different. If your logic is supposed to close the door when the button is pushed but it does the opposite, it will not help you. However it will help you from having two threads trying to close the door simultaneously, or accidentally calling code to close the door when you have no door.
  • Sucks (Score:5, Interesting)

    by AcidFnTonic ( 791034 ) on Saturday February 26, 2022 @10:05PM (#62307599) Homepage

    My experience with Rust ended before it started. Basic system updates eventually left me with cargo errors, multiple versions, and an absolute broken mess trying to fix it.

    I'm a C++ developer using Gentoo in order to specifically control every Library version to keep ABI sane for binary commercial software delivery.

    Rust can't even exist in that basic ecosystem. The tool sucks. I'd rather attack the problem from an llvm compiler plugin and kung fu discipline to actually write readable C++20 code.

    But the hipsters can't write a bunch of cool articles about that anymore. So here we are.

    • by dremon ( 735466 )

      Basic system updates eventually left me with cargo errors, multiple versions, and an absolute broken mess trying to fix it.

      How is that a language issue and not a Gentoo one? Have you even tried to write something in Rust?

      I'm a C++ developer using Gentoo in order to specifically control every Library version to keep ABI sane for binary commercial software delivery.

      How is that related to the Rust language or relevant at all? What are you trying to say here, that Rust cannot be used to specifically contro

      • How is that a language issue and not a Gentoo one? Have you even tried to write something in Rust?

        I think maybe he's saying that the standard library for Rust is... fragile?
        Then again, as someone who has tried to keep up with the STL for a couple decades, I'm not sure I'd choose to throw those particular rocks in my glass house.

        How is that related to the Rust language or relevant at all? What are you trying to say here, that Rust cannot be used to specifically control every library version? What is library versioning has to do with Rust? It can use C ABI (if you really need stable ABI), you know that, right?

        Didn't get that at all from him. I think he was merely saying that it doesn't work in his workflow.

        Again, Rust doesn't stop you from doing just that. I am not sure what was the purpose of your pointless comment about Rust.

        Rust most certainly will prevent you from doing that ;)
        rustc will puke hard if given C++20 as input.

        I'm wondering if you were intentionally trying to misunderstand him. Why are

    • I am still trying to understand what you are complaining about. As far as I can see, you don't like Rust because the Cargo package for Gentoo didn't work when you tried it out?

      The version of library dependencies for Rust is fairly easy to control, although having Cargo makes this easier.

      I wonder whether part of the problem here is that you were expecting Rust and its tools to behave exactly the same as C++ and are not getting what you expected.

  • by 93 Escort Wagon ( 326346 ) on Saturday February 26, 2022 @10:17PM (#62307619)

    Rather than polling the rust community - I'd think you'd get more useful results by asking these questions of the bosses of those members of the rust community.

  • I've written code in 28 languages. Some are certainly more "fun" than others. For me, a "fun" language is one that handles the drudgery of building the nuts and bolts of software. For example, I don't want to write code to transform UTF8 to ASCII, and I don't want to have to do my own date calculations or build my own Zip or JSON file reader.

    So, for those of you who have used Rust, what makes Rust fun?

  • by dltaylor ( 7510 ) on Sunday February 27, 2022 @12:44PM (#62309073)

    Useful as rust may be for some things, the claim that rust is "better" because it allows "'allowed users "to build relatively correct and bug free software"'" is just silly. People that know what they are doing can accomplish the same thing in "C", while those who do not, can write crap code in any language.

  • Why is Rust better than everything that is currently out there? Like C, C++, C#, Java, Python etc. Creating a new programming language is not hard, anyone can do it with little effort. The usefulness of a programming language is not it's syntax or even it's features, but what libraries are available, the hardware platform support and IDE support. What good is a programming language if you have to write every single line of code from scratch? It may be fun for simple pet projects, but for any real life produ

Each new user of a new system uncovers a new class of bugs. -- Kernighan

Working...