4 ms·

> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of

> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of rules to use here you're just going to end up right back where you started. > to migrate to safe languages, which Rust is an example of Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not get you very much. Meanwhile you have tons of garbage collected languages that don't even let the programmer touch pointers. Why aren't those considered? The reason is performance. And because Rust programmers "care" so much about performance you're not ever going to solve the fundamental problem with that language. Do you want performance or safety? You can't have both.

selfmodruntime 2y ago
> It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This is largely untrue. You can use proven abstractions over 99% of cases that would require unsafe.
timeon 2y ago
> To do anything interesting you will require unsafe blocks. This will not get you very much. This is not true.
- akira2501 2y ago
  > This is not true. Burying unsafe blocks in unevaluated cargo modules does not make this true. You're just taking the original problem and sweeping it under the rug.
  - selfmodruntime 2y ago
    You can rely entirely on crates that disallow unsafe to be included.
  - commodoreboxer 2y ago
    You can do tons of stuff with purely safe Rust. The main things that you can't do are FFI, making self-referential structures, and dereferencing raw pointers. And unsafe isn't a problem. It's a point of potential danger to be heavily audited, tested, and understood. Having the entire language unsafe by default is an obviously worse situation. This is throwing the baby out with the bathwater, like rallying against seat belts because you can still die while wearing one. An improvement is still an improvement. I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good.
    - techbrovanguard 2y ago
      > I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good. if you've convinced yourself that you're special and all problems with c are solved by trying harder, clearly everyone else is just lazy. with that line of logic, there's nothing to fix with c. rust is not just redundant, but also aggravating, since its popularity causes the cognitive dissonance to start creeping in. maybe i can make mistakes? should we improve tooling somewhat? no, it's the children who are wrong.
      - talldayo 2y ago
        > all problems with c are solved by trying harder, clearly everyone else is just lazy. If you're even remotely familiar with professional C development then you should know this is unironically true. Tooling does exist to offer memory-safe features in C, they're just far more complicated than using a safe language from the offset. Nobody wants to use Valgrind when your linter can do the same job without leaving your editor. Most of today's high-performance C code is compiled using the same IR that LLVM generates when compiling C. Unless you're a GCC pundit it doesn't make sense to reject the direction the industry is headed in. > maybe i can make mistakes? should we improve tooling somewhat? After a while, being allowed to make mistakes starts to pile up: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
bigstrat2003 2y ago
> Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not get you very much. 1. There are plenty of interesting programs which don't require unsafe. 2. Even if your program does require unsafe, Rust still limits where the unsafety is. This lets you focus your scrutiny on the small section of the program which is critical for safety guarantees to hold. That is still a win.
techbrovanguard 2y ago
> To do anything interesting you will require unsafe blocks this is just flagrantly false, have you no shame?
pjmlp 2y ago
People still die while wearing seatbelts, helmets and motorbike protective gear, body armor, bullet proof vests, yet many more survive, than those not wearing any of those in similar situations.

selfmodruntime 2y ago

> It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This is largely untrue. You can use proven abstractions over 99% of cases that would require unsafe.

timeon 2y ago

> To do anything interesting you will require unsafe blocks. This will not get you very much. This is not true.

akira2501 2y ago
> This is not true. Burying unsafe blocks in unevaluated cargo modules does not make this true. You're just taking the original problem and sweeping it under the rug.
- selfmodruntime 2y ago
  You can rely entirely on crates that disallow unsafe to be included.
- commodoreboxer 2y ago
  You can do tons of stuff with purely safe Rust. The main things that you can't do are FFI, making self-referential structures, and dereferencing raw pointers. And unsafe isn't a problem. It's a point of potential danger to be heavily audited, tested, and understood. Having the entire language unsafe by default is an obviously worse situation. This is throwing the baby out with the bathwater, like rallying against seat belts because you can still die while wearing one. An improvement is still an improvement. I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good.
  - techbrovanguard 2y ago
    > I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good. if you've convinced yourself that you're special and all problems with c are solved by trying harder, clearly everyone else is just lazy. with that line of logic, there's nothing to fix with c. rust is not just redundant, but also aggravating, since its popularity causes the cognitive dissonance to start creeping in. maybe i can make mistakes? should we improve tooling somewhat? no, it's the children who are wrong.
    - talldayo 2y ago
      > all problems with c are solved by trying harder, clearly everyone else is just lazy. If you're even remotely familiar with professional C development then you should know this is unironically true. Tooling does exist to offer memory-safe features in C, they're just far more complicated than using a safe language from the offset. Nobody wants to use Valgrind when your linter can do the same job without leaving your editor. Most of today's high-performance C code is compiled using the same IR that LLVM generates when compiling C. Unless you're a GCC pundit it doesn't make sense to reject the direction the industry is headed in. > maybe i can make mistakes? should we improve tooling somewhat? After a while, being allowed to make mistakes starts to pile up: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

bigstrat2003 2y ago

> Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not get you very much. 1. There are plenty of interesting programs which don't require unsafe. 2. Even if your program does require unsafe, Rust still limits where the unsafety is. This lets you focus your scrutiny on the small section of the program which is critical for safety guarantees to hold. That is still a win.

techbrovanguard 2y ago

> To do anything interesting you will require unsafe blocks this is just flagrantly false, have you no shame?

pjmlp 2y ago

People still die while wearing seatbelts, helmets and motorbike protective gear, body armor, bullet proof vests, yet many more survive, than those not wearing any of those in similar situations.