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++."
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++."
Wait a second... (Score:5, Insightful)
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.
Re:Wait a second... (Score:5, Insightful)
Re: (Score:3)
Hit the nail on the head.
Re: (Score:2)
Exactly.
I want a goddamn compiler, not a moral judgement.
Re:Wait a second... (Score:5, Funny)
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!
Re: (Score:2)
Indeed. I will stay far away from any group that so clearly sails under a false flag.
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
half the population was already living with those feelings
Half the population, meaning women? Or men? Or what exactly did that mean?
Re: (Score:2)
It means that half the population was born with a sex it doesn't like, but I don't believe that for a second.
Re:Wait a second... (Score:5, Insightful)
It doesn't have to be foremost on people's minds to chase them away. I steer way from projects when I see SJW nonsense. It's a huge red flag that the community is full of moral busybodies. Many of whom are all too eager to tear each other and the project apart over bullshit that has nothing to do with the project. I'm not going to waste my time on something that is one "triggering" tweet away from becoming a dumpster fire.
Re: (Score:3, Funny)
Maybe you should get off slashdot too, just in case a SJW posts something!
Re: (Score:2)
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)
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.
Re:Wait a second... (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:3)
Re:Wait a second... (Score:5, Interesting)
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)
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.
Re: (Score:3)
What you overlook is that memory safety issues are by far not the only source of vulnerabilities. They are easy to find, which means attackers go for them first and competent developers do not actually have the problem because they can find them easily too. Because of a large number of incompetent developers, they are the ones mostly counted. But look, for example, to the OWASP Top-10 and you find the first memory safety issue in place 9. The same is true for any other thing Rust claims to do. There are sti
Re: (Score:3)
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)
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.
Re: (Score:2)
Ecosystem matters.
I don't choose my language, I choose my libraries.
Re:Wait a second... (Score:5, Insightful)
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup, creator of C++.
Re: (Score:2)
Who says they love something they have not used???
Shills and fanboys.
Both of which deserve a good solid punch in the teeth.
Re: (Score:2)
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
Re: (Score:2, Funny)
How do I automate auditing the morals of Rust developers so I can continuously judge (CJ) them and reject them from a project?
Re: (Score:2)
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.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
If you need to assure high code quality, you need to audit a lot more stuff than Rust does automatically. And then the difference in language stops to matter and the difference in coder skill is everything.
Re: (Score:2)
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
1. Static analysis tools can warn if naked pointers are used.
2. Memory allocation can be instrumented for testing. A good programming practice is to fully unwind all memory allocation before exiting. Any leaks will be detected. This will even catch leaks from cyclic references that Rust does NOT prevent (yes, Rust can leak memory).
3. I don't know much about Rust's concurrency model, but if I Google for "rust deadlock", I get plenty of hits. So it looks like Rust isn't a magic solution.
Re: (Score:2)
Thank you Captain Obvious (Score:3)
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.
Why Aren't More Developers Using Rust? (Score:3)
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.
Re: (Score:2)
FF will definitely slow the spread of rust.
They say the same thing about sex (Score:5, Funny)
Stack Overflow (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Ah, so the copy&paste crowd is the fan-base. Figures.
The non question of the decade... (Score:2)
... 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
Don't give a computer language a foolish name. (Score:2)
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.)
Re: (Score:2)
All the cool kids use recursive acronyms, e.g.
RUST Until Something Trendier.
So the biggest problem... (Score:2)
...with RUST adoption is "adoption"? Is that right?
Why? (Score:2)
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)
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)
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.
Re: (Score:3)
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
Re: (Score:2)
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:
Counterpoint to fn/fun/func opposition: You could write Lisp with forms that bound symbols
Re:It's the syntax (Score:5, Insightful)
How many times have you gotten "syntax error, ; expected" and thought, if you expected it, why didn't you just infer it?
None, I was always glad the compiler expected rigid syntax and told me to fix my mistake.
Re: (Score:3, Insightful)
Good luck doing in it C.
Re: (Score:2)
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.
Re: (Score:2)
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.
Mixed feelings on those. (Score:2)
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
Re: (Score:2)
Indeed, but in Rust "x + 1" explicit return can drop the ending ";" ! Yikes, and they say that makes it "clearer" ;)
Not as amazing (Score:2)
Love is only part of it (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
Comment removed (Score:5, Insightful)
Re: (Score:2)
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.
Wow! MOD PARENT UP! (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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.
Just yet another language (Score:2)
I can speak only for myself (Score:4, Funny)
I prefer stainless steel.
The language is too unstable (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
That's true. Most of the C++ devs I work with complain about language churn _constantly_, and don't consider this a good thing.
Bad SJW community, unfinished over-hyped language (Score:2)
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.
More developers would use it if you pay them. (Score:4, Interesting)
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.
Re: (Score:2)
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.
3D TV problem (Score:2)
It expects too much (Score:4, Interesting)
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.
Re:It expects too much (Score:5, Interesting)
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.
Re: (Score:2)
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
What rust is for (Score:2)
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
Instruction sets unsupported by LLVM (Score:5, Informative)
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.
Early adoption vs. staying power (Score:2)
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
Rust is NOT resource friendly (Score:2)
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
Have you seen some of Rust syntax ?!? (Score:2)
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
Maybe this has been said ... (Score:2)
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.
What About? (Score:2)
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
'cause no subclassing (Score:2)
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.)
Because Golang Already Won in The Cloud (Score:3)
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]
Re: (Score:2)
Rust is a political platform first and programming language second?
You're confusing it with Firefox, but that's somewhat understandable.
Re: (Score:2)
Rust is a political platform first and programming language second?
You're confusing it with Firefox, but that's somewhat understandable.
Aren't they both Mozilla?
Re: (Score:2)
On top of that their version of 'make' doesn't recognize or honor MAKEOPTS. Instead you have to create a world readable file off the root of the filesystem to control it's behavior.
Oh that's how it's done. I googled the shit out of that and found nothing but irrelevant info. I eventually gave up on my build of firefox I was attempting a few months ago.
Given your explanation I'm not going to bother now though.
Re: (Score:2)
Re: (Score:3, Insightful)
Any language which does garbage collection (like Rust) is highly suspect.
You must be thinking of something else. Rust does not do garbage collection.
Re: (Score:2)
Yes it does, put in by compiler
calls Drop::drop which deallocate
Re: (Score:2)
Yes it does, put in by compiler
calls Drop::drop which deallocate
That is not garbage collection, that's deallocation which is a TOTALLY different thing altogether. The compiler makes deallocation (which you have to do in C/C++) easier because variables are deallocated (what appears to be automatically) when leaving scope. Garbage collection goes around like your neighborhood refuse collection agency and picks up what it finds, occasionally stopping traffic in the process.
Re: (Score:3)
it is a kind of garbage collection, don't make up your own definitions. it's just not run-time garbage collection.
Re: (Score:2)
Re: (Score:2)
Any language which does garbage collection (like Rust) is highly suspect.
You may be thinking of Go. Rust doesn't use garbage collection. In fact, the Rust developers go to incredible lengths to make all of languages features "zero cost".
Re: (Score:2)
I think that to make Rust more suitable to a wider set of problems, they need to figure out how to add a garbage-collected reference type. (I get the impression from some posts I've seen that they've tried this in the past, but gave up.)
As it stands, everything in the program has to be managed by reference counting, borrowing or exclusive ownership. This can be rather onerous, and there are often a lot of parts of a large program that just don't need the performance that those give. C++ is mostly in a simil
Re: (Score:2)
The majority of systems programmers don't think Rust is well suited.
Re:Don't need it. (Score:5, Insightful)
You're kidding, right? C/C++ are going to be the kings of low level development for a long time to come. I wouldn't even call Rust a mature language yet.
If I had a dollar for every language enthusiast who proclaimed their language was going to topple C, I'd be a wealthy man.
Re: (Score:2)
Yes, mostly this.
Don't do kernel memory management in Rust. Don't do signal processing in C. Don't write a network server in C or Rust.
The lack of uptake may well be that very few apps at the right level are being started or rewritten.
People who could adapt C/C++ apps to be libraries that Rust could link to may not see the need. Remember, most C++ devs don't consider the problems that Rust solves to be problems. And depending on how much C++ devs avoid C patterns, they can largely avoid those problems in C
Re: (Score:3)
A build system that requires an internet connection? Seriously? Well, that's a language I'm never going to use.
Re: (Score:3)
Gee, am I the only one who can think of a lot of ways how this could bite one in the ass?
I at least can easily see what makes companies think twice before adopting something like this.