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

31–40 of 113 posts

Re: Some notes on Rust

#31

Post by falcolas »

burntsushi wrote: post #27
falcolas wrote: post #11

Earlier quoted context omitted.

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 not frowned upon. I don't know where you got that idea. The only thing I can think is that this: fn foo() -> bool { true } is preferred over fn foo() -> bool { return true } But that's more of a style issue. As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

> Explicit returns are not frowned upon. I don't know where you got that idea

From the docs:

http://doc.rust-lang.org/book/functions.html

> Using a `return` as the last line of a function works, but is considered poor style

Re: Some notes on Rust

#32

Post by zanny »

pjmlp wrote: post #19
Q6T46nT668w6i3m wrote: post #17

Earlier quoted context omitted.

> 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.

If your employer won't use provably stable and almost entirely backwards compatible language improvements, you might want to just find another job. C++ is a hard enough language that someone out there will be willing to be sane about the language version they use.

I know I'd only touch 20 year old C++ code with the go-ahead to refactor it into C++14. I'd argue that not adopting smart pointers, standard threads and mutexes, and auto type deduction make projects effectively unmaintainable at sufficient scale.

Re: Some notes on Rust

#33

Post by charlieflowers »

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. In C++, you'd have to do this: MyType value; my_function(&value); When returning references, rust uses the lifetimes instead of explicit declarations to figure out where (on the stack) `value` needs to be allocated.

OMG, thank you for including this. I spent several months reading every bit of documentation that was available for Rust, and programming in it daily. Made some good progress. But I never, never came across this explanation. Very enlightening.

Rust desperately needs documentation covering these kinds of details. How on earth is someone supposed to make serious use of the language without knowing this?

I believe the Klabnik documentation hinted at this (something like, "The Rust compiler is smarter than that" and therefore you don't need to overuse pointers), but by no means did it actually spell it out. And you only needed a few sentences to cover it.

I know the Rust community is aware that more documentation is needed and has a todo list a mile long. But I don't know if technical details such as this are high enough on the priority list.

Re: Some notes on Rust

#34

Post by theseoafs »

falcolas wrote: post #31
burntsushi wrote: post #27

Earlier quoted context omitted.

Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this: fn foo() -> bool { true } is preferred over fn foo() -> bool { return true } But that's more of a style issue. As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

> Explicit returns are not frowned upon. I don't know where you got that idea From the docs: http://doc.rust-lang.org/book/functions.html > Using a `return` as the last line of a function works, but is considered poor style

Right -- explicit returns are frowned upon in the last line of a function, because they're absolutely not necessary, but everywhere else they're kosher.

Re: Some notes on Rust

#35

Post by burntsushi »

falcolas wrote: post #31
burntsushi wrote: post #27

Earlier quoted context omitted.

Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this: fn foo() -> bool { true } is preferred over fn foo() -> bool { return true } But that's more of a style issue. As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

> Explicit returns are not frowned upon. I don't know where you got that idea From the docs: http://doc.rust-lang.org/book/functions.html > Using a `return` as the last line of a function works, but is considered poor style

Yes. Which is what I said. "Using a `return` as the last line of a function works" is not the same as "don't use explicit returns."

Re: Some notes on Rust

#37

Post by pjmlp »

Q6T46nT668w6i3m wrote: post #25
pjmlp wrote: post #19

Earlier quoted context omitted.

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

Maybe? I was addressing your “I don’t see the opportunity where to use C++14 outside hobby projects.” Compilers, games, and operating system components are archetypical systems software.

How many Fortune 500 do you see writing those?

Re: Some notes on Rust

#38

Post by pjmlp »

zanny wrote: post #32
pjmlp wrote: post #19

Earlier quoted context omitted.

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

If your employer won't use provably stable and almost entirely backwards compatible language improvements, you might want to just find another job. C++ is a hard enough language that someone out there will be willing to be sane about the language version they use. I know I'd only touch 20 year old C++ code with the go-ahead to refactor it into C++14. I'd argue that not adopting smart pointers, standard threads and mu…

Back in 2005 my employer decided it was about time to move away from C++ in enterprise projects.

Actually in most of the enterprise projects I have been involved, C++ tends to be restrained to bindings to some feature not exposed in the chosen languages.

Changing employer doesn't matter, as most of these decisions come from the customers themselves.

It might work for in-house products, not so well when doing consulting.

Re: Some notes on Rust

#39

Post by pjmlp »

hendzen wrote: post #21
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.

The issue holding most serious projects back is MSVC's historic lack of support for C++11 (and now 14/17) features. Thankfully, it looks like this is starting to change with MSVC 15 [0]. As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks. [0] - http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...

There are more platforms out there than Mac OS X, GNU/Linux and Windows.

Many embedded platforms for example.

There are also enterprise customers that only allow for projects using the installed compilers, usually from the OS vendors.

Post reply on HN