[3a2d29]

Right but if you imported one of those crates, then your “safe” rust would have memory safety issues.

So bam, you just introduced memory safety issues into your web API. This is like a C++ dev using C++ and causing memory issues unnecessarily just because they don’t want to use a safe language.

And Elixir has concurrency and memory safety and it’s guaranteed, so no package you import can violate it. Unlike rust, where you can use safe rust and think there’s no violation, but then use a crate and suddenly have memory unsafety and concurrency violations.

These crates worries are wayyy better than normal C++, but they are terrible compared to any actually safe language.

[josephcsible]

My program might also crash if there's a bug in the kernel's filesystem driver, but that's not my bug. And Elixir has FFI, which definitely lets you do unsafe stuff.

[3a2d29]

It’s not about crashing, it’s about exposing memory that could lead to security vulnerabilities.

And FFI? As in the Unix extensions? That’s the operating systems calls, not the language. By that logic, python is as dangerous as C++.

It’s crazy how so many people on this thread say rust is the only choice because of memory safety, and are now bending over backwards trying to claim memory safety is no big deal. So much so FFI is now being brought up smh.

[josephcsible]

If "import ctypes;ctypes.string_at(0xdeadbeef)" in Python doesn't count as memory unsafety, then I don't see why the equivalent in Unsafe Rust would.