what's so safe about unsafe rust?

i myself do unsafe to make syscalls

Wow... only 20-30% is really shit, especially when you remember that C#, PHP, and JavaScript are memory safe.... and PHP still has a server share of (unverified source) 75%...

No thanks, i'll stick to C.

Saying writing safe C is easy and you just have to get used to it, is like saying you can stir fry chicken with your barehand you just have to get used to it.

Love your vidoes and the way cover topics. Have you looked into Dynamic Linking (or Shared libraries) in Rust? Would like to hear more opinions about this. Personally it would interest me to have such functionality.

Note how these safety features in Swift and Rust stand on your way when implementing simple things like binary protocols. The added complexity can lead to more errors and performance degradation. Give a critical project to negligent people and watch it burn.

I'd love to see a discussion on modern c++, and how that counts as safe or not, or how to write safer c++

Rewrite rust in rust to make rust safe

Rust is like a condom. When used as intended they are 99% safe

Fuck rust. Zig 10/10

Unsafe isn't actually unsafe.
My disappointment is immeasurable. and my day is ruined. I will now learn rust and use unsafe everywhere.

I hope you're happy.

How does rust work for microcontrollers? Writing to memory has inherent side effects that the compiler can't know about. It feels hard to have memory safe code if the memory goes and changes values when you aren't looking

Are/would you consider adding Rust or Zig courses to the Low Level Academy in the future?

"not calling destructors is consider safe - because memory leakage is considered safe"

I am developing a python library and it's main dependency is another library that's basically python bindings for a rust backend via ffi.
Bug I run into tons of rust panics or hangs. And it's not trivially understood or even debugged. So I might need to really learn rust to fix some bugs up-up-up-upstream.

Some of my code is really awful because I am constantly cresting new descriptors and stuff because nothing seems to be reused, mutable or even just pointing correctly. But its graphics programming so the rules change quite a bit.

any language is safe if you use it as intended. the whole point is nonsense.
what's more interesting is the ways in which rust is unsafe if you don't use the unsafe keyword. there are some really interesting memory and lifetime bugs in rust that have been around for a long time. There is a whole repository Speykious/cve-rs with memory corruption, lifetime extensions, double free, use after free and all kinds of other bugs, and all without unsafe.
The main problem is people writing C in C++, teaching C before C++ and using C instead of C++, where C++ offers mechanisms and idoms that kill 99% of all memory related bugs. Use references instead of pointers, use smart pointers, use iterators instead of indexing, use std::array or other container classes instead of raw arrays. Use the standard library instead of rolling your own, probably slower, and likely buggy data structures.
The problem with C is that it is barely above assembly. It was meant to be easier to write and understand than assembly code, and that is exactly what it does, and it does it great. But you basically get the safety of assembly as well, which is non existent. What C++ gives you is mechanisms to write code that is difficult to use wrong. But it is backwards compatible with C. Then 70 year old professors teaching C++ teach C to the students because that's how they learned C++, and then tack on whatever is new in C++ as if it's just extra features. That is not how that works. C++ is backwards compatible to make the barrier to entry lower and to make porting of C applications easier.

Most of the top crates use unsafe as that's the only way to get all the performance. As such most likely a lot of the code you use will have unsafe in the libraries used. And that's fine.

Started with Python. Studying C now using the Zig compiler to compile C code. Rust may have the spotlight but Zig is pretty awesome too and easy to work with.

It's like people still using raw pointers in C++ because the second you use smart pointers everything breaks because they are safer and then all of the horrible practices that had been used don't work... and people moan that they are not good enough and continue using raw pointers. At least rust forces you to specify you are about to break things

I'm thinking lately that my dream language would be something as simple of possible, like C with something like the built-in standard library of Python to back it up and perhaps some of its keywords (with, in and exceptions).

Rust, not Zig, is the future of safe and reliable software? Dang it. I just started learning a bit of zig...

The most idiotic sentence is "Rust is not memory safe because we can write unsafe rust"
It's like saying nail cutter isn't safe because it can cut my toung

I have participated in an ai programming contest recently in rust, and was forced to use the unsafe « global static », which was( to my limited knowledge) the only way to store information between calls to to the player_turn function.

As a formal methods fanatic, we could benefit greatly from logic and proof system for safety inside unsafe blocks

SDR, Downgrade Attack (Changing LTE to GSM).
Attacker collects your device information? For what?
With Device ID can other attacks be performed? Push? Install? MITM apps? Keyloggers?

What is the worst that can happen?

I think the most important misconception about "unsafe" Rust on the Internet is, that after "unsafe" anything and the opposite may happen at the same time and chaos may arise. That is not true. It is somewhat true when calling into external non-Rust-Code, as developers may do anything they want there with Rust-provided data structures, returning them in a state that will crash Rust code sooner or later (most likely by deallocating those structures without having ownership). but within Rust, regarding memory safety the only relaxation is that you may use raw pointers to data. With those pointers you may do anything you want and of course they have the potential to mess things up notably - but for all other types in Rust the standard rules still apply.

Where I used the unsafe keyword yet (aside from calling ffi) was to check whether bounds checks in indexed access into arrays hurt performance. One can get rid of those bounds checks by using a.get_unchecked[i] or a.get_unchecked_mut(i) instead of a[i], both calls are "unsafe" for obvious reasons, but if you are able to prove that i is well within bounds all the time (which Rust sees only on some very simply-structured occasions), you can go for it and nothing will break. But for some other features of Rust not directly related to memory safety, one is rarely using indexed access into arrays or vectors at all. Iterators are so much more efficient and powerful in Rust. And they are the fastest fancy for loops you can get in Rust. Almost always better then an old-school procedural approach. Never worse.

100% "safe Rust" is not safe by any reasonable definition of the word "safe."

A lot of unsafe exists in mutable iterators, simply because borrow checker is too restrictive. A container that is otherwise 100% safe, would still require unsafe for a mutable iterator.

I dont think Rust is more difficult than C/C++, I think they are on the same level of difficulty, I think though that C/C++ is a more stable foundation to begin learning because of Rust's more "modern" features.

I think the amount of Rust unsafe calls might decrease in the future if developers put an effort to rewrite those crates that use unsafe to make calls to foreign functions.
For example, I think most crates that deal with database connections, Vulkan API binding, OpenGL binding, device drivers etc are written in C/C++, not in Rust, so if these API bindings get re-written in Rust then this will reduce the amount of unsafe calls. 🤔

I feel like there's a similar mental reminder with requiring to explicitly define an unsafe block that happens when forcing to handle errors. By forcing developers to actively do something, it reminds us that something can go wrong.

I will never accept tha CISA/DISA statement on code safe languages, not because I don't think its an important point to make, but just because it feels like a such a buck pass for the overall security issues in both public and private infosec applications not just within US infrastructure but outside of it as well.

I love rust. The whole memory safety thing makes the compiler intimately familiar with your code so you get correctness for free. Correctness being how accurately the contacts you've defined operate by the rules you intend for them to follow.

Would the compiled unsafe code be distinct from safe code , would the compiled protective mechanisms or their absence give away a section of a program that is unsafe. You talked of when auditing sources for unsafe key word your attention would be raised, I wonder if possible detecting the absence of the safety mechanisms in compiled code would also possibly be a red flag to a hacker, "here is where to start looking".

rust std library also full of unsafe code. There’s no escaping unsafe even if you took away the c bindings

c isnt the problem
humans are the problem
we just prefer to externalize blame
accountability is the great filter
love your videos

Would love to see an unsafe rust vs zig video

I mostly exist in high-level data wrangling land, but this channel has been extremely interesting to me. Thanks for breaking it all down for us!

Could you please cover cve-rs (a repo which contains some examples of how to corrupt memory in 100% safe Rust)? Would like to know how it works and how the Rust team will fix it.

I have a unsafe macro in rust, and it's called trustme

Whats unsafe about rust? The users mental state after using it.

Run Cargo-Geiger on your favorite crate that has substantial dependencies. Rust still builds superior software and the abstractions possible in the syntax are extremely underrated (traits, blanket impls, macros etc) as a consideration for the languages value. Theres a lot to be done in language research and Rusts ambitions have definitely left some syntactic loose ends but having gone back and Forth from Rust to C etc. Rust is objectively better for what it sets out to accomplish.

I agree more with Jonathan Blow

There was an error in this video: line 69 is always good code.

Miri is an amazing tool. They keep a ledger on their github of bugs that they have found in prominent crates.

You need unsafe for things I consider fairly safe in rust - ie, casting a struct to a byte slice, even if the struct implements Copy.