6 ms·

I don’t why people keep finding one GC language that has unsafe, then declaring my argument wrong. My point is you can find a safe GC language with all the ben

by 3a2d29 4y ago

I don’t why people keep finding one GC language that has unsafe, then declaring my argument wrong. My point is you can find a safe GC language with all the benefits of rust.

josephcsible 4y ago
The quantifier I infer from "GC languages simply will not allow it" is "all", not "some". Anyway, can you name such a language then?
- 3a2d29 4y ago
  Are you gonna argue that no GC language exists that is more safe than rust? There were over 200 memory safety violations discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ Elixir for example, is very safe and guarantees more safety than rust.
  - josephcsible 4y ago
    Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?
    - 3a2d29 4y ago
      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 4y ago
        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 4y ago
        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 4y ago
        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.
        3a2d29 4y ago
        josephcsible 4y ago
        I am not a beginner. Those sorts of security vulnerabilities are possible in Python/Elixir/etc. In both Rust and Python/Elixir/etc., they're only possible when you do certain unusual things. You are claiming that the Rust way does count, but that the other languages' ways don't count, with no justification. Memory safety does matter. Rust is memory-safe and C++ is not, so your conclusion doesn't follow.

by 3a2d29 4y ago

I don’t why people keep finding one GC language that has unsafe, then declaring my argument wrong. My point is you can find a safe GC language with all the benefits of rust.

josephcsible 4y ago

The quantifier I infer from "GC languages simply will not allow it" is "all", not "some". Anyway, can you name such a language then?

3a2d29 4y ago
Are you gonna argue that no GC language exists that is more safe than rust? There were over 200 memory safety violations discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ Elixir for example, is very safe and guarantees more safety than rust.
- josephcsible 4y ago
  Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?
  - 3a2d29 4y ago
    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 4y ago
      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 4y ago
        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 4y ago
        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.
        3a2d29 4y ago
        josephcsible 4y ago
        I am not a beginner. Those sorts of security vulnerabilities are possible in Python/Elixir/etc. In both Rust and Python/Elixir/etc., they're only possible when you do certain unusual things. You are claiming that the Rust way does count, but that the other languages' ways don't count, with no justification. Memory safety does matter. Rust is memory-safe and C++ is not, so your conclusion doesn't follow.