Great!

Posted May 22, 2015 6:51 UTC (Fri) by ncm (guest, #165)
In reply to: Great! by ofranja
Parent article: Rust 1.0 released

Apparently you are not aware that a C++ program can call abort() at any time? Or ignore exceptions and let terminate() be called automatically, which calls abort()? There's nothing innovative or clever about fail!. A C++ function can, as in Rust, return an object that must be cleaned up manually, but it is not done because that would be bad design. Talking about "mindset" seeks to distract attention from a failure of reasoned argument. You can pretend that weakness is really an advantage, but the argument refutes itself: C is weaker yet, but not therefore better.

Manifestly, any regime that makes you fill your program with boilerplate try! blocks (or worse) and Result<> apparatus is weak. Any that makes it impossible to recover gracefully from failures is worse. If your type system increases your cognitive load you are worse off, and no compounding of monads will save you. The type system can be twisted up in increasingly labored knots to try to encompass error handling, but the resulting mess just demonstrates it is a poor match for the job.

Rust implements lots of new, innovative, and good ideas, but it still can easily fail, and will if the response to its failings is to insist it is better for them. C++ started out with many flaws inherited from C, and succeeded because it has never suffered from delusions of perfection.

Great!

Posted May 22, 2015 8:18 UTC (Fri) by ofranja (guest, #11084) [Link] (2 responses)

I'm well aware of the explicit abort() and the std::terminate() implicit execution - either by ignoring exceptions or throwing inside a destructor. I had my years of pain with C++ already.

What I'm talking about is not how fail!() is clever or how "weakness" is good, but how modeling a language over an explicit model of error handling is better than an implicit one.

In that sense, it's indeed a C++ mindset to consider it inferior to C++ only because in C++ that would be bad design. I can say a Haskell programmer - for instance - would have very different opinions about exceptions, error handling, and good design. The same way, Rust and C++ are different languages, so not necessarily the same choices apply.

I'm not talking about perfection here - but soundness. It's tempting to throw soundness away when we are faced with the complexity of the problem, but doing so for the sake of some pre-concepted syntatic pattern or some quirky language construct makes little sense when you are trying to make a real improvement on the language level.

Great!

Posted May 23, 2015 16:04 UTC (Sat) by ncm (guest, #165) [Link] (1 responses)

Ideological purity is very appealing up to the point that it begins to actively interfere with sound system engineering principles. At that point, its main effect is to restrict use of the language to toy applications and academia. Toys are fun, but we have an overabundance of toy languages already. It would be tragic if a language with as much promise as Rust retreated to toyland.

An alternative would be to fork the language, and let Rustoy go the way of so many before it, while those of us who have serious engineering goals get on with them. That would be unfortunate but not tragic.

Great!

Posted May 23, 2015 16:50 UTC (Sat) by ofranja (guest, #11084) [Link]

Sound system engineering principles are a form of ideological purity.

I'd rather view this as a design decision instead of just ideological purity - afterall, if you are trying to design a safe systems language, you have to limit the unsafeness to strictly necessary points. If you are trying to argue that safeness and soundness are not important, Rust might not be a proper fit for your needs.

I guess Rust is not trying to be the glorious successor of C++ or a new C++ with aesthetic improvements - as others like D did - but it's trying to be something different. And this might be the key point of its success.