321–330 of 403 posts
Earlier quoted context omitted.
No, people are not claiming Rust cannot have any problems. UB is not possible in safe Rust, by design. The root cause of UB is always in unsafe code. Miri is useless if your code is 100% safe Rust. The only exception to this is bugs in the compiler, of which there are a few. They’ll be fixed.
I have no faith in this statement. Let's see how it plays out.
Earlier quoted context omitted.
This is the exact formulation of the argument before computers beat humans at chess, or drew pictures, or represented color correctly, or... Self driving cars will be solved. There is at least one general purpose computer that can solve it already (a human brain), so of a purpose built computer can also be made to solve it. In 10 (or 2 or 50 or X) years when Chevy, Ford, and others are rolling out cheap self driving…
> These problems really aren't analogous. I'd put money on the solutions to said problems looking largely the same though - big ass machine learning models. My prediction is that a tool like copilot (but specialized to this domain) will do the bulk of source code conversions, with a really smart human coming behind to validate.
The director orders the use of the tool when the dev team got downsized (and the two most-seniors left for greener pastures just after that). Validation is in the "extensive" tests anyway, we have those, right, so the new intern shall have a look, make it all work (fudge the tests where possible and remove the persistently failing ones as they've probably been always broken). The salesman said it comes from the DOA or DOD or something. If the spooks can do it so can we.
Earlier quoted context omitted.
Ok, but if it's like 90% of small projects can use it as direct no pain bridge, that can be a huge win. Even if it's "can handle well 90%" of the transition for any project, this is still interesting. Unlike cars on the road, most code transition project out there doesn't need to be 100% fine to provide some useful value.
Even if every project can only be 90% done, that’s a huge win. Best would be if it could just wrap the C equivalent code into an unsafe block which would be automatically triaged for human review. Just getting something vaguely Rust shaped which can compile is the first step in overcoming the inertia to leave the program in its current language.
It'll be great for "pure" functions. For the grimey parts of the world, funcs taking pointer args and returning pointers, for things that access and modify global data without locks, for threaded code with implicit (and undocumented) locking, the tool would add most value. If it can. Even only by saying "this code looks grimey. here's why. A bit of FFI will also be thrown in because it links against 100 libraries. I suggest changes along those lines ... use one of the 2000000 hint flags to pick-your-evil".
a) if every C program could be translated into an equivalent safe Rust program, that would mean that each C program is as safe as the safe Rust equivalent. b) since there are C programs that are open to memory currption in a way safe Rust isn't, this corruptability would need to be translated into partially unsafe Rust. Congrats, you now have a corruptible Rust program, what's the point again?? c) so DARPA must be tr…
Memory corruption is undefined behavior and means the compiler is free to do anything it wants. Anything it wants... and that includes doing something entirely safe and reasonable. If you write out of bounds, the compiler is allowed to shut the program down in a controlled manner. It's allowed to transparently resize the array for you. Etc. Hence a rust translation can do these things.
If the compiler can, compile-time, detect that code is prone to memory corruption, it can warn the developer.
If it can't detect it at compile time, will and shall it add some sort of magic signal handler heuristic to determine whether a segfault occurred due to a runtime-provable specific instance of memory corruption and hence format your harddrive, while for runtime-indeterminable kinds it'd rather fry cpu core seven preemptively ? But that behaviour changes in the next version to blink sos on the network cable leds ?
I mean, it were cool if compilers used their "freedom" here to output nagging messages "the mem-safe UB brigade told you so, told you so, told you so ...". The fact they don't tells me, at least, that compiler developers follow Postel's law - be strict at what you emit but lenient at what you process. They're reasonable people. Not some sort of crusader out there to get you in the most excruciatingly painful ways. Undefined behaviour isn't unreasonable behaviour.
A lot of people are reading this as a call or demand to translate all C and C++ code to Rust, but (despite the catchy project name), I don't read the abstract in that way. There are two related but separate paragraphs. 1. C and C++ just aren't safe enough at large. Even with careful programming and good tooling, so many vulnerabilities are caused by their unsafe by default designs. Therefore, as much code as possible…
> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of rules to use here you're just going to end up right back where you started. > to migrate to safe languages, which Rust is an example of Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not g…
I'm reminded of Darpa's old plans for Ada. I expect we'll see the same issues come up as the last time they tried this.
Thus the push for C and C++, alongside security certifications, where those languages feel like using Ada with a C like syntax.
https://www.perforce.com/blog/kw/NASA-rules-for-developing-s...
https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf
Nowadays we live in a world where developers refuse to pay for their tools like other professionals, but hey, Rust is free beer, not like the several millions per seat licenses used by Ada vendors, of whom there are still 7 vendors in business.
They didn't explain why they've chosen Rust. There are a lot of memory-safe languages besides Rust, especially in application-level area (not systems-level like Rust).
It is the systems-level code with UNIX heritage that is the main problem.
Technically, Zig has this functionality built in via translate-c, but it's designed for reading by a C compiler, not a human
Well, the main idea is memory-safety. Zig is certainly better, but not as memory-safe. PS: Java or even JavaScript are memory-safe :)
Definitly better than plain old C, but not what is being looked for here.
Earlier quoted context omitted.
GCC contains `gnat` which is a libre Ada compiler. I think Ada has a lot of technical merit but it's just not fashionable the way Rust is, for lots of uninteresting reasons.
I remember Ada getting pushed in a time when there were many in the computer industry that were pushing Pascal as both a systems and a teaching language. Ada was a lot like Pascal which I think caused an immediate violent reaction in some people. (e.g. the implementers of every other programming language were pissed that BASIC was so hegemonic but they never asked "Why?" or if their alternatives were really any bette…
It could have pushed for more Pascal adoption.
Then again, Borland also did their own mess, when decided enterprise should be their customer focus, not the small developer communities.
Why not Ada or Zig?
Ada, is not popular enough, is my guess. To be fair, writing everything in Ada Spark would make code way more secure, simply because you'd need to write your pre-condition, invariants and post-conditions upfront, and prove they hold, but no one seems to want to think about lifetimes, let alone think about programming in more mathematical terms.