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...
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
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.
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.
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.
I am too lazy to look up which fallacy you just used, but your comment is also pretty stupid. A general understanding what Rust is programming language is quite enough for that statement. You can easily shoot yourself in the foot in _all_ currently known programming paradigms, except ones where you cannot solve real problems and even there it is sometimes possible.
I am too lazy to look up which fallacy you just used
It doesn't matter. Naming "fallacies" is a pointless waste of time. It adds nothing to the discussion and there's an excellent chance that neither party actually understands the "fallacy" in question.
I blame the recent flood of so-called "informal fallacies" coupled with autodidact programmers who don't have a formal background in logic believing themselves to be competent logicians because they once heard about DeMorgan's laws.
You can easily shoot yourself in the foot in _all_ currently known programming paradigms
I don't buy it. Some languages make it significantly harder to do stupid thi
It doesn't matter. Naming "fallacies" is a pointless waste of time. It adds nothing to the discussion and there's an excellent chance that neither party actually understands the "fallacy" in question.
I blame the recent flood of so-called "informal fallacies" coupled with autodidact programmers who don't have a formal background in logic believing themselves to be competent logicians because they once heard about DeMorgan's laws.
I've noticed this, too: it seems that a sizeable fraction of the Slashdot community have taken the same "Intro to Logic" class at University (and most of them apparently got a poor grade).
Then why is it conceptually difficult to come up with underhanded rust code? If it's easy to shoot yourself in the foot with rust, and really hard to figure out what went wrong, then underhanded rust code should be dead simple to create.
It is also easy to just make code-logic errors. If the programmers believe they can be a lot less strict and careful (after all, Rust prevents "all" errors....), Rust is likely to amplify the problem. Same if "managers" believe they can use even less experienced people because Rust is so great.
The focus on memory-safety as the main problem is bogus. Sure, if you just count, these seem to be the most numerous. But they are easy to find, both for attackers and for (competent) developers. They are also easy to
No one has ever said that in earnest. I'm reasonably certain that you're the only person to have ever said that.
Same if "managers" believe they can use even less experienced people because Rust is so great.
No one is saying that either. Rust is not a good language for beginners and has a nasty learning curve that would quickly frustrate an inexperienced team.
You seem really upset with what I can only assume are completely imaginary people.
The only reason they have high numbers is general developer incompetence.
So it solves are real problem and helps prevent common errors. Isn't that what the guys railing against dynamic languages always complain about? That they
Why do you assume I am "upset"? I think you are just trying to belittle me in a transparent attempt to avoid actually addressing my points, i.e. talking down to somebody that basically behaves like a child. Pathetic.
Incidentally, you have not even begun to understand my points. Shows a lack of real-world insight and experience. No, that is not an insult, that is a diagnosis. Yes, I am placing myself above you here, as you clearly are not a peer to me.
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.
It must be very profitable if you can spend 20 person years re-writing it in another language. Amazing you don't need to spend time on maintenance (bug fixes) or new features.
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.
Nope. And you do not even understand what I am talking about. That is a pretty big fail. It nicely illustrates the general incompetence level of "developers" these days though.
There was nothing obvious about your claim that "you can shoot yourself in the foot with Rust just as easily", when Rust was engineered specifically to keep the developer from making these kinds of mistakes.
Nope. And you do not even understand what I am talking about.
I'd love to have you explain what you meant!
You wrote: "you can shoot yourself in the foot with Rust just as easily, it will just be harder to find the problem later on."
My answer was that the foot-shooting from a soundness perspective is limited to unsafe blocks. This (1) makes it easier to find problems up-front, (2) makes it easier to find the problem later on.
If your point was that that foot-shooting isn't related to soundness? I certainly agree with you in languages like Java and C# and Haskell. I stre
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
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
You could go and the next ten messages on the rust users forum and tell me how many of them mention things that you would consider by the SJW nonsense and how many are actually about the technology. Compare that with articles from about Rust on slashdot where it comes up with tiresome regularity. "It should only be about the technology" and "I would never use a project with SJWs in it". See the contradiction there?
Esp since, as far as I can tell, the anti-SJW outrage is coming from something Rust the video game did rather than anything to do with the language... and even that pretty much came down to 'how dare a game developer treat us like women! SJW SJW SJW!'
In the real world where people program for a living.. yeah, lack of libraries, ecosystem, and a compelling reason to spend the resources to switch a project from something that is already working for pretty limited benifits.
"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."
By this definition, if you are on slashdot, you are clearly not a good engineer.
For reference, some of thing the SJW impositions that I have regularly had to face on the Rust forums are:
1) No first post ascii swastiki 2) No links to goat
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.
So, Rust solves a problem that only exists in principle.
I think it's worse than that. Not only does it solve a problem that's already been solved (for those who program with care, at least), but it introduces a whole raft of new problems. Last time I looked (which admittedly was a while ago), nobody could work out how to do a GUI in Rust. If the language experts have trouble working out how to make the language do routine things, adoption is going to be a problem.
Hmm, people do GUIs in C quite often. A few minor components that implement some object abstraction method and you can go far. So if Rust can't do what C can...
20 years or so ago, I wrote a reasonably large GUI toolkit for X11 in C. It worked out great. The code base was neat as a pin and trivial to use. Using C++ would have added quite a bit of unnecessary complexity.
I'd say that only a masochist or worse would use C++ in place of C.
Hmm, I'm in embedded systems, generally either all third party libraries are in C, but you mostly have to implement your own at some stage and you usually get full source code so you can fix all the bugs in the third party libraries. If your bread and butter product is chiefly built around other people's code, then the in-house expertise may reside somewhere other than in coding.
Better than C, but not as screwed up at C++ and all the other C replacements. We can all hope for that, but it might be a long wait.
Plus you don't adopt new stuff for serious work. There's often one guy straight out of school who can't stop evangelizing over some other language and is pissed that the entire company won't throw out its code base and start from scratch. Even for a new project, you have to plan out the future - if we go with today's fashionable language, do we have to train everyone and how
The confusion of a staff member is measured by the length of his memos.
-- New York Times, Jan. 20, 1981
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
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:1)
Re: (Score:2)
Re: (Score:2)
Not quite. It refers to soldiers who do not want to get killed in battle.
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: (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.
No. Real-world experience needed. It seems you lack that. The irrelevant counting-statistic you cite further underlines that.
Re: (Score:2)
Re: (Score:2)
I am too lazy to look up which fallacy you just used, but your comment is also pretty stupid. A general understanding what Rust is programming language is quite enough for that statement. You can easily shoot yourself in the foot in _all_ currently known programming paradigms, except ones where you cannot solve real problems and even there it is sometimes possible.
Re: (Score:2)
I am too lazy to look up which fallacy you just used
It doesn't matter. Naming "fallacies" is a pointless waste of time. It adds nothing to the discussion and there's an excellent chance that neither party actually understands the "fallacy" in question.
I blame the recent flood of so-called "informal fallacies" coupled with autodidact programmers who don't have a formal background in logic believing themselves to be competent logicians because they once heard about DeMorgan's laws.
You can easily shoot yourself in the foot in _all_ currently known programming paradigms
I don't buy it. Some languages make it significantly harder to do stupid thi
Re: (Score:1)
It doesn't matter. Naming "fallacies" is a pointless waste of time. It adds nothing to the discussion and there's an excellent chance that neither party actually understands the "fallacy" in question.
I blame the recent flood of so-called "informal fallacies" coupled with autodidact programmers who don't have a formal background in logic believing themselves to be competent logicians because they once heard about DeMorgan's laws.
I've noticed this, too: it seems that a sizeable fraction of the Slashdot community have taken the same "Intro to Logic" class at University (and most of them apparently got a poor grade).
Re: Wait a second... (Score:2)
Then why is it conceptually difficult to come up with underhanded rust code? If it's easy to shoot yourself in the foot with rust, and really hard to figure out what went wrong, then underhanded rust code should be dead simple to create.
Re: (Score:2)
It is also easy to just make code-logic errors. If the programmers believe they can be a lot less strict and careful (after all, Rust prevents "all" errors....), Rust is likely to amplify the problem. Same if "managers" believe they can use even less experienced people because Rust is so great.
The focus on memory-safety as the main problem is bogus. Sure, if you just count, these seem to be the most numerous. But they are easy to find, both for attackers and for (competent) developers. They are also easy to
Re: (Score:2)
after all, Rust prevents "all" errors....
No one has ever said that in earnest. I'm reasonably certain that you're the only person to have ever said that.
Same if "managers" believe they can use even less experienced people because Rust is so great.
No one is saying that either. Rust is not a good language for beginners and has a nasty learning curve that would quickly frustrate an inexperienced team.
You seem really upset with what I can only assume are completely imaginary people.
The only reason they have high numbers is general developer incompetence.
So it solves are real problem and helps prevent common errors. Isn't that what the guys railing against dynamic languages always complain about? That they
Re: (Score:2)
Why do you assume I am "upset"? I think you are just trying to belittle me in a transparent attempt to avoid actually addressing my points, i.e. talking down to somebody that basically behaves like a child. Pathetic.
Incidentally, you have not even begun to understand my points. Shows a lack of real-world insight and experience. No, that is not an insult, that is a diagnosis. Yes, I am placing myself above you here, as you clearly are not a peer to me.
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: Wait a second... (Score:2)
It must be very profitable if you can spend 20 person years re-writing it in another language. Amazing you don't need to spend time on maintenance (bug fixes) or new features.
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.
That's incorrect.
Nope. And you do not even understand what I am talking about. That is a pretty big fail. It nicely illustrates the general incompetence level of "developers" these days though.
Re: (Score:2)
Re: (Score:2)
When somebody overlooks obvious things, it is a pretty valid argument and a nice indicator for incompetence.
Re: (Score:2)
Re: (Score:2)
There was nothing obvious about your claim that "you can shoot yourself in the foot with Rust just as easily",
You think so? Then you have no place in this discussion.
Re: (Score:2)
Nope. And you do not even understand what I am talking about.
I'd love to have you explain what you meant!
You wrote: "you can shoot yourself in the foot with Rust just as easily, it will just be harder to find the problem later on."
My answer was that the foot-shooting from a soundness perspective is limited to unsafe blocks. This (1) makes it easier to find problems up-front, (2) makes it easier to find the problem later on.
If your point was that that foot-shooting isn't related to soundness? I certainly agree with you in languages like Java and C# and Haskell. I stre
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:1)
You sure showed that straw man.
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: (Score:2)
Confirmation bias, statements from authority lacking said authority.
Re: (Score:2)
You could go and the next ten messages on the rust users forum and tell me how many of them mention things that you would consider by the SJW nonsense and how many are actually about the technology. Compare that with articles from about Rust on slashdot where it comes up with tiresome regularity. "It should only be about the technology" and "I would never use a project with SJWs in it". See the contradiction there?
Re: (Score:2)
In the real world where people program for a living.. yeah, lack of libraries, ecosystem, and a compelling reason to spend the resources to switch a project from something that is already working for pretty limited benifits.
Re: (Score:2)
"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."
By this definition, if you are on slashdot, you are clearly not a good engineer.
For reference, some of thing the SJW impositions that I have regularly had to face on the Rust forums are:
1) No first post ascii swastiki
2) No links to goat
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)
So, Rust solves a problem that only exists in principle.
I think it's worse than that. Not only does it solve a problem that's already been solved (for those who program with care, at least), but it introduces a whole raft of new problems. Last time I looked (which admittedly was a while ago), nobody could work out how to do a GUI in Rust. If the language experts have trouble working out how to make the language do routine things, adoption is going to be a problem.
Re: (Score:2)
Hmm, people do GUIs in C quite often. A few minor components that implement some object abstraction method and you can go far. So if Rust can't do what C can...
Re: (Score:2)
Only masochists or worse would program a GUI in C, instead of C++.
Re: (Score:2)
If it is any harder using C, then you probably shouldn't be touching it anyways. Use something higher level that you'll understand more of.
Re: (Score:2)
20 years or so ago, I wrote a reasonably large GUI toolkit for X11 in C. It worked out great. The code base was neat as a pin and trivial to use. Using C++ would have added quite a bit of unnecessary complexity.
I'd say that only a masochist or worse would use C++ in place of C.
Re: (Score:2)
X11 is hard to program, so your claim: codebase neat etc. makes no sense.
I programmed on SUN S OpenLook - simply a horrible API.
Re: (Score:2)
Except that it's not that difficult.
Re: (Score:2)
(for those who program with care, at least)
Well, that changes everything. That leaves the problem completely unsolved.
nobody could work out how to do a GUI in Rust.
They've been making a web browser with it since 2012: Servo [servo.org] A "while ago" indeed...
Re: (Score:2)
Ecosystem matters.
I don't choose my language, I choose my libraries.
Re: (Score:2)
Hmm, I'm in embedded systems, generally either all third party libraries are in C, but you mostly have to implement your own at some stage and you usually get full source code so you can fix all the bugs in the third party libraries. If your bread and butter product is chiefly built around other people's code, then the in-house expertise may reside somewhere other than in coding.
Re: (Score:2)
Re: (Score:2)
You still choose the language, too. C/C++ - Ada - Forth - etc. ...
Some people even use OCml or Lisp
Re: (Score:2)
Better than C, but not as screwed up at C++ and all the other C replacements. We can all hope for that, but it might be a long wait.
Plus you don't adopt new stuff for serious work. There's often one guy straight out of school who can't stop evangelizing over some other language and is pissed that the entire company won't throw out its code base and start from scratch. Even for a new project, you have to plan out the future - if we go with today's fashionable language, do we have to train everyone and how