Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some notes on Rust

lambda-the-ultimate.org

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Some notes on Rust

#11

Post by falcolas »

gcv wrote: post #4

Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the author saying there isn't enough syntactic sugar?

My experience mirrors the author's: it results in a lot of use of macros and case statements. These create a fair bit of cognitive overhead to discern what the program flow will end up being, and special syntax for unpacking values.

The broad use of case statements leads to one more odd problem - knowing when, and when not, to use a `;`. Explicit returns are frowned upon, they prefer the "results from the last expression" form of returns. The `;` results in an expression returning a different value and a different type. The type system will usually catch these errors and print a helpful "perhaps you should remove the ';' from this line" message, but it's an extra bit of cognitive overhead induced by case statements.

Ultimately, I think it's less about missing syntactic sugar, and more about the type system acting like an electric fence instead of a hedge in its efforts to guide the user to their destination.

Re: Some notes on Rust

#12

Post by pcwalton »

falcolas wrote: post #7
stebalien wrote: post #6

I don't have an account there so I'll comment here: > In particular, allocating a new object and returning a reference to it it from a function is common in C++ but difficult in Rust, because the function doing the allocation doesn't know the expected lifetime of what it returns. This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. Refere…

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

> Except where they can't, and those locations aren't terribly consistent.

Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute).

> The Rust designers have publicly announced their preference for explicitness over inference, and the language reflects that.

As the original author of the typechecker, I can state that the idea that we intentionally made the type inference less powerful than it could have been is totally false. It's always been as powerful as we could make it, except for interface boundaries (where type annotation is needed because of separate compilation anyway).

Re: Some notes on Rust

#13

Post by pcwalton »

falcolas wrote: post #11
gcv wrote: post #4

Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the author saying there isn't enough syntactic sugar?

My experience mirrors the author's: it results in a lot of use of macros and case statements. These create a fair bit of cognitive overhead to discern what the program flow will end up being, and special syntax for unpacking values. The broad use of case statements leads to one more odd problem - knowing when, and when not, to use a `;`. Explicit returns are frowned upon, they prefer the "results from the last expres…

> Explicit returns are frowned upon

That's not true in any of the code I write. I prefer explicit returns in all of my Rust code. The only time I use the "result from last expression" return is when it's the last statement in the function.

The recommended way to deal with errors in Rust is "try!". Using "try!" essentially gives you the ergonomics of exceptions. You should prefer that to match or .and_then(), which are verbose.

Re: Some notes on Rust

#14

Post by [deleted] »

pcwalton wrote: post #12
falcolas wrote: post #7

Earlier quoted context omitted.

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

> Except where they can't, and those locations aren't terribly consistent. Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute). > The Rust designers have publicly announced their preference…

[deleted]

Re: Some notes on Rust

#15

Post by Q6T46nT668w6i3m »

pcwalton wrote: post #10
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

> What? C++11/14 solves these issues. You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data. I would also argue that Rust is a better s…

Fair points

Rust’s synchronization primitives are immature — they’ve been rewritten once or twice in the past year or so — but cool from a usability perspective.

edit: oh, hello pcwalton. I suspect you knew this already. :P

Re: Some notes on Rust

#16

Post by pjmlp »

Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

Only if you are allowed to use said features.

Many C++ codebases out there are still pre C++98.

I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

Re: Some notes on Rust

#17

Post by Q6T46nT668w6i3m »

pjmlp wrote: post #16
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

Only if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

> I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

Sure, but I’ve encountered some notable exceptions: LLVM projects (C++11), Playstation 4 games (C++11/14), QT5 (C++11) projects, et al.

Re: Some notes on Rust

#18

Post by copsarebastards »

pcwalton wrote: post #10
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

> What? C++11/14 solves these issues. You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data. I would also argue that Rust is a better s…

Also, it's worth noting that "C++ provides a solution" is not "C++ solves these issues". Somewhere in any C++ codebase of significant size, someone has done it wrong and the compiler isn't going to tell you where.

Re: Some notes on Rust

#19

Post by pjmlp »

Q6T46nT668w6i3m wrote: post #17
pjmlp wrote: post #16

Earlier quoted context omitted.

Only if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

> I like C++, but I don't see the opportunity where to use C++14 outside hobby projects. Sure, but I’ve encountered some notable exceptions: LLVM projects (C++11), Playstation 4 games (C++11/14), QT5 (C++11) projects, et al.

None of those are the typical corporation code that most of us are exposed to.

Re: Some notes on Rust

#20

Post by scott_s »

Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

No; modern C++ provides the tools for which disciplined use solves these issues. The problem is that one can silently subvert that discipline, and still introduce memory errors.

Rust enforces memory safety at the language level. C++ itself does not "know" about memory safety. This difference, to me, is huge. You can still opt out of memory safety in Rust through unsafe regions, but the fact that Rust provides memory safety guarantees to non-unsafe regions is, to me, a change in kind, not degree. When the only thing enforcing memory safety is disciplined use, it's still too easy to make a mistake.

Post reply on HN