Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Mozilla

Why Aren't More Developers Using Rust? (zdnet.com) 341

An anonymous reader quotes ZDNet: Rust has been voted the "most-loved" programming language by developers on Stack Overflow for four years in a row. But the Rust project now admits it has an adoption problem among developers and organizations. Rust's adoption issue surfaced in January's Stack Overflow's 2019 survey, which revealed that despite developers' positive feelings toward Rust, 97% of them hadn't actually used it.

Rust maintainers have now explored the adoption challenges in their latest annual survey of nearly 4,000 developers across the world...

Asked why developers have stopped using Rust, the most common response is that the respondent's company doesn't use it, suggesting an adoption issue. Other common reasons are the learning curve, a lack of necessary libraries, and a lack of integrated development environment (IDE) support. The top issues that respondents say the Rust project could do to improve adoption of the language are better training and documentation, followed by better libraries, IDE integration, and improved compile times... "Most indicated that Rust maturity — such as more libraries and complete learning resources and more mature production capabilities — would make Rust more appealing," the project noted....

"The results show the overriding problem hindering use of Rust is adoption. The learning curve continues to be a challenge — we appear to most need to improve our follow-through for intermediate users — but so are libraries and tooling."

The article also notes that Rust is popular with some developers at Microsoft, "who are experimenting with Rust to reduce memory-related bugs in Windows components written in C and C++."
This discussion has been archived. No new comments can be posted.

Why Aren't More Developers Using Rust?

Comments Filter:
  • Wait a second... (Score:5, Insightful)

    by SuperKendall ( 25149 ) on Sunday April 26, 2020 @10:41AM (#59992658)

    despite developers' positive feelings toward Rust, 97% of them hadn't actually used it.

    Who says they love something they have not used???

    I might say something seems decent, but no way would I say I *LOVE* a language until I've done a few real things in it.

    The top issues that respondents say the Rust project could do to improve adoption of the language are better training and documentation, followed by better libraries, IDE integration, and improved compile times...

    That is a pretty tall list of things that need advancement. Another problem seems to be just sheer lack of experts in Rust, look at the Rust tag [stackoverflow.com] on StackOverflow - A whole lot of questions with little upvoting, most with one to no answers. Honestly instead of focusing on further improving training and documentation, they should have a handful of top Rust devs just camp on StackOverflow questions and make sure all of them get answered well, in a timely manner. That may help people get some Rust stuff running enough to bring the language to popularity.

    • by PeeInButt4PregNancy ( 6802784 ) on Sunday April 26, 2020 @10:48AM (#59992686)
      You left out the part about not wanting to be in a project that spends more of its time debating what a man should call his vagina than working on actual work.
      • Hit the nail on the head.

      • Exactly.

        I want a goddamn compiler, not a moral judgement.

      • by nagora ( 177841 ) on Sunday April 26, 2020 @11:57AM (#59992952)

        You left out the part about not wanting to be in a project that spends more of its time debating what a man should call his vagina than working on actual work.

        "Wife". There you go - sorted!

      • by gweihir ( 88907 )

        Indeed. I will stay far away from any group that so clearly sails under a false flag.

      • You left out the part about not wanting to be in a project that spends more of its time debating what a man should call his vagina than working on actual work.

        Ahh the old "spending more time on X than work" reply.

      • There's nothing wrong with wanting to have good morals and values, but it makes no sense to me that you'd create a new language to replace time-tested, fully functioning languages on the basis that those languages get in the way of a developer's thought process, only to later tie-in a bunch of non-development related issues that get in the way of a developer's thought process.
    • by Octorian ( 14086 )

      despite developers' positive feelings toward Rust, 97% of them hadn't actually used it.

      Who says they love something they have not used???

      Somehow this reminds me of Ruby back in the day. Only back then, it was developers who only learned it the prior week being overly enthusiastic about it.

      But yeah, Rust seems to have a huge cheerleader squad on various tech sites, that's definitely out of proportion with people who actually use it. Most of the actual Rust-based projects I've run across so far, tend to be novel (and not drop-in) replacements for various command line utilities. I almost never actually use these after installing them, because o

      • Re:Wait a second... (Score:5, Informative)

        by Dutch Gun ( 899105 ) on Sunday April 26, 2020 @11:48AM (#59992914)

        I think in some ways, it's perhaps because people love the idea of Rust as much or more than the language itself. The concept is pretty compelling, really - a compiler/language that actively presents you from shooting yourself in the foot, which C++ allows you to do if you step outside of "voluntary best practices", and which C seems to gleefully encourage with the slightest misstep. And all this while still achieving the fantastic run-time efficiency of a natively compiled language. What's not to love? At least in concept...

        In practice, at least for my purposes, Rust is pretty much a non-starter. I'm in game development, where C++ rules with an iron fist. Ecosystem matters. C++ is available everywhere, from PCs to smartphones to consoles. So it just make sense to write your code in a language where you know that a supported compiler / dev environment will be available on every platform you can imagine, where you know there are good libraries and engines and examples and APIs in that same language. You can really only use Rust if you're willing to blaze a lot of new trails yourself, or are willing to accept some severe limitations in your potential deployment.

        • by gweihir ( 88907 ) on Sunday April 26, 2020 @12:11PM (#59992984)

          Indeed. Also, you can shoot yourself in the foot with Rust just as easily, it will just be harder to find the problem later on. The whole approach they selected to market this thing seems a recipe for failure though. If you water down engineering discussions with SJW-nonsense, they are not engineering discussions anymore. Also, basically most good engineers will stay far away from such a community.

          • Indeed. Also, you can shoot yourself in the foot with Rust just as easily, it will just be harder to find the problem later on.

            Citation needed.

            As a counterpoint, Microsoft released research that stated 70 percent of all security bugs are memory safety issues [zdnet.com], the same bugs that Rust is designed to prevent.

            • Why would you have to shoot yourself in the foot in one specific way?
            • Re:Wait a second... (Score:5, Interesting)

              by Darinbob ( 1142669 ) on Sunday April 26, 2020 @04:19PM (#59993822)

              70% of all bugs, or just 70% of Microsoft's bugs? Note that Microsoft seems to have lost a lot of it's technical peak, which was never that high a peak to start with. If you look at their products as an example it's clear they're not focusing on efficiency or spending time to plan out APIs for the long term.

          • Re:Wait a second... (Score:5, Informative)

            by ljw1004 ( 764174 ) on Sunday April 26, 2020 @01:58PM (#59993344)

            Indeed. Also, you can shoot yourself in the foot with Rust just as easily, it will just be harder to find the problem later on.

            That's incorrect.

            My team (20 developers) have been rewriting our team's project in Rust for the past year. Rust doesn't let you shoot yourself in the foot easily. You have to explicitly mark as "unsafe" the places that might shoot you in the foot, and there are generally few of these, and they all get very stringent code-reviews by the senior developers. The normal pattern is that the senior developer encapsulates the unsafe behavior behind a safe API, and they write down the internal invariants which prove that no foot-shootage will happen within the API, but the users of the API don't use the "unsafe" keyword and aren't able to shoot anyone's feet.

          • by Boronx ( 228853 )

            The only time I hear about Rust be full of SJWs are from slashdotters butthurt about a project trying to be inclusive of women. It never, ever comes up when normal people talk about Rust among themselves.

            The reason I and many other professional programmers do not use Rust is lack of libraries full stop

        • Re:Wait a second... (Score:5, Interesting)

          by lgw ( 121541 ) on Sunday April 26, 2020 @02:28PM (#59993460) Journal

          I think in some ways, it's perhaps because people love the idea of Rust as much or more than the language itself. The concept is pretty compelling, really - a compiler/language that actively presents you from shooting yourself in the foot, which C++ allows you to do if you step outside of "voluntary best practices", and which C seems to gleefully encourage with the slightest misstep.

          I think the key is, almost no one has come out of school in the past 10 years or so and gone into low-level programming. People get taught Java and web programming, and get jobs doing that. So most of the people who would actually be choosing between C, C++ or Rust for actual work have already spent a decade or two learning all the ins and out of C or C++. Those "voluntary best practices" are second nature. The days when the average development experience with C or C++ was less than 5 years was long past.

          So, Rust solves a problem that only exists in principle. If you're on a team with an average of say 15 years working in C++, all the gotchas and footguns of that language don't actually bother anyone any more. It's the devil you know.

        • Ecosystem matters.

          I don't choose my language, I choose my libraries.

      • by Brain-Fu ( 1274756 ) on Sunday April 26, 2020 @12:54PM (#59993158) Homepage Journal

        "There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup, creator of C++.

    • Who says they love something they have not used???

      Shills and fanboys.

      Both of which deserve a good solid punch in the teeth.

    • I don't see why anyone would "love" any programming language.

      I have looked at Rust and written some simple toy programs. But I don't use it for work.

      The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.

      So, with a huge code base of working C++, it doesn't make sense to switch. It would be yet-another-language that everyone we hire would need to know. We would be constantly swit

    • Asked why developers have stopped using Rust, the most common response is that the respondent's company doesn't use it, suggesting an adoption issue.

      Wow, that was a choice?

      Q: Why have you, Mr/Ms Developer, stopped using Rust?
      A: Because my company doesn't use it.

      Can we even assume that there company ever actually DID use Rust? It's implied in the question, but you never can tell.

  • by Freischutz ( 4776131 ) on Sunday April 26, 2020 @10:44AM (#59992668)

    Why Aren't More Developers Using Rust?

    Because every time one of them starts using it the other developers douse him in "Fluid Film Rust Stopper" [amazon.com] to keep it from spreading. I recommend the 6 spray can value pack.

  • by Gavino ( 560149 ) on Sunday April 26, 2020 @10:47AM (#59992680)
    Most software developers also say they love sex, even though 97% of them are still virgins
  • Other common reasons are the learning curve, a lack of necessary libraries, and a lack of integrated development environment (IDE) support.

    Yeah. I can see this on Stack Overflow [webdeveloper.com]. Everyone is sitting around waiting for someone else to write some Rust code and upload it.

    • Is there a new "Ooo... Shiny!" language that's come out. I've seen plenty of things get a lot of early hype and even have plenty of people check it out, but they never really attract the critical mass to sustain that and almost all of the people who were flocking to it have found something else to flock to instead. Rust seems like it will probably stick around and no doubt we'll even get a few useful and widely used applications out of it, but I think it's mainly going to be a smaller community of dedicated
    • by gweihir ( 88907 )

      Ah, so the copy&paste crowd is the fan-base. Figures.

  • ... news sites need to whip up nonsense news articles for views, either way the startup culture around many modern programming tools is pretty foolish all around. You use the right tool for the right job, the idea that anyone needs to start using "insert new fancy language here" just because it exists when other languages do the job just fine is quite a nonsense idea.

    Real innovation in languages takes decades of research, it's not some over night job. I'm sure there will be all sorts of future innovation

    • I agree with what you said, but here is additional opinion. Don't give a computer language a foolish name:

      Imagine going to a top manager and saying you want to program a product in Rust [rust-lang.org].
      RUST - Makes iron into useless red dust.
      RUST - Ridiculously Unable Social Tribe?
      RUST - Raunchily Unstable and Seriously Troubled?
      RUST - Rash Under Smelly Toes (Someone else's idea.)
  • ...with RUST adoption is "adoption"? Is that right?

  • It's still relatively new.

    Developers are not special snowflakes who are more adventurous than most other people and the language therefore follows the same Christensen adoption curve as any new technology. Rust has a high barrier to entry as C infrastructure is the most well-developed, ubiquitous computing environment available today. Unless Rust can demonstrate a very significant improvement over C in cost of development (something almost no proposed replacement language has ever provided), it will not be

    • Re:Why? (Score:5, Insightful)

      by Anonymous Brave Guy ( 457657 ) on Sunday April 26, 2020 @01:06PM (#59993194)

      Unless Rust can demonstrate a very significant improvement over C in cost of development (something almost no proposed replacement language has ever provided), it will not be adopted.

      I can easily believe that Rust could offer significant improvement over C: as a language, it is both safer and more powerful in practically relevant ways. However, as with any relatively young language, Rust itself is probably only a small piece of the puzzle. The rest of the ecosystem is also needed -- the libraries, the tools, the documentation, and most importantly, the developers.

      Kickstarting a new programming language ecosystem has been done several times in recent years, but the common factor in almost all of the success stories is that they've had at least one "killer application" where either they were so much better than the incumbents that everyone was interested in moving or they were the only game in town. I'm not sure what Rust's is, or could be.

      For embedded software, it's up against a huge base of highly specialised libraries and obscure hardware architectures, and everyone speaks C.

      For server software, it's up against several capable incumbents and Go has grabbed a significant amount of the "new language" mindshare by being almost too simple but therefore highly accessible, which is the polar opposite of Rust.

      For native applications, there are again capable incumbents with huge library support on every major platform.

      Systems software is somewhat similar to embedded in its status quo.

      For the crowd who value safety/security features particularly highly and are willing to explore more niche/experimental approaches to achieve them, Rust has garnered some interest, but it's up against other somewhat well-known languages such as Haskell, and (regrettably) this is a relatively small target audience anyway.

      So this still leaves us with the killer feature problem: there needs to be some significant field where Rust, or some library or tool connected to it, becomes regarded as almost essential, if it's going to attract a critical mass of developers and start climb the adoption curve significantly faster. Right now, I'm not sure it has one.

  • It's the syntax (Score:5, Insightful)

    by TypoNAM ( 695420 ) on Sunday April 26, 2020 @10:55AM (#59992720)

    I would be interested using Rust if it weren't for the poorly chosen language syntax. Same goes for Kotlin and Swift. Coming from C/C++ background I don't care for declaring variable names before their types. val/let, fn (instead of say "func" or "function"), etc... I hate implicit types and operations instead of being explicit.

    fn plus_one(x: i32) -> i32 {
            x + 1;
    }

    Ugly as hell compared to

    int plus_one(int x) {
            return x + 1;
    }

    it's also far more explicit as to what's going on in the C version that it's returning a value instead of just automatically returning the result of the last expression (implicit operation) in Rust which I definitely hate.

    • by dyfet ( 154716 )

      It's more than that. Core language features like traits are done in a decorator language. Disjunctive syntax for core features! Fond memories of Objective-C anyone?

      Then you have a C-like language that doesn't even use ';' consistently. It's absence is an expression returning. Clear as mud. Many other quirks and oddities that subtly break expectations of a C syntax like language, too. In some ways Perl is more readable...

      Your left with a functional language expressed in imperative syntax. They would

    • fn, fun, func, are definitely garbage to me too. In C, the compiler infers that you're declaring a function based on the syntax. OTOH, I think having return be optional, and a compiler that infers semicolons before the closing brace would be great. How many times have you gotten "syntax error, ; expected" and thought, if you expected it, why didn't you just infer it?. I'd be down with:

      int plus_one(int x) { x+1 }

      Counterpoint to fn/fun/func opposition: You could write Lisp with forms that bound symbols

    • Re: (Score:3, Insightful)

      by dremon ( 735466 )
      Ugliness is subjective. Rust fn syntax is made for easier symbol search in the sources. It's trivial to find a function by grepping "fn plus_one". And it's much easier to find a function returning something by grepping for "-> xxx".

      Good luck doing in it C.
      • by gtall ( 79522 )

        Ya, but a decent IDE would just tell you what the functions are. I don't have time to grok a mountain of code just find what I want.

      • Good luck doing in it C.

        It's generally done with a search for "function_name(" or "function_name (" depending on your coding convention. Problem solved.

    • I don't use Rust but I've done a lot of Swift, and have a very long history using C/C++ in the past...

      I don't care for declaring variable names before their types

      For me, I ended up not really caring which side of variable a type is declared on. I do like being able to omit the type in every expression, then I can choose if its clearer to add it, or the simplicity of leaving it out is clearer.

      val/let

      I agree here, to me that is just noise - you are basically telling the compiler if you expect to modify some

  • as many people talk it up; and the ecosystem and bootstrapping is truly horrifing and annoying; oh and they constantly break things https://www.youtube.com/watch?... [youtube.com]
  • Why is there a certain set of developers that think a language that you love is the one that you should work in? I may "love" a language but that doesn't mean I'll be able to get stuff done with it. I learned Python because I wanted to be able to make Django based websites. I learned PHP back when my wife wanted to have a phpbb bulletin board. When I come across something really useful for something I want to do that is developed in Rust, I will learn Rust.
    • by Octorian ( 14086 )

      Why is there a certain set of developers that think a language that you love is the one that you should work in?

      Likewise, why do so many developers think that one's language choice is a completely arbitrary independent variable? When I'm doing development, quite often my language choice is heavily dictated by the platform/environment I'm actually doing development for.

    • by Pimpy ( 143938 )

      Different languages also suit different tasks better. I wouldn't bother with anything but C and assembler for low-level programming, verilog/vhdl and TCL for hardware design, python for machine learning and computer vision applications, go for backend services and CLI apps, flutter/dart for user-facing apps, etc. I'm happy when I get to use a language that I consider the best fit for a particular problem, as opposed to having to sort through years of legacy that requires dragging an old code base kicking an

    • I choose the language for the libraries. That's why I spend most of my time writing in languages that I'd rather avoid.
  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday April 26, 2020 @11:20AM (#59992800)
    Comment removed based on user account deletion
    • People have a great deal of inertia. They will tend to stay with what they know.

      Unless you're looking for a "I'm the juggernaut" joke, then I think you mean that people are lazy or other languages have inertia.

    • I very much like what you said.

      My idea of the biggest problem with C++: The quality of the documentation is, generally, not good. So people use C++ in ways they should not.
    • I do agree with you that using Rust doesn't seem to have sufficient advantages over other options to tip the scales and make it a preferred language for most jobs, but I strongly disagree with most of your supporting reasoning.

      The arguments about what can be done in "well written" C++ are idealistic. The problem with C and C++ is that almost no-one does "write well", and we have countless security breaches and data loss incidents and downtime costs going back decades to prove it. A language that prevents a

    • The object oriented approach, is much more sophisticated. It essentially creates a base type (person) that holds the universal id, and two inherited types (teacher and student) that hold specific functionality for those persons. Using this approach, the "pay" function would be a function of only the teacher class, and you would not be able to call pay() on a person or a student, only a teacher. This would force the developer to keep a separate list of just teachers in order to pay teachers (Or use some dangerous pointer casts which you should basically never use if you are writing good software). In that way, a bug that attempts to pay a student would result in a *compile-time* error instead of a run-time error where a student gets paid. In this simple example, the proper use of OOP has forced the developer to architect the software in a way that renders it far more difficult to compile the program with a bug in it.

      This is a "scattered" approach. Instead of having the logic of "who gets paid" all in one place, the logic gets scattered into multiple places and becomes hard to read.

      If you add to that the tendency of OOP programmers to maximize the "glue code"/"get stuff done" code, then you see why OOP has bugs.

    • You forgot the most important types of bug, and they aren't even related to the programming language: design and requirements bugs.

      No programming language can resolve those, and those are at least 90% of all programming errors.

  • The biggest problem is that Rust is just yet another language and tries what have been tried before. To me it's always that some developers aren't happy with the language they are using and take that and try to recreate another language which in the end has it's own problems. Why use yet another language instead of just using the one you have better. I'm getting a bit tired of having to learn a new framework every single time because some other devs loves it, even though it doesn't really add anything new.
  • by nospam007 ( 722110 ) * on Sunday April 26, 2020 @11:32AM (#59992852)

    I prefer stainless steel.

  • by SkOink ( 212592 ) on Sunday April 26, 2020 @12:00PM (#59992956) Homepage

    Rust's whole concept of an unstable language is terrifying to me as a developer.

    I don't want to have to get the latest nightly/unstable version of a compiler ever. In fact, unstable is exactly the opposite of what I want from my compiler or my language specification.

    I know that Rust maintains good backwards compatibility. But after two or three rounds of adding "the new hot way to do something", older tutorials and libraries effectively become obsolete/stale. And this can make the language look like a constant treadmill to an outside observer.

    If the Rust team wanted to encourage broader adoption, I'd recommend:
      - Freeze the language for a few years.
      - Deprecate the concept of unstable and nightly versions of the language and compiler.
      - Expand the packages available in Linux distributions. Using Cargo to download everything feels too much like npm, and is vulnerable to authors taking down their packages.

    • Rust has seen a lot fewer changes than C++, over the last few years.
      • by SkOink ( 212592 )

        That's true. Most of the C++ devs I work with complain about language churn _constantly_, and don't consider this a good thing.

  • And probably some more problems. Question answered?

    Sure, it does have some nice ideas in there (nothing really earth-shattering, although the fanbois claim otherwise as usual), but overall it does not convince. My impression is the people behind it have no clue how to make a general-adoption production-stable language and the SJW-infested community does the rest to prevent people from even trying it.

  • by TurboStar ( 712836 ) on Sunday April 26, 2020 @12:09PM (#59992976)

    I wrote a compiler and process vm in Rust. (basic-lang.org) It was easy to learn and I like the language design but it compiles slow and some essential features are still being debated. I was happy to trade compiler speed for the quality of the code in my toy project. There doesn't seem to be many paying jobs though. I also wouldn't recommend it for most professional projects. Chicken and egg problem.

    • I wrote a compiler and process vm in Rust. (basic-lang.org)

      Did you write a Rust compiler?

      It was easy to learn and I like the language design but it compiles slow

      If you can write your own Rust compiler, you should be able to discover what is causing slow compile times.

      and some essential features are still being debated

      This is where I break from "The Cathedral and the Bazaar". A programming language is a work of art (good, bad, or ugly). It needs to "mostly perfect" before being released into the wild. Otherwise, it becomes design by committee.

  • Rust has the 3D TV problem. It's cool, looks good on a web page (or in a shop). But until people see that there is content for it (in terms of large projects) then it will continue to be an amusement and nothing more.
  • It expects too much (Score:4, Interesting)

    by nagora ( 177841 ) on Sunday April 26, 2020 @12:12PM (#59992994)

    Rust, from what I've read, expects the programmer to do a lot of work that we've come to expect the language to do for us - like do/while loops and working out what size ints are on the target machine.

    It's also big on immutability which is another crutch of the modern language designer, pushing more burden onto the end programmer. It's 2020, the compiler should be warning when something should be immutable for performance reasons (or pointing out possible parallel processing opportunities), not requiring the programmer to declare that his/her variables are actually variable and not constant.

    It also does insane things like:

    a=45;
    b=a;
    a=a*2; # error. 45 has been MOVED to b, not copied; a is now null. I don't know why anyone would design a language which does this.

    Again, this is what I've been told. It was enough to make me decide that Rust is an interesting possible alternative to assembler, but that's about it.

    • by vadim_t ( 324782 ) on Sunday April 26, 2020 @01:07PM (#59993200) Homepage

      First, Rust doesn't really do that with integers. It does it with objects. So your specific example is just fine, it wouldn't be with a reference.

      Second, Rust doing that is the very point of the language. In say, C if you call "foo(ptr)", you need some sort of convention about what's supposed to happen. Eg, "foo" might start a thread and change the object when you don't expect. It might free it. It might modify it in some unexpected way, like if "ptr" points to an array and "foo" shrinks it, and the caller doesn't take that into account.

      So the way Rust deals with that is that you transfer ownership to "foo". The caller has given it up, and can do nothing with it afterwards. So if "foo" starts a thread, or does something weird to the object, the object is now outside of the caller's control anyway. The language ensures that once foo() terminates, the memory is freed. And this costs nothing, because since there's only one owner of the object at any time, there's no reference counting or garbage collection.

      There's a lot more to it, but in short that's the very point of it: it forces code to be structured in a very particular way, that ensures some very specific guarantees. And so for instance you can't have a double free, or a variable being changed behind your back because you didn't read the documentation well enough or the library decided to do something you didn't expect in version N+1.

    • by ljw1004 ( 764174 )

      Rust, from what I've read, ... Again, this is what I've been told. It was enough to make me decide that Rust is an interesting possible alternative to assembler, but that's about it.. [a=45; b=a; a=a*2; # error. 45 has been MOVED to b, not copied

      What you read and were told is flat out incorrect; your example is incorrect. That is not what Rust does. I'd encourage you to look at Rust yourself rather than second hand!

      It's also big on immutability which is another crutch of the modern language designer, pushing more burden onto the end programmer. It's 2020, the compiler should be warning when something should be immutable for performance reasons (or pointing out possible parallel processing opportunities), not requiring the programmer to declare that his/her variables are actually variable and not constant.

      You've got the wrong end of the stick. Programmers are asking for immutability to SAVE THEMSELVES from bugs. They have been asking for ways to indicate their intent that something shouldn't be changed, neither by themselves, nor by subsequent maintainers of their code. There is less foot-shootage in languages that offer programmers the a

  • Rust does similar things to C++, I played with it, and I agree it's very cool. However, in my real world job we use Java, typescript ( java script) and Python in that order. What we do, there's not really a place for that type of language. I think a lot of developers work in similar environments, Node JS or Javascript, Java, Python ...... Arguably we could replace the python systems glue code with Rust, but again all the devops folks love python so that's not happening. It's an awesome C++ replacement

  • Rust uses LLVM as its sole backend. C++ can use either LLVM or GCC. GCC supports several instruction sets that LLVM does not, particularly the Motorola 680x0 (m68k) instruction set of the 68000, 68010, 68020, 68030, 68040, and 68060 CPUs. These CPUs are found in the Amiga computer, older Macintosh computers, and the Sega Genesis and Neo Geo AES video game consoles, among others. Currently, a program written in Rust cannot be compiled for any m68k CPU.

    Though support for m68k in LLVM was prototyped in the second half of 2018, upstream refuses to merge it unless someone can commit to maintaining it for several years [llvm.org]. Because LLVM changes faster than GCC, maintaining support for an instruction set in LLVM takes more effort than doing so in GCC. The only recent change needed for GCC, for example, was a port of its handling of condition codes (zero, negative, overflow, carry, and extend flags) from a deprecated framework to the framework that GCC currently uses, which happened in November of 2019 [phoronix.com].

    It's probably a small amount in absolute numbers, and I admit that many will consider computers and game consoles from the mid-1980s to mid-1990s to be an edge case not worth serving.

  • Toy languages are a dime a dozen, which for most people means that it's not worth sinking resources into learning until there's a sufficient ecosystem around it to suggest there will be some continued adoption, or because it solves some sort of fundamental programming problem that other languages do not. I've not yet seen any indication of either in Rust, and the added layer of social justice silliness by the author(s) put a pretty big question mark over that ecosystem coming to fruition. My expectation is

  • Back in then late '80s and '90s, many people's computing resources were stratified. You had the haves and the have-nots, and if you didn't have the memory, CPU, Internet or other resources, you couldn't do what other people could do. This, obviously, included programming.

    As free and open OSes became prevalent, and as computing has become ubiquitous, pretty much anyone can attain enough computing power to participate, even on a first gen Raspberry Pi or a decade old, recycled x86.

    Rust changes all of that. Ru

  • This question is quite apropos... Just 2 weeks ago I decided to expand my horizons as a 30-year C programmer and took up a rust tutorial. Already I can't stand syntaxes like this: io::stdin().read_line(&mut guess).expect("Failed to read line");
    But what really made me omit is this:
    match guess.cmp(&secret_number) {
    Ordering::Less => println!("Too small!"),
    Ordering::Greater => println!("Too big!"),
    Ordering::Equal => println!("You win!"),
    }
    How exactly i
  • Rust is popular with some developers at Microsoft, "who are experimenting with Rust to reduce memory-related bugs in Windows components written in C and C++."

    Or, they could spend a little more time honing their skills to reduce those issues using C and C++. Just sayin' the above argument makes using Rust sound like a crutch.

  • Rust is one of many languages that address one subject area well (memory safety in this case) but otherwise are not much better than what's already out there - perhaps not enough better outside of its specialty to justify widespread adoption for use outside of software development that really requires its specialty. Does it produce faster code as well as safer? Is it widely available (e.g. in Visual Studio, as part of the gcc collection, etc.)? If it's a domain-specific language (like COBOL and FORTRAN and

  • That's just me, though. I'd pick up rust if it supported subclassing. It just happens that I really like that flavor.

    (No, I really don't need to hear why subclassing is bad [for rust]. This was an opinion question, and I've got one.)

  • by skinlayers ( 621258 ) on Monday April 27, 2020 @05:49AM (#59995886)

    Docker, Kubernetes, LXD, and most of the projects under the Cloud Native Computing Foundation (Envoy being a notable C++ exception) are all written in Go. In fact, we'll probably see Java slowly die off an be replaced by Golang more and more in cloud environments as time progresses. Like it or not, Linux, Golang, and Python rule the Clouds.

    https://www.cncf.io/projects/ [www.cncf.io]

Your good nature will bring you unbounded happiness.

Working...