The difference is that when you are forced to declare where your program does not follow some safe semantics, while it's still trivial to write an overflow, it's also trivial (or at least not nearly as complex as some alternatives) to find and fix, compared to a language where the entire code base is a possible source for those problems.

For comparison, I would say C and C++ (but to a slightly lesser degree) are also trivial to write buffer overflows in, it is definitely non-trivial in many cases to find and fix those problems, as the surface area is so large.

To illustrate this, it's trivial to write a buffer overflow in almost all languages that provide any sort of raw memory access or hardware instructions (ASM), even if through a module. It's trivial for me to create a buffer overflow in Python or Perl my including a module that allows direct assembly code access. The difference when using those languages is that when I run into a buffer overflow problem, I can be reasonably sure it's in a place where I bypassed the assurances provided by those languages, or in some included module that did the same (including just using a shared library). When tracking down a problem like that, I'll focus my attention on those spots, which makes identifying and hopefully fixing those problems easier.

Rust's "unsafe" is really an in-language way to provide a similar set of levels of assurance about how likely the code is to have problems of specific types, with assurances provides by the language and compiler. This is a step above what C and C++[1] provide, and thus welcome.

1: C++ provides some similar assurances based on types, but by nature of how "safe" code becomes "unsafe" when used in conjunction with unsafe portions, is much harder to assess at a block level, since you can't even be sure a line is safe until you've verified all the types used within it.

For embedded code, I'd recommend that all application code should be compiled with the `--deny unsafe-code` option. Then the compiler will stop you. A separate module for the I/O code providing is the only place where one should use `unsafe`. Extra care must be taken here, in code review and in testing.

Do you have any idea how impossible it is to do anything useful without unsafe in Rust on a microcontroller?

About as hard as on desktop? I mean, many of the core datastructures commonly used there are implemented using unsafe. This does not mean that the application code must or should be riddled with unsafe code blocks... For a very simple example see https://github.com/hackndev/zinc/blob/master/examples/blink_...

If Ada, Pascal and Basic can, so can Rust.

Every case where this is not true is a bug.

You can also get a buffer overflow in Python and Java by abusing their equivalents of "unsafe".

"unsafe" in Rust isn't abuse. It's explicit syntax with compile time effects specifically for the purpose of facilitating unsafe constructs, like direct memory buffer manipulation, required for low level programming.

I've never tried the Python or Java equivalents and frankly don't know enough about them to even know whether your comment is accurate or not.

Java has `sun.misc.Unsafe`, and Python has the FFI which is remarkably easy to misuse. The point is that you don't use these unless you need to, and you spend special effort when you do - same as `unsafe` in Rust. The rest of your code runs perfectly safely, and the vast majority of code has no need to use `unsafe`. Code which uses `unsafe` and isn't obviously either directly an FFI wrapper or a straightforward implementation of a generic data structure is generally considered bad form.

True that unsafe isn't considered too wrong in rust, but auditing the small amount of unsafe code is much easier than all the code.

Is getting that past the person who is reviewing your code also trivial?

Possibly. Depends on the quality of the reviewer and the complexity of the code (as a whole). On average Rust programmers aren't necessarily better than programmers using any other language. If history is a guide then if Rust takes off there will be plenty of terrible, buggy, unsafe and very thoroughly reviewed Rust code out there used in popular, widely used applications or services.

I find the notion that "explicit unsafe makes bugs less likely" to be suspect. It seems reasonable, almost tautological at first glance. But theory and practice are different animals.