Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

111–120 of 474 posts

Re: Rust is mostly safety

#111
post #56

Earlier quoted context omitted.

> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Especially since the systems we use are often dynamic with changing requ…

> 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 anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.

Re: Rust is mostly safety

#112

Earlier quoted context omitted.

Go doesn't protect you against race conditions, it merely offers some concurrency tools. There is nothing to declare ownership of objects in memory. So the compiler doesn't (can't) complain if you share memory and access it simultaneously. At best, there are runtime checks. Rust does offer compiler protection against that. Edit: "merely", relatively to Rust :) on an absolute scale, still way better than C for concurr…

As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production. Sure thing, some applications need to be safe-super-safe. But is it worth to switch over from go to rust as a beginner, since go is the unsafer language? I know, that there is no ultimate language. But i always asked myself i am missing a poi…

You can also check out some CMU public calendars and read their lecture notes about safe standards in programming or get introduced to contracts just so you get better at eyeballing your own libraries to look for obvious errors https://www.cs.cmu.edu/~rjsimmon/15122-s16/schedule.html

They also have distributed programming course lecture notes that are open to the public with golang specific info on how to deal with race conditions.

You'll have the same experience in Rust if you research why they've done certain things, but can quickly get lost on the mailing list unless you've read books like EoPL http://www.eopl3.com/

Re: Rust is mostly safety

#113
post #20

The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.

Part of the issue stopping me from jumping in is that it feels like the language is still changing in ways large enough to make it difficult to learn. That may not be true anymore, but it seems like it would take a lot of work to keep up with the current 'best practices'.

Re: Rust is mostly safety

#114
post #89

Earlier quoted context omitted.

No programming language, even C or C++ or Java, lives up to that standard.

ANSI Common LISP lives up to that standard. POSIX AWK lives up to that standard. C's versioning lives up to that standard. ksh93 lives up to that standard. All of those are backward compatible, and can churn through older versions of their own syntax with no problem. But that's not the point, and you know it: the point is you guys were hacking like crazy, without any engineering. That's why the syntax of Rust is insa…

> ANSI Common LISP lives up to that standard.

The interface to environment objects in Common Lisp the Language 2nd Edition did not make it into the ANSI standard. If you're going to fail Rust for making changes pre-1.0, then you should fail ANSI Common Lisp too.

Re: Rust is mostly safety

#115
post #85
post #47

Earlier quoted context omitted.

You didn't answer my question :)

I did so answer your question, you just don't like my answer. If you expect me to go look at every single thing that they changed, I'm not doing that. This isn't a pissing contest.

I asked you to provide a single example as proof and you have not done so. There is no pissing contest in asking you to provide a tiny bit of proof for your statements.

Re: Rust is mostly safety

#116

What about stack overflows? I heard that rust no longer protects against those for benchmark reasons.

That's incorrect. On some platforms, stack probes are not yet implemented because the patch to LLVM hasn't been merged, and we need it to do this properly. Someone is working on getting that through right now.

Re: Rust is mostly safety

#117
post #99

Even if Rust adds increasingly more "unsafe" features in order to appeal to new developer groups, I agree that it should remain a "100% safe by default language", and they should continuously try to improve the performance of the safe code, rather than get lazy and say developers can just use the unsafe syntax if they want 3x the performance. This would only lead more and more developers to increase the usage of unsa…

There is no serious proposal to make anything unsafe by default, and I wasn't proposing we do such a thing. The change I'm talking about is how we talk about Rust, not making changes to the language at all.

Re: Rust is mostly safety

#118

I was surprised to see Ada in the list of unsafe languages, since it always was sold to me as being designed for safety. A bit of searching leads me to believe that Ada is better about memory even though it mostly uses types for safety, and better enforcement of bounds on array access should solve overflow issues regardless. Am I missing something?

The other thing he semi got wrong is on safe concurrency. Ada has Ravenscar and Eiffel has SCOOP. Ravenscar didn't need a GC since it was for real-time while Eiffel has one. Before them, there was Concurrent Pascal. The author would be right if he said Rust had much better approach to safe concurrency in terms of expressiveness and performance.

Ada side is producing a new model for parallel and concurrent programming called ParaSail:

http://www.embedded.com/design/programming-languages-and-too...

Re: Rust is mostly safety

#119
post #68
post #57

Earlier quoted context omitted.

> Currently Rust is about Go's age but nowhere close in usage. Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012. If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense … Fun fact: Go's first commit is 44 years old [1] ;) [1] https://github.com/golang/go/commit/7d7c6a97f815e…

Well, Go is Limbo with some Oberon-2 touches.

I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)

Re: Rust is mostly safety

#120
post #90

Earlier quoted context omitted.

No. Nobody is counting. That's why the OP said countless. "What have you done? That vase was priceless!" "Oh good, I was afraid it was expensive."

While that's a funny definition of the word, technically speaking the word "countless" does mean "too many to count".

I think it was humor :)
Post reply on HN