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

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

241–250 of 323 posts

Re: 100 days with Rust: a series of brick walls

#241

Post by brandur »

burntsushi wrote: post #215
brandur wrote: post #165

Earlier quoted context omitted.

(Author here.) I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it. Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea. What I'm speaking to h…

> (it also happened with many other libraries) I take documentation bugs seriously. If you did this with any of my crates, please file bugs. My guess is that other crate authors might feel the same, and that they would also appreciate bug reports. Writing good docs is super hard, because in order to do it well, one must sink themselves entirely into the perspective of someone who is seeking answers. This is hard when…

> I take documentation bugs seriously. If you did this with any of my crates, please file bugs. My guess is that other crate authors might feel the same, and that they would also appreciate bug reports.

Will do! For what it's worth, I also had `chan` in dependencies list, but didn't list it above because it's one of the minority where the docs and examples were very good.

More generally, I feel quite bad for complaining about things instead of going in to improve them (through bug reports or patches), but there has to be a balance between making forward progress and stopping to help shore up the tooling. That said, I haven't been doing enough of the latter lately, so I'll make more of an effort.

Re: 100 days with Rust: a series of brick walls

#242

Post by burntsushi »

brandur wrote: post #241
burntsushi wrote: post #215

Earlier quoted context omitted.

> (it also happened with many other libraries) I take documentation bugs seriously. If you did this with any of my crates, please file bugs. My guess is that other crate authors might feel the same, and that they would also appreciate bug reports. Writing good docs is super hard, because in order to do it well, one must sink themselves entirely into the perspective of someone who is seeking answers. This is hard when…

> I take documentation bugs seriously. If you did this with any of my crates, please file bugs. My guess is that other crate authors might feel the same, and that they would also appreciate bug reports. Will do! For what it's worth, I also had `chan` in dependencies list, but didn't list it above because it's one of the minority where the docs and examples were very good. More generally, I feel quite bad for complain…

Yeah, totally, I hear you. I certainly don't file issues for everything I should either. Mostly, my aim was to make it clear that documentation is one of my priorities. It isn't everyone's priority, so some might think that filing documentation bugs isn't wanted or something. But they definitely are, for me at least!

Re: 100 days with Rust: a series of brick walls

#243

Post by fafhrd91 »

brandur wrote: post #165
justinpombrio wrote: post #16

> universally terrible documentation Wait, what? Rust has what I consider the best documentation I've seen of any language. The docs explain things at a high-level, but concisely, and have numerous examples. The formatting is good, the keyboard navigation support is good, it's well-linked, and it has convenient features like links to the source and the ability to collapse everything but method headers for easier brow…

(Author here.) I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it. Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea. What I'm speaking to h…

Writing good docs is hard for sure! Especially for developers, you just want to write cool code :) but take into an account lifetime of the projects, compared to python all of them pretty young. For example I started actix-web just 5 months ago, sure it needs more documentation

Re: 100 days with Rust: a series of brick walls

#244

Post by physguy1123 »

SCdF wrote: post #126
ehsanu1 wrote: post #118

Earlier quoted context omitted.

I can agree with the initial frustration coming from a GC-ed language until one figures out the right way to design code and structure data in a language with manual memory management. But I got over it eventually. I'm also curious about this nitty gritty bit. I see this: Generally, Self : Sized is used to indicate that the trait should not be used as a trait object. If the trait comes from your own crate, consider r…

Yeah. So I'm following a ray tracing book that uses C++ as example code, and am using Traits as a form of interface: there is a trait of Material that has a function on it, and then there are different "implementations" of Material with different implementations of that fn, and can have arbitrary data stored against them. I need to have them sized because I need to copy them at a point where I only understand they ar…

> there is a trait of Material that has a function on it, and then there are different "implementations" of Material with different implementations of that fn, and can have arbitrary data stored against them.

Do you mean like a class hierarchy+virtual functions, or just having allocated data of arbitrary length past the end of a struct?

If it's the former, C++ fares no better in this regard but it's pretty easy to do in Rust. You just have a cloner in the interface. If it's the latter, that's pretty nonstandard and Rust doesn't make that easy for good reason. Unless this raytracer is doing something wild the code should hopefully be refactorable into a more normal struct+trait layout.

Re: 100 days with Rust: a series of brick walls

#245

Post by dbaupp »

wokwokwok wrote: post #231
brandur wrote: post #165

Earlier quoted context omitted.

(Author here.) I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it. Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea. What I'm speaking to h…

I wonder idly if it would be useful to have 'cargo doc deps' that would generate docs for all your dependencies (or top level dependencies) in a project. The rust docs are super useful, but not everyone bothers to publish them, and people tend to forget to pit full working examples in them.

'cargo doc' generates documentation for dependencies (along with the main crate) by default.

Re: 100 days with Rust: a series of brick walls

#246

Post by tormeh »

jdemler wrote: post #226
steveklabnik wrote: post #219

Earlier quoted context omitted.

It's interesting how perspectives differ; I love refactoring Rust code more than any language I've ever used, as it catches so many of my errors when doing so for me, at compile time.

Ever tried changing an owned field in a struct to a borrowed one with lifetimes? Be prepared to change not only the struct and its fields but also everything else where it appears. Yes, the compiler will catch your mistakes, but no, it's not something I love.

I think the Rust devs like C++'s abstraction level. Rust is about the same (more modern), it just catches your errors. I don't think it's possible to make Rust as ergonomic as Python, but I do think it's possible to move a little in that direction without losing Rust's strengths.

Re: 100 days with Rust: a series of brick walls

#247

Post by xfer »

arghwhat wrote: post #230
steveklabnik wrote: post #210

Earlier quoted context omitted.

? calls a conversion function. It only won't work if the error you're trying to return won't convert to the error that's in the type signature. Even then, you have options, like .map_err.

We have gone a bit down a tangent here. My original complaint was about the friction of different error types compared to other languages (like, say, Go). Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersom…

There is zero friction if you use either error_chain/failure crate and you can still recover the precise underlying errors. The only thing is it allocates.

Re: 100 days with Rust: a series of brick walls

#248

Post by xfer »

steveklabnik wrote: post #194
xfer wrote: post #169

Earlier quoted context omitted.

Yeah, i have recently finished a tokio based server. Working with future combinators is very frustrating. I accidentally captured a variable in a closure(should be cloned and moved), and it didn't tell me where it happened, just an error saying requires 'static lifetime for the variable.

The new async/await stuff will help a lot with this; it'll enable borrowing across futures, which will remove this requirement and make things a lot simpler.

Are there any plans to make them happen this year?

Re: 100 days with Rust: a series of brick walls

#249

Post by [deleted] »

wokwokwok wrote: post #231
brandur wrote: post #165

Earlier quoted context omitted.

(Author here.) I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it. Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea. What I'm speaking to h…

I wonder idly if it would be useful to have 'cargo doc deps' that would generate docs for all your dependencies (or top level dependencies) in a project. The rust docs are super useful, but not everyone bothers to publish them, and people tend to forget to pit full working examples in them.

[deleted]

Re: 100 days with Rust: a series of brick walls

#250

Post by staticassertion »

tveita wrote: post #238
gnode wrote: post #47

Earlier quoted context omitted.

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

I just want to be able to say "do this thing or time out in 5 seconds", and that's like all the 'async' I need in rust. Everything else, nah.

But that's just me - many people need these 0 cost abstractions, this is Rust's focus, and I'll have to wait for the higher level stuff for my projects.

Post reply on HN