News for hackers. Stuff that matters.
Re:Introducing MIR by kibwen on Thursday April 28, 2016 @04:45AM (#11587318)
Rust is emphatically not a kitchen sink language. If you believe otherwise, please explain what features you would remove without compromising safety or the notion of zero-cost abstractions.
Re:Introducing MIR by dschiptsov on Thursday April 28, 2016 @05:07AM (#11587386)
I don't believe in safety and zero costs. These are mere catchy memes.

I could only repeat my question: How Common Lisp or even more pragmatic Golang are less safe? I am not asking about Haskell or Erlang.)

Compile time error for trying to use an old binding/reference? Is this memory safety?

Re:Introducing MIR by nercury on Thursday April 28, 2016 @01:12PM (#11590394)
The engineering decisions are not based on beliefs. They are usually trade-offs. Safety in Rust has a very specific meaning clearly outlined in the official book. There are users who prefer it for certain tasks. The answer to your last question is also in the book.
Re:Introducing MIR by dschiptsov on Thursday April 28, 2016 @11:07PM (#11593534)
Why not state it here in a few simple sentences, like for a 5 year old? Clarity is usually an evidence for deep understanding. I hope I will be able to get it.
Re:Introducing MIR by pcwalton on Friday April 29, 2016 @01:53AM (#11593972)
Memory safety without garbage collection. (While still supporting dynamic allocation.)
Re:Introducing MIR by pcwalton on Thursday April 28, 2016 @06:11PM (#11592281)
Go is less safe due to the "Off to the Races" problem, but there's a legitimate debate as to whether that safety loss matters in practice.

Common Lisp and Golang use GC, which exacts a performance cost in some scenarios. Go also has highly dynamic semantics (e.g. with defer) which have unavoidable performance overhead, especially in an AOT compilation setting.