Some notes on Rust • Hacker News Board

Re: Some notes on Rust

#111

Post by marrs » Mon, Feb 02, 2015, 2:24 PM UTC

ajanuary wrote: post #93

frou_dh wrote: post #46

> There's a macro called "try!(e)", which, if e returns a None value, returns from the enclosing function via a return you can't see in the source code. Such hidden returns are troubling. Strikes me as simply a very appropriate use of macros. Get tired of writing the same syntactic fragment again and again? Write a macro. Want to see what some macro is "hiding"? Look it up or expand it.

The issue is it makes it difficult to notice that a function might return when scanning through a function. Especially as it's in places that are looking for a value (e.g. assignment). At the moment it's just return and try!, but people look to the standard library for what is acceptable. When the standard library contains a macro that can return, people will write their own macros that return. It could potentially b…

I think people get used to it, especially if it's a part of the standard libs. C++ overloads the bitshift operator and nobody seems to mind.

Re: Some notes on Rust

#112

Post by mkishi » Tue, Feb 03, 2015, 4:21 AM UTC

steveklabnik wrote: post #89

mkishi wrote: post #67

Earlier quoted context omitted.

Actually, I got curious and tried it out. Turns out Rust didn't optimize the heap case: it used the caller's stack, and only then copied the value to the heap. https://play.rust-lang.org/?code=%23!%5Bfeature(core)%5D%0A%...

That's because of `Box::new`, I'd think. If you use the box keyword, you should get the placement new effect.

Thank you! I thought the box keyword was simply a syntactic sugar -- I'm not that familiar with placement new, even in C++.

Note for the interested: the optimization works right now, even though the keyword is behind the box_syntax feature gate.

Updated test: https://play.rust-lang.org/?code=%23!%5Bfeature(core)%5D%0A%...

Re: Some notes on Rust

#113

Post by cristicbz » Tue, Feb 03, 2015, 11:31 AM UTC

Animats wrote: post #58

Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html ) I wasn't expecting it to be picked up on Hacker…

I agree with many of your points actually. But I wrote the Doom renderer in rust at https://github.com/cristicbz/rust-doom and it's not a port, it's written from scratch based on specs, so maybe your argument is correct in general, but it really doesn't apply to it: it has very little unsafe code, some which really shouldn't be:

1. A tiny function which loads textures. I was fooling around with optimising load speeds. The actual speedup I got was insignificant and I really should revert it to safe code.

2. A silly getter on the transformation matrix---another misguided attempt at a speedup; no reason to use UnsafeCell instead of RefCell. Should revert.

3. Casting buffers from files as structs. This is safe for any buffer the same size as a Copy struct, std offers no such function, so I do. Unsafety is isolated in two small functions (one for T and one for Vec), all its callers are safe.

4. Interacting with OpenGL. Fair enough, this happens all over the place, but it's not actually unsafe. The OpenGL bindings library didn't take much care to only mark unsafe operations as such, and all GL calls are marekd unsafe---which is why I wrap them up in a macro which peforms the operation in an unsafe block and panics on any error. I should port my code to glium and then this would go away as well.

*better formatting