Rust is mostly safety • Hacker News Board

Re: Rust is mostly safety

#471

Post by jibalt » Mon, Jan 09, 2017, 1:54 AM UTC

rkrzr wrote: post #45

bassislife wrote: post #31

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…

"Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language)."

This is a common misunderstanding of being Turing complete. A program running in an interpreter isn't unsafe just because the programming language and the interpreter are Turing complete. Being Turing complete doesn't mean being able to gain root access, overwrite the boot block, scribble on the hard drive, etc.

Re: Rust is mostly safety

#472

Post by jibalt » Mon, Jan 09, 2017, 1:59 AM UTC

ytugiuyghvk wrote: post #111

rkrzr wrote: post #56

Earlier quoted context omitted.

> It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors. > The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Sure, I don'…

Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anyth…

"Every type system eliminates all its own type errors by definition."

Nonsense. C/C++ will happily produce a warning, if you specified -Wall, that you violated a type constraint and then go ahead and compile your program. To suggest that such violations are part of C's type system is to pedantically and willfully miss the point.

Re: Rust is mostly safety

#473

Post by jibalt » Mon, Jan 09, 2017, 2:00 AM UTC

braveo wrote: post #369

msbarnett wrote: post #223

Earlier quoted context omitted.

There was nothing interesting in what he was trying to say. Yes, no programming language perfectly eliminates all classes of unsafety. But that's no reason to let the perfect be the enemy of the good! "The issue with safety is..." no issue at all. Being safe in a bunch of problem domains (Rust) is still strictly better than being safe in very few if any of them (C).

So you did it on purpose. That just makes you a bad actor in the conversation.

No, that's you.

Re: Rust is mostly safety

#474

Post by jibalt » Mon, Jan 09, 2017, 2:02 AM UTC

ssalazar wrote: post #386

ytugiuyghvk wrote: post #111

Earlier quoted context omitted.

Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anyth…

More to the point, Rust and other statically typed languages* eliminate type errors at compile-time. In e.g. Python, the following code: foo = Bar() foo.baz() will compile without complaint but, supposing that baz() is not a member of class Bar, will cause errors when the code is actually run. In statically typed languages this will be caught by the compiler and treated as an error; type errors are simply not allowed…

"but its usually clear to the programmer when they are doing something dangerous"

Um, no. Every pointer is fundamentally unsafe, and a lot of C++ code is written with pointers through and through.