Rust Foundation Reports 20% of Rust Crates Use 'Unsafe' Keyword (rust-lang.org) 92
A Rust Foundation blog post begins by reminding readers that Rust programs "are unable to compile if memory management rules are violated, essentially eliminating the possibility of a memory issue at runtime."
But then it goes on to explore "Unsafe Rust in the wild" (used for a small set of actions like dereferencing a raw pointer, modifying a mutable static variable, or calling unsafe functions). "At a superficial glance, it might appear that Unsafe Rust undercuts the memory-safety benefits Rust is becoming increasingly celebrated for. In reality, the unsafe keyword comes with special safeguards and can be a powerful way to work with fewer restrictions when a function requires flexibility, so long as standard precautions are used."
The Foundation lists those available safeguards — which "make exploits rare — but not impossible." But then they go on to analyze just how much Rust code actually uses the unsafe keyword: The canonical way to distribute Rust code is through a package called a crate. As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword [according to numbers derived from the Rust Foundation project Painter]. Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.
Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++. In fact, the crate with the most uses of the unsafe keyword is the Windows crate, which allows Rust developers to call into various Windows APIs. This does not mean that the code in these Unsafe Rust blocks are inherently exploitable (a majority or all of that code is most likely not), but that special care must be taken while using Unsafe Rust in order to avoid potential vulnerabilities...
Rust lives up to its reputation as an excellent and transformative tool for safe and secure programming, even in an Unsafe context. But this reputation requires resources, collaboration, and constant examination to uphold properly. For example, the Rust Project is continuing to develop tools like Miri to allow the checking of unsafe Rust code. The Rust Foundation is committed to this work through its Security Initiative: a program to support and advance the state of security within the Rust Programming language ecosystem and community. Under the Security Initiative, the Rust Foundation's Technology team has developed new tools like [dependency-graphing] Painter, TypoMania [which checks package registries for typo-squatting] and Sandpit [an internal tool watching for malicious crates]... giving users insight into vulnerabilities before they can happen and allowing for a quick response if an exploitation occurs.
But then it goes on to explore "Unsafe Rust in the wild" (used for a small set of actions like dereferencing a raw pointer, modifying a mutable static variable, or calling unsafe functions). "At a superficial glance, it might appear that Unsafe Rust undercuts the memory-safety benefits Rust is becoming increasingly celebrated for. In reality, the unsafe keyword comes with special safeguards and can be a powerful way to work with fewer restrictions when a function requires flexibility, so long as standard precautions are used."
The Foundation lists those available safeguards — which "make exploits rare — but not impossible." But then they go on to analyze just how much Rust code actually uses the unsafe keyword: The canonical way to distribute Rust code is through a package called a crate. As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword [according to numbers derived from the Rust Foundation project Painter]. Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.
Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++. In fact, the crate with the most uses of the unsafe keyword is the Windows crate, which allows Rust developers to call into various Windows APIs. This does not mean that the code in these Unsafe Rust blocks are inherently exploitable (a majority or all of that code is most likely not), but that special care must be taken while using Unsafe Rust in order to avoid potential vulnerabilities...
Rust lives up to its reputation as an excellent and transformative tool for safe and secure programming, even in an Unsafe context. But this reputation requires resources, collaboration, and constant examination to uphold properly. For example, the Rust Project is continuing to develop tools like Miri to allow the checking of unsafe Rust code. The Rust Foundation is committed to this work through its Security Initiative: a program to support and advance the state of security within the Rust Programming language ecosystem and community. Under the Security Initiative, the Rust Foundation's Technology team has developed new tools like [dependency-graphing] Painter, TypoMania [which checks package registries for typo-squatting] and Sandpit [an internal tool watching for malicious crates]... giving users insight into vulnerabilities before they can happen and allowing for a quick response if an exploitation occurs.
Well, so much for that empty promise (Score:3, Interesting)
I am just surprised that they admit this themselves. The problem is, of course, that the typical Rust coder has no clue what "standard precautions" are here and is very likely to mess it up.
Re: Well, so much for that empty promise (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
The problem is, of course, that the typical Rust coder has no clue what "standard precautions" are here and is very likely to mess it up.
It's much less likely that the Rust coder writing a little shim to call an external library will mess up than it is that the C coder who wrote the library has already messed up. The library has orders of magnitude more code to mess up, and C has orders of magnitude more "standard precautions" that must be manually juggled.
Re:Well, so much for that empty promise (Score:5, Insightful)
Despite all the derision Rust gets for "unsafe", and the predictions that unsafe will plague Rust code, this survey finds that over 80% of all crates.io code don't use it and those that do are mostly using it for C interop, where is it inherently unavoidable.
That looks like an admirable result to me.
Re: (Score:2)
Maybe. How many programs use that 20%? Is the "unsafe" tool required, or does it just make things easier? What is the updating protocol?
It still sounds better than Javascript. And one must remember that EVERY C program does the equivalent of using the unsafe keyword.
That said, I find Rust abhorrent. This is a matter of personal taste. I like the idea that it pushes, but in practice I'd even rather use SPARK (Ada).
Re: (Score:3)
Maybe. How many programs use that 20%? Is the "unsafe" tool required, or does it just make things easier? What is the updating protocol?
From the summary, the majority of unsafe calls are to non-Rust libraries like C and C++. At that point Rust cannot guarantee the memory safety of another language. It does however highlight where problems could occur. Those libraries may need some focus.
Re: (Score:2, Funny)
That said, I find Rust abhorrent. This is a matter of personal taste. I like the idea that it pushes, but in practice I'd even rather use SPARK (Ada).
Ada is still a language where, if you have no data to return, then you simply return an invalid pointer and expect that the caller already knows not to dereference it without checking first. Basically like handing somebody a loaded gun with a round chambered and assuming that they'll just check to make sure the safety is on because it's expected to do so anyways. Sure, even if they don't, most of the time nothing will go wrong.
Most of the time...
https://www.rollingstone.com/t... [rollingstone.com]
(Sorry, this joke had to be m
Re: (Score:2)
How many programs use that 20%? Is the "unsafe" tool required
I'd expect that nearly all programs are obligated to use dependencies that use "unsafe." That's the nature of adapting to a world where 99% of the OS functionality is in C/C++, and you have to use unsafe to talk to it.
Re: (Score:1)
Re: (Score:2)
Despite all the derision Rust gets for "unsafe", and the predictions that unsafe will plague Rust code, this survey finds that over 80% of all crates.io code don't use it and those that do are mostly using it for C interop, where is it inherently unavoidable.
It's only 20% that use "unsafe" now. Probably still too early to tell which way it's going to go. Hopefully better, maybe worse -- slowly eating away any benefits, like... What's that thing that happens to iron over time when exposed to oxygen? :-)
Re: (Score:2)
On the other hand, what would you think of the characterization that while you need to mark sections as "unsafe" in Rust, in C and C++ all code is implicitly "unsafe", they just don't have a way to annotate it?
I know which body of code I would enjoy more when reviewing it.
Granted the shared^mutable rule can be easy to break, giving the compiler free reigns to break it in the optimizer.
I'm glad for articles like this. (Score:5, Funny)
I'm glad for articles like this because slashdot reliably has such measured opinions about Rust, C, C++.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: I'm glad for articles like this. (Score:2)
Re: (Score:2)
Re: (Score:2)
That's going a bit too far. shared_ptr does get over-used quite a bit by people who don't want to reason about lifetimes, however on occasion a need may arise to share some data between threads and it really is impractical or impossible to determine which thread will exit first so a shared_ptr really is the best solution.
Shared ownership is not the best way to handle most data, but in situations where shared
Re: (Score:2)
Re: (Score:2)
Sometimes that's the right way to go especially if that data might be reused multiple times in the future, but then each child thread needs to explicitly communicate back with the main thread so the main thread knows when it's safe to delete the data and that is going to involve some kind of synchronization.
I generally try to avoid locking mutexes when terminating threads as much as possible because it's very easy to get a deadlock that way. If threads can just end without any need for explicit synchronizat
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
eh? im going to need an example here.
No. It's not my job to educate you. Fuck your needs. If you had any significant experience you'd already know what I was talking about.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
You just need to use smart pointers properly.
Then why is it no C++ developers can actually manage to do so? Not even the so called good ones. In Rust, smart pointers are all there is. Sure, you can create raw pointers, but unless you use unsafe you can't actually do anything with them.
(Not really a fan of Drew DeVault, but he makes good points here: https://drewdevault.com/2019/0... [drewdevault.com])
Re: (Score:2)
Re: I'm glad for articles like this. (Score:2)
But isn't that what every C++ developer says? Basically everybody but themselves are incompent. That everybody but themselves doesn't use smart pointers correctly.
Why weren't they just designed so that they can't be used incorrectly in the first place? That's the approach rust took, and it's already proven to work. Sure, you can misuse them in ways that are suboptimal, unergonomic, or unidiomatic, but you can't inadvertently use them in a way that will cause your program to crash, or worse, create a silent
Re: (Score:1)
Re: (Score:3)
I'm glad for articles like this because slashdot reliably has such measured opinions about Rust, C, C++.
In my head, I always imagine these particular discussion posts happening between multiple clones of the Simpsons' Comic Book Guy.
Re: (Score:2)
I can feel my neckbeard sprouting as I read the comments in this thread. I want to reply but...
Further Proof Rust on Linux Kernal is Sabbotage (Score:4, Interesting)
Re: (Score:3)
There's a valid argument to adding the SILK parallelism extensions to GCC and Clang, then seeing if these could improve Linux kernel performance.
There's a valid argument for using SEL4's theorem idea and writing theorems for core components, like the memory manager, to establish correctness in sections of code small enough and structurally simple enough for this to be doable.
Rust is currently slower (but not by much) than C, but does offer a few gems to improve robustness. Which, of course, you wouldn't nee
Re: Further Proof Rust on Linux Kernal is Sabbotag (Score:3)
Rust is currently slower (but not by much) than C, but does offer a few gems to improve robustness.
It's hard to overstate just how little of a difference it is. Some researchers actually put out what is likely the most useful, meaningful, AND practical measurement for this, which is in terms of power consumption.
https://thenewstack.io/which-p... [thenewstack.io]
Spoilers:
These numbers are normalized so that the most efficient is a 1.0, higher numbers are less efficient:
C: 1.0
Rust: 1.03
C++: 1.34
Ada: 1.7
Java: 1.98 (this actually surprised me; ada is almost as inefficient as java, apparently, or java is almost as efficient a
Re: Further Proof Rust on Linux Kernal is Sabbotag (Score:4, Insightful)
I'm sorry, but I don't see how this is an argument for including Rust code in the kernel. The prior argument was that maximizing human understanding would argue against that. And it's definitely clear that requiring someone to be expert in both Rust and C is a higher requirement than only requiring them to be expert in C.
Re: (Score:2)
I'm sorry, but I don't see how this is an argument for including Rust code in the kernel.
The argument is that Rust is nearly as efficient as C and more efficient than C++. In addition to that Rust has better type and memory safety. Naysayers has said that type safety could be done in C++. Yes but at the cost of efficiency.
Re: (Score:2)
Naysayers has said that type safety could be done in C++. Yes but at the cost of efficiency.
But they've still yet to actually even pull even that off.
Bjarne Stroustrup did his bizarre "call to arms" speech in response to this with his key argument being that there's more to safety than memory safety. Problem is, when you listen to his words carefully, his definition of memory safety seems to be extremely narrow. It seems like his only definition of it is temporal safety, which yeah, there's more to memory safety than temporal safety, but it seems like he wants to brush that aside solely because it
Re: (Score:2)
I'm sorry, but I don't see how this is an argument for including Rust code in the kernel.
It wasn't meant to be.
The prior argument was that maximizing human understanding would argue against that. And it's definitely clear that requiring someone to be expert in both Rust and C is a higher requirement than only requiring them to be expert in C.
I wasn't making any argument about this, but I'd argue C is harder than Rust. Sure, C is small and well-defined, but much of what you do with it is well-defined as being undefined in very subtle ways that arguably takes at least a decade to get (mostly) right. C++ on the other hand is just an ultimately pointless extension of C, and I completely understand why Linus Torvalds doesn't want it.
Re: (Score:3)
If you think C++ is pointless, you haven't tried to implement a hash table in C. But they are a standardized part of C++. There are many other examples. But this is NOT an argument for including C++ in the kernel.
(Yes, you can add libraries to do in C what C++ includes as part of the standard. This makes things much more fragile. Which is why Python comes with all those libraries attached as a part of the standard build.)
FWIW, in the section of developer space that I typically operate in C++ appears to
Re: (Score:2)
If you think C++ is pointless, you haven't tried to implement a hash table in C.
I have. Hundreds of times.
The only thing I can imagine that C++ adds to that is some neat overloading syntax, and a gigantic performance-consuming dildo rammed up your ass.
So what they're saying is (Score:2)
Rust programmers need a safe word. Banana is a good one.
Re: (Score:2)
The fundamental fallacy that C code is a flaming security disaster is just not true. Given the number of exploits found related to buffer management (as opposed to logic/design errors or race conditions, etc. where things are comparable in the Rust world) is actually quite small when you look at the sheer amount of C code out there. There are tons of embedded systems running the world, programmed i
Re: (Score:2)
The fundamental fallacy that C code is a flaming security disaster is just not true.
No, C++ code is the flaming security disaster. For C, I think the argument is that large C codebases are a potential security disaster.
A good analogy I'm sure everybody can relate to is writing big code projects purely in dynamic scripting languages. The reason for this is basically that you don't have a compiler there ensuring you're doing things like properly re-initializing variables between for loops so that you're not carrying over data from a previous iteration and getting confused looks from your pee
Re: (Score:1)
I disagree: C++ is just a flaming disaster all around. Readability and maintainability are pretty poor in C++. It's hard to even lump C++ code into a single style. Some C++ code is mostly OOP relying on virtual functions (how I write C++). Some C++ code is mostly template driven and a bit like macro-heavy Scheme code. There's straight C with C++-isms and of course modern lambda-heavy C++.
C++ is very design by committee, IMHO.
Re: (Score:2)
For C, I think the argument is that large C codebases are a potential security disaster.
I've been a professional C programmer for several decades, and as much as I adore the language, this can absolutely be true.
As for the perl, perl has 100% lexical scoping- there's never a need to reinitialize any variable.
Any block is a new scope, and you can put one anywhere. It need not be tacked to an anonymous sub, or a flow control statement.
use strict;
use warnings;
If you don't- you're a criminal.
If you were literally referring to that gigantic fucking bash script- well ya. Big bash scripts ar
Re: So what they're saying is (Score:2)
I've never been able to entertain the idea of writing anything in perl, only fixing somebody else's broken script. Its syntax honestly bugs the crap out of me. Though in addition to bash, the problem I'm describing is definitely there in python, PowerShell, and beanshell. If you haven't heard of beanshell, then don't google it unless you want PTSD.
Re: (Score:2)
Its syntax honestly bugs the crap out of me.
I'll be the first to admit it's an acquired taste, like kimchi extracted from an elephant's ass.
However, there are very elegant and beautiful aspects to the language once you get to know her.
Though in addition to bash, the problem I'm describing is definitely there in python
My interaction with python has been like your interaction with perl- I've only really touched it to fix broken things.
It feels too much like Visual Basic to me. I don't see the allure to it at all.
PowerShell
Can we maybe both agree that PowerShell is nastier than the nastiest perl?
I've never seen anything drop my typing rate fr
Re: So what they're saying is (Score:2)
There is none. Either it's satisfied or it tells you to get your clothes on and get out.
Re: (Score:2)
Rust programmers need a safe word. Banana is a good one.
+1 Funny - if I had mod points
Re: (Score:2)
I'd say "Sunstone", but that's just a waste of a perfectly good safeword...
Rust is a good language (Score:4, Interesting)
But throughout history, there have been many good languages, especially ones that had one or two clever features absent from others that made a big difference.
Most of these languages (Eiffel, Nim, Ada, SPARK, Tcl/Tk, LISP, Forth, MUMPS, Oberon, Ruby, Occam, Erlang, Haskell, MARS D, PL/I, etc) had some time in the sun, and a few of these are still very popular in niche fields. But they never took the world by storm. Perl, which DID take the world by storm, suffered from some disastrous politics and over-ambitious updates and has all but been replaced by Python and PHP, where PHP is itself withdrawing to more of a background presence.
All but Occam will survive, sure, but as tiny islands that can't survive in the longer term. Occam is functionally extinct, which is a shame as it had by far the best IPC system and multithreading system of any language.
SILK was an ingenious parralel extension to C, but it exists now only in an extension to Intel's compiler. Nobody else has reimplemented it and it's not in the standard. Is Unified Parallel C still a thing? A lot of other parallel extensions have died - the ATLAS library tried a few and found it made the code slower.
But Fortran (which has implicit parallelism) and COBOL are recovering, and C/C++ are still fighting hard. Java nearly died during the dot com era and Oracle has been sabotaging it ever since, but it might endure despite their best efforts.
Rust might endure and even replace one of the Lovecraftian Great Old Ones. It easily could. It's a strong language with a lot of support. But so did other languages whose stars have faded. It cannot and should not be taken for granted that Rust will join the Ancient Ones and become essentially immortal.
(Python shouldn't assume it either, given what happened to Perl and what is happening to PHP.)
Fortelling the future of programming languages is a dangerous game, and as Galadriel, top geek in Lothlorien, once said, for telling is in vain and all paths may run ill.
Re: (Score:1)
Some of your stuff is funny, your money and insurance are moved by COBOL and/or Java, as are the resources ERP/MRP of the biggest companies on Earth. Billions of lines of COBOL and the enterprise Java will be around for decades. It never waned.
Occam? Yes good design but ha, never saw it after decades in engineering, hard science and now multi-tier mixed services architectures, it's dead if it ever was alive and was used for anything major? Survive where?
The numerical libraries built in ForTran are all
Re: (Score:2)
BLAS and Lapack were converted to C years ago.
Less sure about the NAG libraries.
Re: (Score:1)
you sure? the reference implementation is in Fortran, there are C and Fortran binding for the API to the BLAS and Lapack libraries
Microsoft made a C implementation, but what serious place would use that?
https://en.wikipedia.org/wiki/... [wikipedia.org].
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
I've been told that Go's "goroutines" and channels supposedly were designed after the same CSP [wikipedia.org]-formalism.as Occam.
I which ways do you think Go's concurrency is deficient compared to Occam's?
Re: (Score:2)
Go's concurrency model is a lot like Erlang's.
Re: (Score:2)
Occam supported implicit and explicit parallelism (the PAR keyword) and could enforce sequential processing, overriding the optimiser, if necessary (SEQ).
It supported process migration over a cluster, but more crucially supported the MOBILE keyword that allowed data structures to also migrate.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The transputer was a marvellous device that really got CPU manufacturers into considering multi CPU systems. It's a shame they never got the T9000 working properly.
If I get a chance, I might try to rehabilitate the KROC Occam compiler.
Re: (Score:2)
Languages, like all platforms, survive thanks to killer apps. We use the languages we do because we have to, not because they are good.
That's why the Rust people are fighting so damn hard to get it integrated into the Linux kernel. Once that happens, it guarantees it will survive and we will have to use it whether we like it or not.
Re: (Score:2)
get it integrated into the Linux kernel. Once that happens, it guarantees it will survive
HAHAHAHAHAHAHAHAHAHA!
Anyone making that statement clearly doesn't even read the kernel's git log....
Aah, reminds me of mutable, const, and const_cast (Score:4, Insightful)
Re: (Score:2)
Rust is no more than a tool like the rest of them. If you are going to assume disaster at-best with one, you shouldn't compare it to another where that assumption is false. I.e. Rust assumes disaster by it's programmers and it's assumption drives it's design. C / C++ / etc. assumes that programmers will be more responsible and trustworthy, and that assumption drives it's design. Comparing the two is comparing Apples to Oranges. Both will feed you,
Exception for unsafe is valuable (Score:4, Informative)
It's good to allow unsafe code (we've done all along) and it's also good that it's pushed into a small section and labeled unsafe.
Re:Exception for unsafe is valuable (Score:4, Informative)
It's good to label code unsafe if and only if it is actually unsafe.
The keyword gives the wrong connotation for what code in those blocks is. The code in those blocks is merely not subject to some of the compiler rules. That is it.
I know why the language creators chose that word, but that word choice is (mis)leading. In fact, if I was running a Rust project, I would ensure that code inside the unsafe blocks should actually be the most safe code, because it should be subject to the most diligent review and testing possible.
The vast majority of my career is in safety-critical (as in, if it breaks it causes physical harm, not merely causing offense or financial issues) systems, and one rule about safety is that if you assume your tools are going to make you safe, you will fail. Tools can help you be safe, but what makes you safe is diligence, not tooling or testing or any other such thing.
Calling something "unsafe" when it's not gives false understanding about the entire codebase, and false understanding causes all sorts of problems that cannot be solved by technology.
Re:Exception for unsafe is valuable (Score:4, Funny)
Well it would be awkward to label it failsOurAlgorithmicCheckForSafetyButMightStillBeSafeAndTheSafeCodeMightBeUnsafe.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
With regard to marketing...well...The main thing you can say about Rust is that it's the only language that not only has already delivered everything it promised, it continues to deliver a hell of a lot more on top of it: Performance in excess of what it even set out to be, easy as hell parallelism and concurrency that actually works and intuitively so. Turns out all you had to do to get all of that was set a few strict but simple rules around pointers.
Re: (Score:2)
Re: (Score:2)
That's an unproven assertion. It reminds me of the claim that every language needs to allow unguarded array access of long jump. It *may* be true, but perhaps we just haven't come up with the correct abstraction.
OTOH, if you mean that deep under the hood, there will be unsafe mechanisms used...yeah, that's going to be true. At least with all existing cpus.
But since the existence of labelled break statements, I haven't been convinced that a raw goto was needed in high level code. And FWIW, I had to check
Re: (Score:2)
No, I'm making a logical argument. Type information cannot just be propagated - at some point it must have been created. For example a keyboard driver reads 2 bytes (or whatever it is) from some hardware memory address and says 'this value is a character code' - an unsafe operation, in the sens
Re: (Score:2)
That's an unproven assertion. It reminds me of the claim that every language needs to allow unguarded array access of long jump. It *may* be true, but perhaps we just haven't come up with the correct abstraction.
Don't be absurd.
At some point, you must interact with the CPU, and it is memory-unsafe by design.
It doesn't check the bounds of your array dereference, because it has no fucking idea what an array is.
Re: (Score:2)
I think my point is that it comes down to what you mean by "unsafe." Code isn't safe or not because of the language it uses, or what is checked by the compiler, etc. It is safe by what it does and does not do.
Sure it's splitting semantic hairs, but it's important to know that the safety comes from the principles and structures used, not the tools! What you get from the tooling is efficiency when implementing those principles and structures. Which I grant is indeed quite valuable, especially in a world w
Re: (Score:2)
It's good to allow unsafe code (we've done all along) and it's also good that it's pushed into a small section and labeled unsafe.
And here is the part you forgot to add in your statement:
And that small section that is labeled 'unsafe' is then quickly jettisoned overboard onto a sulfur-fueled h3ll of a planet.
Training wheels (Score:2)
Rust is also kinda dumb/pedantic, is kinda toxic (Score:1, Informative)
One of the big issues with rust is the fact that it's so pedantic, but doesn't actively have a reason for a lot of that. The language designers don't really care about the language itself being useful to people. They just want to have a place to be as pedantic as possible.
For example, if you just simply want to define a string constant in rust, its harder than it should be. Why? Because they want to be pedantic instead of helpful.
Example:
pub const CONSTANT_STRING_DERP: String = "derp";
That wont compile.
pub
Not surprised (Score:1)
Literally 0% of C code contains the unsafe keyword (Score:2)
Just sayin'
Shouldn't we expect MORE unsafe in libraries? (Score:1)
Pardon my Rust ignorance, but when I read about it some years ago, I understood "unsafe" to be a keyword to mark sections that perform necessary operations that are not possible when under the safety rules of the compiler. So long as it is implemented correctly, there is no problem, but the unsafe keyword makes it so such sections of code are extra-visible to review processes.
Seems fine to me, no? Or is it possible to do *everything* in a "safe" way?
One valid use for AI is to transform old code (Score:2)