New Study Verifies Safety of Rust (eurekalert.org) 132
Slashdot reader Beeftopia writes: Rust has two modes: its default, safe mode, and an unsafe mode. In its default, safe mode, Rust prevents memory errors, such as "use-after-free" errors. It also prevents "data races" which is unsynchronized access to shared memory. In its unsafe mode (via use of the "unsafe" block), in which some of its APIs are written, it allows the use of potentially unsafe C-style features. The key challenge in verifying Rust's safety claims is accounting for the interaction between its safe and unsafe code. This article from April's issue of Communications of the ACM provides an overview of Rust and investigates its safety claims.
The article is co-authored by Ralf Jung, a prominent postdoctoral researcher in the 'Foundations of Programming' research group at the Max Planck Institute for Software Systems. And (spoiler alert) Jung has just received one of two 'Honorable Mentions' for the 'Dissertation Award' of the 'Association for Computing Machinery' (ACM), reports a nonprofit site operated by the American Association for the Advancement of Science: In his dissertation, Ralf Jung now provides the first formal proof that the safety promises of Rust actually hold. "We were able to verify the safety of Rust's type system and thus show how Rust automatically and reliably prevents entire classes of programming errors," says Ralf Jung.
In doing so, he also successfully addressed a special aspect of the programming language: "The so-called 'type safety' goes hand in hand with the fact that Rust imposes restrictions on the programmer and does not allow everything that the programmer wants to do. Sometimes, however, it is necessary to write an operation into the code that Rust would not accept because of its type safety," the computer scientist continues. "This is where a special feature of Rust comes into play: programmers can mark their code as 'unsafe' if they want to achieve something that contradicts the programming language's safety precautions. Together with international collaborators, including my thesis advisor Derek Dreyer, we developed a theoretical framework that allows us to prove that Rust's safety claims hold despite the possibility of writing 'unsafe' code," Jung says.
This proof, called RustBelt, is complemented by Ralf Jung with a tool called Miri, with which 'unsafe' Rust code can be automatically tested for compliance with important rules of the Rust specification - a basic requirement for correctness and safety of this code. "While RustBelt was a great success, especially in academic circles, Miri is already established in industry as a tool for security testing of programs written in Rust," explains Ralf Jung.... The ACM states: "Through Jung's leadership and active engagement with the Rust Unsafe Code Guidelines working group, his work has already had profound impact on the design of Rust and laid essential foundations for its future."
The article is co-authored by Ralf Jung, a prominent postdoctoral researcher in the 'Foundations of Programming' research group at the Max Planck Institute for Software Systems. And (spoiler alert) Jung has just received one of two 'Honorable Mentions' for the 'Dissertation Award' of the 'Association for Computing Machinery' (ACM), reports a nonprofit site operated by the American Association for the Advancement of Science: In his dissertation, Ralf Jung now provides the first formal proof that the safety promises of Rust actually hold. "We were able to verify the safety of Rust's type system and thus show how Rust automatically and reliably prevents entire classes of programming errors," says Ralf Jung.
In doing so, he also successfully addressed a special aspect of the programming language: "The so-called 'type safety' goes hand in hand with the fact that Rust imposes restrictions on the programmer and does not allow everything that the programmer wants to do. Sometimes, however, it is necessary to write an operation into the code that Rust would not accept because of its type safety," the computer scientist continues. "This is where a special feature of Rust comes into play: programmers can mark their code as 'unsafe' if they want to achieve something that contradicts the programming language's safety precautions. Together with international collaborators, including my thesis advisor Derek Dreyer, we developed a theoretical framework that allows us to prove that Rust's safety claims hold despite the possibility of writing 'unsafe' code," Jung says.
This proof, called RustBelt, is complemented by Ralf Jung with a tool called Miri, with which 'unsafe' Rust code can be automatically tested for compliance with important rules of the Rust specification - a basic requirement for correctness and safety of this code. "While RustBelt was a great success, especially in academic circles, Miri is already established in industry as a tool for security testing of programs written in Rust," explains Ralf Jung.... The ACM states: "Through Jung's leadership and active engagement with the Rust Unsafe Code Guidelines working group, his work has already had profound impact on the design of Rust and laid essential foundations for its future."
Does not matter (Score:3, Informative)
The problem we have is not inadequate tools, it is inadequate coders. These come from broken hiring, broken education and the demented misunderstanding that coders do not need to be engineers. All other technological fields restrict tasks on the difficulty level of writing code to engineers. Unless and until we have that for code as well, things will _not_ get better.
There are plenty of severe vulnerabilities in things written in memory-safe languages. That alone shows these efforts and the promises made by the Rust people are, at best, misdirection and at worst lies.
Re:Does not matter (Score:4, Interesting)
The problem we have is not inadequate tools, it is inadequate coders.
You can improve the tools. You aren't going to improve the people.
If your solution relies on "better people" then it isn't a solution at all.
These come from broken hiring, broken education
Yet better hiring and better education haven't made software problems disappear.
the demented misunderstanding that coders do not need to be engineers.
I have seen no evidence that degreed engineers write better code than CS people. My personal experience is that the opposite is true.
Re:[Rust] Does not matter (Score:2)
Interesting line of analysis. Should have been FP.
However, I think it's going in a funny direction. The problem is that people are going to rise to whatever level of complexity the tools make possible. Rust might eliminate certain kinds of problems. You may even argue that those problems were created by fools with weak tools. But the fools are infinitely ingenious and if you give the fools fancier tools, they'll just rise to the occasion, same as it ever was.
I'm just barely old enough to remember when a "re
Re: (Score:3)
And that's exactly the kind of issues Rust (in safe mode) aims to solve.
You can't overflow a buffer. You can't free memory twice. You can't access a shared data structure without locking it. You can't write a switch statement that doesn't cover every possibility. You can't ignore error handling, if a function returns an error you must do something about it (which may be just panicking right there, but you must explicitly do something).
Which means that a lot of issues that result in a crash in C are outright
Re: (Score:2)
You seem to be missing my point, and the tone of your reply suggests you have religious issues.
I'm not saying that Rust doesn't do anything or solve any problems. My point is that people are innovative and they will create new problems. Would it help to cite Godel's Incompleteness Theorems against Rust's "perfection"? Or an appeal to Turing's work on UTMs and the halting problem?
Re: (Score:2)
No religious issues, very much practical ones.
If empirical observation shows that people often mess up memory management, make a language that ensures you don't mess it up.
Yes, people will make other mistakes the checks don't cover. So iterate, and improve the language again.
Re: (Score:2)
Basically my point is that the iterations never cease. However the complexity of the problems increases.
I acknowledge that the current problems are already too complicated for me, but that's a big chunk of the reason I'm not a professional programmer now. Actually I'd be ready to throw up my hands in defeat except that the level of abstraction is also increasing. Yeah, we still don't know what's going on, but we don't know in bigger pieces?
Re: (Score:2)
Perfection doesn't exist. We can only approach it.
Complexity is unavoidable, because the real world is complex. We can to an extent limit complexity by building good interfaces. A filesystem is a devilishly complex thing, but you don't have to care most of the time, because you know you can open() and write() a thing, and what happens behind the hood isn't of your concern.
We've reduced the effective complexity in many regards. Remember the time when disks had cylinders, heads and sectors, and when you had t
Re: (Score:2)
At this point I'm not sure if you're disagreeing or agreeing with me. But initially I took you as proselytizing for Rust. Maybe I should just blame Shanghai Bill for drawing me into it?
Re: (Score:2)
My point is that people are innovative and they will create new problems.
Perhaps, but mostly people are just lazy and will take whatever is the course of least resistance to getting their program to a shippable state. If Rust (or some other tool) can make it so that the path of least resistance is also less bug-prone, then that's a win for everybody.
If you're looking for the Rust's Achilles' heel, I suggest a different one: that Rust, in the name of safety, if finicky enough that the fools of the world will get frustrated trying to get their buggy code to compile, and will tur
Re: (Score:2)
Basically concurrence, though my eye got stuck for a minute on the typo.
Re: (Score:2)
You can't access a mutable shared data structure without locking it.
FTFY
Re: (Score:3, Insightful)
You can't overflow a buffer. You can't free memory twice.
Solved by libraries.
No, it isn't solved by libraries because many programmers don't use them or don't use them correctly. Then you are right back to the "Just hire better people" non-solution.
Turn on the compiler warning and change it to an error.
Download a C++ program from the Internet, and try to compile it with -Werror.
Good luck with that.
You can't depend on every programmer to be trained and diligent.
nodiscard on functions and types.
How many C++ programmers do that? Most don't.
Re: (Score:2)
You can't depend on every programmer to be trained and diligent.
True of any field. Amateurs are not necessarily trained or diligent. Professionals, should be.
Re: (Score:3, Informative)
No, it isn't solved by libraries because many programmers don't use them or don't use them correctly. Then you are right back to the "Just hire better people" non-solution.
If someone can't use a library properly, one that removes low level considerations like memory management, then that person is not fit to use Rust either. Are Rust libraries immune from being used incorrectly?
Download a C++ program from the Internet, and try to compile it with -Werror. Good luck with that.
Doesn't negate what I said. The fact is, the compiler caught it, which proves my point.
How many C++ programmers do that? Most don't.
Most don't, because most functions and types don't need it. But we're talking about error types where they can be tagged at one spot but used anywhere. What's to stop a Rust programmer from avoiding error types? Furt
Re: (Score:3)
I'd prefer a trained, diligent C++ programmer over any programmer who thinks Rust will solve all the problems and so can't be arsed to learn how to use libraries correctly.
Would you take this one step further, and prefer a trained, diligent assembly-language programmer over any programmer who thinks C++ will solve all the problems and so can't be arsed to learn how to use libraries correctly?
If not, why not? All your reasons for preferring C++ over assembly also apply (at least in principle) to the case of someone else preferring Rust over C++. It's just another evolution of the programmer's toolkit towards better fitting what the world's software requirements are in 2020..
Re: (Score:2)
back in 1985, when C++ was being designed
C++ is still being designed and today is suitable for internet-facing security issues.
Maybe people should actually keep learning C++ instead of assuming it stopped improving in the 90s.
Re: (Score:2)
C++ is still being designed and today is suitable for internet-facing security issues.
It's being augmented, yes. But one of the goals of C++ is 100% backwards compatibility with existing code, and while that's completely understandable (they don't want to introduce any Python-style codebase schisms) it also means that almost all of the original design (and design mistakes!) of the 1985-era C++ language is still there, ready to bite every unsuspecting C++ programmer, and it will always be there. There's nothing anyone can do about it other than keep telling people on StackOverflow that they
Re: (Score:2)
But one of the goals of C++ is 100% backwards compatibility with existing code
No it isn't. It aims to maintain backwards compatibility as much as reasonable. Plenty of thing have now been deprecated and will be removed in future versions. It also hasn't imported some of C99s more controversial additions, like VLAs.
(for whatever value of "the new way" is fashionable this year).
So you dismiss updated features in C++ as "fashionable", but find it completely acceptable that Rust doesn't even care to maintain backwards compatibility and programmers also have to learn what's fashionable with a new release of Rust. Will you stake your life on there nev
Re: (Score:2, Informative)
Will you stake your life on there never being StackOverflow posts that tell Rust developers what the new thing is?
Of course not. All languages evolve. But I will stake my life on nobody ever having to tell a Rust developer that they should be using (the Rust equivalent of) std::string for their character-strings instead of const char *, because with Rust, the latter simply isn't an option anyway.
There's some weird double standards you Rust developers have.
I don't know why you think I'm a Rust developer. I write almost exclusively in C++, and have done so for my entire professional career. That doesn't make me blind to the potential or actual benefits of Rust, though. C++, w
Re: (Score:2)
Of course not. All languages evolve.
Then why was it even an argument? It's basically a retreat to "Rust is better because it's newer" because it's had less time to develop newer options.
while a useful tool, is showing its age in the form of decades' worth of accumulated cruft.
So when something shows its age, abandon ship? Bodes well for Rust.
Yeah, no thanks. I prefer a language with a sensible upgrade path to better features, rather than switching languages and rewriting everything every decade. Accumulated cruft means accumulated testing of existing libraries and programs, since they all still compile and work (and also benefit
Re: (Score:2)
Would you take this one step further, and prefer a trained, diligent assembly-language programmer over any programmer who thinks C++ will solve all the problems and so can't be arsed to learn how to use libraries correctly? If not, why not?
Actually, yes. But nice of you to presume to know my answer.
If any programmer who thinks C++ will solve all their problems and so don't require training and diligence, I'd sooner delete their software from my system. Such programmers, no matter the language, do not have the ATTITUDE required to write safe software.
Re: (Score:2)
I'm just barely old enough to remember when a "regular" application programmer could dig all the way to the bottom of the OS internals. No way I could do that now, and it isn't just because I've become so much stupider over the years. The OSes really have gotten MUCH more complicated and I frequently wish there was a path to more simplicity.
As I spend more and more of my time on embedded systems, usually without an OS, to me it seems that the path to more simplicity is to simply use less tools. Use thinner libraries.
Re: (Score:2)
Basically concurrence, though you may be talking about focus?
Re: (Score:2)
I have seen no evidence that degreed engineers write better code than CS people. My personal experience is that the opposite is true.
I know a lot of degreed electrical engineers. The vast majority know, at best, python and Java and most only know python. Nothing inherently wrong with that, except 1) when they come to me with coding questions, it becomes pretty obvious they don’t really understand some very basic stuff - they’ve basically “learned” python via numerous stack overflow searches, with no systematic knowledge at all; and 2) they think python should be used for everything, and can’t grasp that a la
Matlab? (Score:3)
The PhD electrical engineers I know use Matlab and think if you are using anything else, you are wasting time on coding your algorithms from scratch and not writing enough journal papers.
The younger generation is Python-centric, where a a computer language not tied to a single, proprietary, commercial implementation is a step in a positive direction.
Who in Electrical Engineering is using Java? I asked this question when I walked by a student with his head down in a laptop, editing Java code in Eclipse
Re: (Score:2)
I'm on the support staff side of things, not faculty. I know we have one somewhat older faculty member (and possibly one other) who is Java-centric - many of the students end up first learning Java during his courses, but I'm betting they forget it soon afterward.
Our younger faculty have turned away from Matlab, for the most part. And they've even managed to convert a couple of the older faculty to python! I'm not actually anti-python, I think it's very useful for a lot of things... it's just that these guy
Re: (Score:3)
The problem we have is not inadequate tools, it is inadequate coders.
You can improve the tools. You aren't going to improve the people.
If your solution relies on "better people" then it isn't a solution at all.
Wrong. If you were right, we would not have any highly competent engineers. Or any brain-surgeons. What you do is a) be a lot more selective and b) treat the experts well, so really smart people will find the field attractive. As it is currently, coders are often treated as really cheap technicians and it is no surprise most of them have no clue what they are doing.
Re: (Score:2)
What you do is a) be a lot more selective
That obviously doesn't scale.
If you figure out how to hire better people, that leaves worse people for everyone else. The average coder is going to be the same.
Of course, you do NOT have a magic formula for hiring better programmers, and neither does anyone else. Hiring is hard and certainly isn't a silver bullet.
coders are often treated as really cheap technicians
What?? Programmers are paid higher salaries than any other BS-level profession.
Re: (Score:2)
Programmers are paid higher salaries than any other BS-level profession.
Ah, so you think that programming is a BS-level profession. Interesting.
Re: (Score:2)
Programmers are paid higher salaries than any other BS-level profession.
Ah, so you think that programming is a BS-level profession. Interesting.
Yep. Quite telling.
Re:Does not matter (Score:4, Insightful)
I have seen no evidence that degreed engineers write better code than CS people. My personal experience is that the opposite is true.
If you could be permanently banned from professionally writing code like a professional engineer can be for approving faulty plans you would see a marked improvement with code quality.
The problems with how shitty code is made are many-fold, but the main ones are time pressure to make it cheaper, and extremely low cost for failure on the part of the authors. At least that's my view from the point of a programmer who's been doing this shit professionally since the late 80's.
Laughably counter-factual. "Everybody code" isn't (Score:2)
> you aren't going to improve the people.
> better hiring and better education haven't made software problems disappear.
That's laughably counter-factual. We're in the age of "everybody should code". We have fresh graduates *designing* corporate information systems whom would barely be qualified to code individual functions under the direct supervision of a seasoned engineer in my mom's day.
We have literally 10,000 as many people writing software and that's not because the requirements for getting a p
Re: (Score:2)
Most new programmers today probably don't even know what I linked list *is*.
Fun story: I ~recently had a job interview in front of a room full of programmers. I solved a problem on the whiteboard, partially using a linked list.
The interviewers didn't understand what I had done, and I had to spend several minutes explaining it.
Re: (Score:2)
Regardless of the validity of the post you're responding to, real progress is made when you 'improve' both the tool and the person wielding it (skills, knowledge). Both improvements go hand in hand and reinforce each other.
Re: (Score:2)
You aren't going to improve the people.
You can. I train them to be better.
Re: (Score:2)
So teams are a spectrum and mistakes will happen. Rust tries to stop mistakes from compiling and even produces helpful error messages to try and explain the issue - you're trying to reference something which was only temporary etc. It trains programmers to think
Re: (Score:2)
> it is inadequate coders.
I thought it was object oriented coders? Refusing or being sanctioned by your instructors or your supervisors for looking beyond the small, designated part of the problem you're working on is a popular source of security failures when software is used in unorthodox or unexpected ways. Every host needs a powerful anti-virus package, and direct admin access for the security team? Then the security team becomes the vulnerability, and poor handling of their credentials becomes the
Re: (Score:2)
Most people who hate OOP are Javascript programmers, and that's mainly because the syntax and semantics for classes in Java suck.
Re:Does not matter (Score:5, Insightful)
So first I want to talk about the underlying issue you bring up, and then second talk about how none of that relates to what THIS paper says.
The problem we have is not inadequate tools, it is inadequate coders.
I think this is the completely wrong way to think of this issue. There's literally nothing wrong with a hammer. But you are a fool to use a regular hammer to put shingles on a modern roof, especially when nail guns exist. Yes, you can absolutely put a roof on with a hammer, but your time to delivery for that roof is going to be measured in weeks not days.
There's nothing wrong with C. But C isn't a tool that's going to get to goal faster than Rust, just point blank. There's things the Rust compiler won't allow you to do. That limits you. If those limits are fine with your project, then you no longer ever have to worry about those details. You can go faster to the goal. Now not everyone is in a race. Sometimes, it's not about time to delivery. Cool, check out C then. Or there's some other variable that dictates to you that you should go with C. There's so many things for consideration, there's no one person that can enumerate them all. The thing is that there are people who want to warp this into a discussion about good and bad programming. The reality is that you have a language that allows you to ensure that a subset of the nasty stuff that comes with C, never comes into the picture. So you needn't ever worry about it. Sometimes that's what you want. Sometimes not. Pick the right tool.
And that said, yeah there are people who have no idea how to use a damn nail gun. So I think your argument is a false dichotomy, it can absolutely be both, either, none of the above, and different degrees of both. But I think it's super dismissive by some people who hold to C like some religion, that some people want different tools.
These come from broken hiring, broken education and the demented misunderstanding that coders do not need to be engineers
And these are society things. Computers and programmers aren't here to fix those people. Computers answer to humans, and if the humans are insane, then we need a computer that can work for those insane people. But you're putting a lot of blame on things that C nor Rust nor Java can fix, and that feels a lot like you're trying to steer the discussion away from on-topic things.
All other technological fields restrict tasks on the difficulty level of writing code to engineers
No they don't. There are analyst that need SQL. There are mathematicians that use Julia. There's Wall Street hotshots that have things in VBA or python. Computers are everywhere and coding them have also become an everywhere thing. The days that the code was restricted to the old men in the basement are long dead. Are you saying those people don't need to code? Or that their coding isn't REAL coding? Because I would argue that they would think otherwise, especially if the things they are doing are actively helping a company or themselves.
Unless and until we have that for code as well, things will _not_ get better
That is a massive underselling of humanity. We're just too dumb to make a machine that will work for the masses? This is an incredibly silly take.
There are plenty of severe vulnerabilities in things written in memory-safe languages
Yes, but they're not the same kind of vulnerabilities found in non-memory safe languages. But that said, this isn't even a good argument. There are vulnerabilities in every language. The thing that differs is the kind and scope. If you've got people that are good at catching type ABC and not so good at catching XYZ type, then it kind of makes sense to use a language that doesn't allow the XYZ type so that your team can focus on the type they're good at catching. AND YES, people who are good at catching
Re: (Score:2)
Kind of long, but well written and you sucked me into reading the whole thing. This is a case where having an "Insightful" mod point to give would be better than a reply. Too bad I never get a givable mod point these years. (How about if we got a givable mod point for each 10 received? (Yet another crazy solution approach, eh?))
I admit that after a while I was looking for something like "Tis the poor craftsman who blames his tools." My extension (which applies to your position) is "But it's the worse crafts
Experimental nail gun (Score:2)
Your analogy about using a nail gun instead of a hammer on a roofing job would be apt, were it not for the nail gun being in a sub 1.0 version number and subject to frequent upgrades and revisions?
And the nail gun accepting the kind of nail needed for your project being planned for the next nail gun release?
Re: (Score:2)
Re:Does not matter (Score:5, Interesting)
I've heard this nonsensical argument time after time, and the argument never gets any less specious. "We just need coders who don't make mistakes" is not a practical solution. Yes, by all means, improve your training and discipline for better results, but in the end, we're all human. We make mistakes, whether through carelessness or ignorance. Nothing will prevent that, especially in a language, like C, in which memory-related mistakes, which so often turn into security vulnerabilities, are so easily and trivially made by the slightest mental misstep.
Rust is an effort to bring memory safety by default to a high efficiency compiled languages. I'm not some Rust fanatic (I'm a C++ programmer by trade), but Rust clearly has some significant advantages when used in safety-critical applications. In two well-publicized studies of a large codebase written in C/C++, it was shown that roughly 70% of security issues tended to be memory-related issues. It's a ridiculous straw man to claim that Rust advocates pretend the language will solve all security related issues. No one with a brain is claiming that. But it's highly likely that Rust will tend to eliminate a very large percentage of what would otherwise be accidentally introduced memory-related issues, if the same functionality were written in C, given the same level of programming competence.
I'm not bashing C, as I love the simplicity and elegance of the language myself, nor do I necessarily think Rust is the answer to all security problems, nor is it a practical replacement for all C-based code at this point. However, it's beyond foolish to simply deny some of the practical advantages Rust has brought to the table, such as it's memory and thread safety programming model.
Re: (Score:2)
I've heard this nonsensical argument time after time, and the argument never gets any less specious. "We just need coders who don't make mistakes" is not a practical solution. .
Your statement just shows you are arguing in bad faith.
What we need is coders that a) make exceptionally stupid mistakes only rarely and b) understand both security and redundancy. To many of the current crop fails both a) and b) and no tool is ever going to fix that.
Re: (Score:2)
If you think that in the real world we are going to find coders who are statistically any better than the current crop, then you're an idiot.
Since you're an idiot, you surely can't be trusted to code in C. Maybe you could be given an assignment in Rust.
Re:Does not matter (Score:5, Interesting)
The problem is you don't need to make an "exceptionally stupid" mistake in C to introduce a memory-related error, which often turns into a security bug. It's ridiculously trivial to do so, and can be obscured by the logic of surrounding code very easily.
The entire point of a security-focused programming model like Rust is to allow programmers to concentrate on avoiding higher-level logic bugs. There is only so much cognitive room in even the best programmer's brain. Doesn't it make sense to actually use tools to fix the low-hanging issues, allowing them to spend more of their brainpower ensuring they can avoid the remaining 30% of typical non-memory-related security issues?
I'm not disputing that a focus on proper techniques and theory is important for programmers working on front-line code with security requirements. Yes, by all means, let's hold programmers to a higher standard and raise the bar where we can. But I'm also pragmatic enough to understand that programmers, no matter how skilled, are always going to make mistakes. Simply insisting they be (nearly) perfect, is just a way of obliquely ignoring the problem. It's making perfect the enemy of good.
Re: (Score:2)
I've heard this nonsensical argument time after time, and the argument never gets any less specious. "We just need coders who don't make mistakes" is not a practical solution.
In the 1980s, auto manufacturers were looking for assembly line workers that didn't make mistakes. It didn't work well for them.
Toyota decided it was impossible to find a human that doesn't make mistakes. They implemented a system called Poka-yoke [wikipedia.org], to reduce the number of mistakes an assembly line worker could make. It was a huge success, and allowed Toyota to dominate the auto industry.
We're in that same situation with software development. Rust is a poka-yoke for software development.
Re:Does not matter (Score:5, Insightful)
That's not how problems are solved properly in reality. For good problem solving we need to accept that people are imperfect, and that we need to design systems and contingency plans for that.
That's how we have safe aviation. Not by blaming the pilot for everything, but by using every accident as an opportunity to see what could have been done to make sure everybody made it out alive. Even in the cases where the pilot was a moron and did something completely unnecessary, we almost always find something that could have been improved on the technical or procedural side of things.
Re: (Score:2)
That is my point. Actual engineers _know_ they make mistakes. They also know what they are doing and know how to put in redundancy. Coders these days can very often do neither and that is why we have so many really stupid security and other problems with software. This is not a problem any "tool" can ever fix. It is a problem of the wrong people with the wrong education.
Re: (Score:3)
We're not agreeing then.
What I'm saying is that with important things like aviation, we're not stopping at "blame the pilot". We also iterated designing better airplanes. Sometimes the blame is squarely on the pilot, and yet we still try and think of what design improvement to the airplane we could make so that it had a better chance to land with the wrong person at the controls.
So yes, better tools do fix problems. A huge amount of advancement was made by making better tools, and this extends to pretty muc
Re: (Score:3)
Sometimes the blame is squarely on the pilot, and yet we still try and think of what design improvement to the airplane we could make so that it had a better chance to land with the wrong person at the controls.
Absolutely! If the pilot was an idiot, chances are another pilot will sooner or later be the same idiot. Better to save lives than rag on both pilots.
I just don't get this guy. He says "real engineers know they make mistakes" then loses his shit when real engineers figure out a way to completely elim
Re: (Score:2)
Seriously? The "pilot" is a _user_. We are talking airplane design tools here, not airplanes. You seem to not understand your own example or maybe you do not know what a programming language is.
Computer Science (Score:2)
All other technological fields restrict tasks on the difficulty level of writing code to engineers.
Not at all. Engineers are simply not qualified to deal with many of the tasks most scientific fields need code for. Coding is a skill more like writing. There are some times you need a professional coder to deal with software infrastructure etc. in which case I would hire a computer scientist, not an engineer. Other times you need someone who understands the data or hardware they are interacting with and who can also code in which case you need someone with the relevant knowledge who could be a scientist o
Re: (Score:2)
You missed the point. He didn't say that engineers should or should not be coding. His argument wasn't about that. What he was saying is that in other fields tasks that are comparable in difficulty to coding in the software field, are not just done by anyone. They are done by people who have to through a certification process, who are sanctioned by their professional organizations if they stuff up etc.
When building a bridge you hire an engineer not a pastry chef who has decided to be an engineer. Sadly i
Re: (Score:2)
His argument wasn't about that. What he was saying is that in other fields tasks that are comparable in difficulty to coding in the software field, are not just done by anyone. They are done by people who have to through a certification process
Re: (Score:2)
His argument wasn't about that. What he was saying is that in other fields tasks that are comparable in difficulty to coding in the software field, are not just done by anyone. They are done by people who have to through a certification process
You are wrong and ignore reality. It is as simple as that. These mystical "has the required skills" basically never pans out in actual reality without the formal qualification being present as well. Also, Physicists rarely design electronics. They may design measurement instruments, but if you look more closely, you will find an electronics technician somewhere in a lab that did the actual electronics (if simple) or an EE (if complex).
Re: (Score:2)
These mystical "has the required skills" basically never pans out in actual reality without the formal qualification being present as well.
Quite a few of the physics students and even postdocs I have worked with over the years have ended up in EE jobs in industry. You can try to tell me that this did not happen but the great thing about reality is that it did happen whether or not you believe it.
Re: (Score:2)
Re: (Score:2)
Thanks. That is exactly my point. And until that is fixed, software will continue to suck.
Re: (Score:2)
Coding is a skill more like writing.
Not at all. But that utterly stupid idea is responsible for most of the problems we see with software.
Re: (Score:3, Interesting)
Re: (Score:2)
The problem we have is not inadequate tools, it is inadequate coders.
If you have studied actual engineering then you would know that modern safety systems try to make sure that humans simply CAN NOT make a mistake.
These come from broken hiring, broken education and the demented misunderstanding that coders do not need to be engineers.
I see that you've flunked your safety engineering courses.
Re: (Score:3)
I am a PhD-level engineer. You have no clue what you are talking about. Your posturing is pathetic and clueless.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Nope. But you are either stupid or arguing in bad faith. Understanding redundancy and understanding what you are doing and understanding software security are not "never make mistakes". They are what many, many coders fail at though and that is the problem.
Newer is not always better? (Score:2)
Interesting to note that this comment [from gweihir] was promoted to FP by deletion of some trollage. I sort of approve, but it carried my prior diversion with it. For those who are interested, such a reply is not actually deleted, but just unlinked. Didn't even know the body could be recovered from my personal page... Since I tried to include a bit of substance, I decided to repost it (below). However my real objective would be to reply to someone who apparently replied to my comment, and now I don't see a
Re: Does not matter (Score:2)
I'm a C++ developer, and I've been trying to work in top teams throughout my career, which has mostly been the case, with startups, academia, small business-focused firms.
A few years ago though, I joined a large corporation, where IT is a separate division from the business. Way lower standards in hiring, quantity over quality, slow red tape and most employees are just corporate drones who don't go the extra mile.
I had no idea that people with 10+ experience in writing C++ code professionally could be so ba
Re: (Score:2)
Both things are real problems.
Inadequacies in tools come in multiple kinds. Lack of a compiler for a given platform would be one kind. Lack of self-hosting making it dependent on a second- or third-party compiler is another. Rust became self-hosting in 2011 but still has inadequacies. Rust has "tier 1 [rust-lang.org]" support only on x86[_64] and everything else is less well-supported. Tier 2 means "builds but not necessarily tested", so tier 2 builds may not actually function. That means that you can only "count" on Rust
Re: (Score:2)
There are plenty of severe vulnerabilities in things written in memory-safe languages. That alone shows these efforts and the promises made by the Rust people are, at best, misdirection and at worst lies.
Name these vulnerabilities
Re: (Score:3)
You can’t have proper engineering without known materials and science. We have smart engineers in other fields today, but if they didn’t have the centuries of material science, physics, and other research to build on, what could they actually do? They’d be left trying to apply some best practices and making the best guesses they could, which is basically where developers find themselves today in a field that has only had a few decades to figure out what “engineering” even looks
Does not allow what the programmer wants to do (Score:2)
Such as assignments and branches?
(not a joke -- doesn't Functional Programming have such a restriction?)
Re:Does not allow what the programmer wants to do (Score:4, Informative)
Sadly, no. (Score:5, Insightful)
This proof, called RustBelt, is complemented by Ralf Jung with a tool called Miri, with which 'unsafe' Rust code can be automatically tested for compliance with important rules of the Rust specification - a basic requirement for correctness and safety of this code.
The problem with this statement is that Rust does not have a formal specification of any sort. What it does have is an ever changing reference [rust-lang.org] which they are likely using as a specification.
There is a very important difference between a specification and a reference. The reference may change over time but a formal specification is etched in stone forever. This is extremely important if you want to make a compiler for a programming language otherwise you will always be second fiddle to the compiler that the reference is based off of. This constant state of change is why there aren't any other working compilers for Rust and why no company has bothered making a Rust compiler of their own.
Re: (Score:2)
This constant state of change is why there aren't any other working compilers for Rust and why no company has bothered making a Rust compiler of their own.
Why would you do this anyways? We're in an era where the diversity of platforms continues to shrink. Most of the unix based services have long since moved to linux, and end user applications are mostly consolidating to the web, windows, mac, and to a lesser extent, linux, all of which are natively supported by Rust. If you're building a new cpu architecture, your best bet is to just add support for it in LLVM, GCC, etc, then from there its easy to make all of the languages supported by those to compile to y
Re: (Score:3)
Why would you do this anyways?
Because "one size fits all" is a myth, you want special optimizations for a specific platform, you don't want to be reliant on a single third-party group for the continuity of your product, you want a compiler that has actual paid support, or a dozen other reasons.
Seriously, how do you not understand this?
Re: (Score:2)
It's even worse, without a rock solid specification, you risk the language being irreparably forked.
One reason iOS did not support Flash was that Apple didn't want to depend on Adobe to add support for iOS
Re: (Score:3)
Why would you do this anyways? We're in an era where the diversity of platforms continues to shrink. Most of the unix based services have long since moved to linux, and end user applications are mostly consolidating to the web, windows, mac, and to a lesser extent, linux, all of which are natively supported by Rust. If you're building a new cpu architecture, your best bet is to just add support for it in LLVM, GCC, etc, then from there its easy to make all of the languages supported by those to compile to y
Re: (Score:2)
You write as though building a compiler were something exceedingly difficult.
Re: (Score:2)
The problem with this statement is that Rust does not have a formal specification of any sort.
Good point.
Nice try, trolls. (Score:2)
Pretty sure tetanus is still a thing. So, shan't bother reading beyond the clearly-idiotic headline here. Cheers~!
Nice solution, wrong problem (Score:3)
I think some aspects of Rust's solution to memory problems are nice. Other languages (e.g. Clean) have something similar for certain kinds of Rust-like pointers. All power to them.
My primary problem with Rust, and indeed all new programming languages, is that to my mind they are solving the wrong problem. Even if I had an amazing language that could check complete correctness of a program (without me writing a spec) -- an Oracle (queue up the jokes about Oracle) of sorts -- this would improve my performance as a programmer by very little. Why? Because the coding part of programming is a very small part of my job. The thinking part where I understand the problem, ask a client what they are talking about, figure out failure modes, etc is where I spend the vast majority of my time.
And no I am not a manager, I am a day-to-day programmer.
Re: (Score:3)
A. Be extremely complex
B. Put you out of a job
The less time you spend on menial tasks, the more time you have to solve real problems.
Re: (Score:2)
Re: (Score:3)
If only 5% of my time is spent coding then Rust's checks are optimizing that 5% ... To me that's the wrong thing to be optimizing.
Software development has been around a very long time. If a tool could be created that reduces the workload by 50%, it would have been done a long time ago. This is the "low hanging fruit" at the moment. At this point, tools require a lot of development, for a small return.
Caveat Emptor, Seekers of the grail! (Score:3)
As an analogy, Rust's safe mode, is like adding a saw stop ( Rust Rules/Constraints ) on a table saw ( C, C++, etc ). Touch the blade while it is spinning, and an emergency brake halts it in milliseconds; you get to keep your fingers.
It may prevent the carpenter from injuring themselves while doing the carpentry, but a safe carpenter, can still build a dangerous guillotine, or gallows, or a customized Trebuchet.
To push the analogy just a little further, failure to select correct data structures, or enumerate all options in a switch, is rather like failing to select the correct joinery (interfaces), right type of wood/material, of the correct strength, for the expected loads and use-cases. Mastery and Experience matter and cannot be supplied by any tool.
The problem for the buyer is, Construction time safety, is neither necessary, nor sufficient, to guarantee end-user safety, or fitness for purpose, during use.
A guillotine with a missing safety catch, a gallows with dodgy steps, a Trebuchet that snaps under load, are all potentially lethal design faults, to the unwary user, especially during the popular "let's have a revolution" use-case ( a rarely specified test-case, but popular in France ).
Rust is a limited safety improvement, mostly because one-fingered woodworking developers, are an inefficient and sad lot.
The downside: HR-know-nothings will be told "10 years Rust experience"==" Safe Hire Coder", Sales will think "Rust"==" Must-Have New Hype" and Marketing Press Releases will be updated, "Rust"==" Buzzword Compliant Pitch Deck".
Companies will now advertise their, old, unsafe, design and construction as New Rust-Safe products, with happy shots of some ten-fingered development interns, picking their noses, while launching cows in your general direction.
The whole thing falls apart when the customer mentions, in an email to the Agile nose-picking lead, that they are looking forward to testing the new stainless steel, guillotine blade throwing Trebuchet, next week. However, they no longer want the gallows front end, because the business sponsor died, horribly, when the steps collapsed unexpectedly, during a sales presentation.
NSA loves/hates provable security (Score:2)
Modula-2 (Score:2)
I was doing some of this type of stuff in Modula-2 a few decades ago. The mainstream wasn't ready for type safety yet, so it's in the dustbin, and we've continued to have memory management related issues. (Modula-2 let me do unsafe stuff, but in specially-marked modules.)
Re:Obsessed (Score:5, Insightful)
I more or less viewed it that way at first. Then one day I got bored and decided to give rust a try.
The first real shocker is that the community is super supportive of new users. It seems even the most seasoned experts are willing to answer newbie questions, and some very very good rust developers frequent stackexchange to help new users (shout-out to Shepmaster.)
The second real shocker is just how friendly the compiler is and just how amazingly good the tooling is. The compiler explains what's wrong with your code in a way that's easy to understand and even suggests fixes, rust analyzer is amazingly useful by showing what data types you're working with and offering tons of refactoring automations, and cargo makes building and compiling your applications, complete with managing dependencies, a total breeze, and the tooling is intuitive enough that you rarely need to find a manual to find out how to do something.
The third real shocker is just how expressive the language is. It really does not feel esoteric at all, in fact it's rather intuitive, and you can tell the designers went way out of their way towards this end. The only reason rust is perceived as hard to learn is because it introduces several programming concepts that are totally unique to rust: The ownership model, the borrow checker, option, and result. The borrow checker is a blessing in disguise. It actually ends up compelling you to write your code in a way that is less prone to bugs, and when you start to think in its terms, and you carry that coding style to other languages you'll find that you create less buggy code in those other languages. Option and Result may seem like they get in the way at first, but they give you confidence that you can write your code without running into anything that would cause a runtime error unless you specifically tell it to, and they're a hell of a lot easier to work with than exception handling.
Oh and did I mention that it's very close to the metal, there's no garbage collector yet you still don't have to manually deal with memory management, and it's also memory safe?
Re: (Score:2)
That's great. But why does Slashdot/BizX talk about it so much? No one cares about Rust or wants to use it. No other languages are discussed here. Why Rust?
Re: (Score:2)
Because Rust is new, growing and making a steady stream of new developments?
Really I don't think talking about any other language would make much of an improvement. I don't think the the crotchety old nerds here would appreciate talk about C++23 all that much more than Rust. As I see it anybody keeping up with the times has already moved on for the most part, the ones that remain here seem to be mostly stuck in the 80s.
Re: Obsessed (Score:2)
So I think you're wrong. It
Re: (Score:2)
Well, the two first at least. Option and Result types are standard functional programming patterns, don't know how old they are in that world but Haskell 98 standard had Maybe (the same as Rust Option) and IOError (basically the same as Rust Result).
Re: (Score:2)
Re: (Score:2)
One minor niggle: Option and Result are not unique to Rust, Haskell has them under the names Maybe and Either, and it wouldn't surprise me if the concept is even older than that. Agreed that they're very useful abstractions, either way.
Re: (Score:2)
Safe Rust prevents data races - concurrent unsynchronized reading and writing to the same address - not race conditions in general. It's always been very clear on this. It is not Rust which has a narrow definition of race condition. You'll notice even the slashdot submitter has got the terminology right. It was you who brought up the term "race condition".
You can perfectly well write Rust code that does other things in unpredictable order. But data races have to be prevented to guarantee memory safety. With
Re: (Score:2)
My bad! Read the summary wrong!
Re: (Score:2)
You can perfectly well write Rust code that does other things in unpredictable order. But data races have to be prevented to guarantee memory safety. Without safety from data races, you can never assume e.g. that a mutable function pointer actually points to a function, and before you know it you're executing garbage.
This makes no sense. The hardware already does this for you. I dare you to write a c program that switches the value of a function pointer concurrently in multiple executing threads to any of a preset list of functions and read out garbage that does not correspond to address of one of the functions. The only way to do it is to go out of your way to make the pointer unaligned.
Re: (Score:2)