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

231–240 of 323 posts

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

#231

Post by wokwokwok »

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…

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.

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

#232

Post by [deleted] »

oblio wrote: post #49
seawlf wrote: post #10

As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. I've found the compiler messages to be succinct and helpful. The package system is wonderful. It's dead easy to get something off the ground quickly. All it took was learning how and when to borrow.

Were you a C/C++ programmer before? Your starting perspective matters a lot.

[deleted]

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

#234

Post by dmitrygr »

eropple wrote: post #229
dmitrygr wrote: post #228

Earlier quoted context omitted.

If it has no protections then why even use rust? You cannot both claim safety and then claim versatility by abandoning said safety. Because without your claimed safety, I might as well use C and not do battle with my compiler.

The claims of safety and versatility are not in opposition. There are cases where the compiler can't prove what you're doing is safe, so take the guards off and do it yourself. In the 99% case (I've literally never written unsafe Rust), you leverage its tooling to better communicate intent and safety. Clinging to an exceptional case and pretending it's the rule doesn't hold in practice.

The OP i was arguing against said

   if something is hard to do in Rust it's
   probably an anti-pattern with respect
   to memory performance or safety.
To counter a statement of the form "nothing of type X is good", only a single example is needed. I provided it.

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

#235

Post by dragonwriter »

dmitrygr wrote: post #234
eropple wrote: post #229

Earlier quoted context omitted.

The claims of safety and versatility are not in opposition. There are cases where the compiler can't prove what you're doing is safe, so take the guards off and do it yourself. In the 99% case (I've literally never written unsafe Rust), you leverage its tooling to better communicate intent and safety. Clinging to an exceptional case and pretending it's the rule doesn't hold in practice.

The OP i was arguing against said if something is hard to do in Rust it's probably an anti-pattern with respect to memory performance or safety. To counter a statement of the form "nothing of type X is good", only a single example is needed. I provided it.

> To counter a statement of the form "nothing of type X is good", only a single example is needed.

“If something is hard in Rust, it is probably an anti-pattern” (emphasis added) is not equivalent to a statement of the form “nothing of type X is good”. It is equivalent to the form “most things of type X are not good”, which cannot be rebutted by a single example.

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

#236

Post by arghwhat »

reaperducer wrote: post #136
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.

If we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler. It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry. Imagine if car makers worked the same way.

Your "stable and mature" languages were the crazy research projects of old. No one is forcing you to do anything, but let us not forget the nature of our "mature" technologies and the process by which they form.

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

#238

Post by tveita »

gnode wrote: post #47
majewsky wrote: post #39

Earlier quoted context omitted.

I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example: error[E0271]: type mismatch resolving ` + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result >, futures::MapErr , [closure@src/server/mod.rs:74:18: 74:74]>>, std::…

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.

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

#239

Post by brandur »

steveklabnik wrote: post #208
brandur wrote: post #176

Author here. I want to apologize a bit for the tone of this article — it was written from a place of frustration, and this part of the site is very much akin to a development journal — these are short articles without a lot of concrete facts that are not really intended for broad or comprehensive consumption. In no way is this meant to be an anywhere-near comprehensive critique on Rust. I'll quickly point out that Ru…

No worries There's a lot of stuff coming down the pipeline that I think would help you a lot. > there's a distinct lack of pragmatism around getting core features like concurrency nailed down and shipped. For one example; we're working really hard right now on getting async/await shipped, and dealing with ergonomics problems around it. The recent changes are to make it simpler, not make it harder. For example, you sh…

Thanks for not taking it personally :) that's not always easy!

> For one example; we're working really hard right now on getting async/await shipped, and dealing with ergonomics problems around it. The recent changes are to make it simpler, not make it harder. For example, you should need to think a lot less about future composition, since you'll be able to borrow across futures, as just one example. > > There might be a disconnect between what we're working on and what we're perceived to be working on. Messaging is hard!

Sufficed to say that I can't wait to see these improvements come out. It may end up being the case that I simply got started on this project a little too early — six months from now many of my problems may have evaporated already.

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

#240

Post by physguy1123 »

SCdF wrote: post #61
physguy1123 wrote: post #51

Earlier quoted context omitted.

There's nothing at all preventing you from having a Vec in a struct, and the use cases for variable sized structs are pretty rare. It sounds more like you conflated having a different problem with having a Vec be in a struct and stuff like that poisoned your further attempts to understand the language

You're absolutely right. What I really meant was that you can't have Vec where T is a trait without also wrapping that in a box, which for me in turn doesn't work for a bunch of other reasons. In any case, my point remains the same: it is very challenging-- at least for someone used to just creating data structures and letting GC handle it-- to build code that does what you want, and you spend large amounts of time "…

> In any case, my point remains the same: it is very challenging-- at least for someone used to just creating data structures and letting GC handle it-- to build code that does what you want, and you spend large amounts of time "fighting" the compiler.

This is a fundamental problem of languages that don't use a managed runtime. You either take the C route and just hope the user did things right or try and enforce it somehow. If you're used to writing GC-code, your problems around understanding object lifetimes are probably going to manifest as 'fighting the compiler' with Rust whereas with C they would manifest as intermittent and hard-to-track segfaults.

If I follow the github in your profile and take the Rust issue you opened, in C that mistake may never manifest except in certain control paths after you've turned off debug mode, and you'd compile code easily but sit banging your head against the wall.

I write a decent amount of Rust and write both C and C++ professionally, and in most cases Rust is drastically easier to write nontrivial code in because it catches all sorts of lifetime issues and has so many QOL improvements.

Post reply on HN