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

161–170 of 323 posts

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

#161

Post by pimeys »

vardump wrote: post #150
pimeys wrote: post #100

Earlier quoted context omitted.

That's nothing! | 212 | / fn call(&self, payload: Self::Request) -> Self::Future { 213 | | let request = self.create_request(payload); 214 | | 215 | | let work = async_block! { ... | 254 | | FutureResponse(Box::new(work)) 255 | | } | |_____^ note: ...so that the type `impl futures::__rt::MyFuture request:hyper::Request for {futures::Async , (), fn(std::result::Result ) -> std::result::Result as std::ops::Try>::Ok, as…

I see. Rust is aiming to be closer and closer to C++ every day! Anyways, I think it has still long way to go to match the length of even common C++ template related error messages...

I've definitely seen much worse with C++. These kind of errors you get though when you use Tokio and combine many different futures together, the future wanting to have static lifetimes and me using a reference to self inside an async block, hopefully solved this year.

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

#162

Post by nabla9 »

skohan wrote: post #72
SCdF wrote: post #38

I am currently learning Rust and I feel this intensely[1]. I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more. Want to have a da…

Two things jump out at me: 1. Automatic reference counting is a really good alternative to GC. It takes a little bit more book-keeping, but the performance characteristics are predictable since allocations/frees are handled along the way. Many GC implementations require execution to be halted while the reference graph is traced, which makes it a non-starter for applications trying to deliver predictable real-time per…

Reference counting is a form of GC.

The problem with reference counting is that it don't work with recursive structures and counters may overflow. Overflow or reaching some max value and returning runtime error are both problems.

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

#163

Post by pimeys »

plandis wrote: post #107
alexeiz wrote: post #88

Earlier quoted context omitted.

Finally, a language that can compete with C++ on complexity and size of error messages!

This is still an unstable library (futures and Tokio are both still 0.1 release) actively being developed, in general I tend not to see crazy compile errors working on synchronous projects. FWIF I’ve made a Chip8 emulator with Rust and am working on a Z80 emulator now.

Yeah, sync projects are just pure pleasure to work with. The language is ergonomic, errors are easy to read and tooling is the best ever.

The problems right now start when you want to go async. I follow the development because I want to see easy, safe and fast way of writing async programs, and there's lots of interesting development happening with Rust.

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

#164

Post by perlgeek »

dman wrote: post #120

Disclaimer: Am a C++ programmer Watching from a distance I have to concede that from a safety, dynamism of the community and package management using cargo Rust has improved upon C++ in meaningful and measurable way. However on the complexity of the language front, I wonder if Rust will also join C++ in the realms of "too complex" 10 years from now. Would love to get some Rust experts to weigh in here on their though…

My hope is that, over time, we figure out simpler ways to achieve the safety goals that Rust is pioneering right now, and so there will be simpler/easier alternatives that do the same.

If in ten or twenty years we can't do better than now, we've failed to make progress.

So yes, in the future we will hopefully consider Rust "too complex".

(Disclaimer: I don't have much experience with Rust, speaking as an outside observer).

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

#165

Post by brandur »

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 here is more once you get into the broader ecosystem and start using a lot of non-core libraries. Oftentimes I found that the front page docs explaining the basic premise were concise and well-written, but that things got quite a bit harder when you started diving into individual classes and functions (put another way, as you started deviating from the happy path). This doesn't apply everywhere, but often the comments are very minimal and the documentation relies heavily on "types as documentation" in that there's a big list of all the traits and the functions on those traits that are implemented. In many, many cases there's little in the way of detail or examples.

I've written quite a bit of Rust now and have used many of the headliner projects. So far there have been very few crates where I didn't have to resort to eventually checking out the source tree and figuring out how to do some particular thing by examining its source code and test suite. I won't call out any single project in particular, but I found this to be the case in every one of `actix`, `clap`, `diesel`, `error-chain`, `horrorshow`, `hyper` and `juniper`, just to pick a few from the top of my `Cargo.toml` (it also happened with many other libraries). It's great that you can do this and open source is awesome, but ideally I could get by on just documentation, which is what you can do in many other languages.

Unfortunately, read with little context, it sounds like the tone of my piece was intended to crucify, but it's not. It can be simultaneously true that Rust's docs can still use lots of improvement and that the Rust team is doing an amazing job of improving them (there's just a lot of work and a long way to go). Both these facts are true with Rust.

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

#166

Post by rayascott »

actuallyalys wrote: post #90
rayascott wrote: post #63

There are a few things in life you just should not do. One of them is jump from your only language experience being Python into an advanced language like Rust when you’re struggling to grok SQL.

I don't care for this assumption that people who struggle with a programming language are so inexperienced anything they struggle with is their fault. It might be the case that Rust will always be an advanced language that beginners should avoid until they've mastered something else, but feedback from beginners could still make the experience easier for programmers who take the ideal path and learn it as their second…

“anything they struggle with is their fault.”? When did I say or even imply that? I didn’t. Like the author, don’t make stuff up.

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

#167

Post by detaro »

rayascott wrote: post #154
habitue wrote: post #111

Earlier quoted context omitted.

Brandur is not struggling with SQL[0][1]. That was an illustrative example of the kinds of walls you encounter in life as a programmer. [0]: https://brandur.org/postgres-reads [1]: https://brandur.org/postgres-atomicity

Then perhaps he should become a fictional writer then. So what parts of this “story” are even true? But more importantly, what is the point of writing a fictitious story like this? If he’s not struggling with SQL and Rust, then what is it? Clickbait? I think you mean an illustrative example of Rust-bashing.

The introduction is a generic example of learning to program and the kind of difficulty curve you encounter there. Nowhere does it suggest that it's the current state of the authors knowledge.

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

#168

Post by narag »

geezerjay wrote: post #146
pcwalton wrote: post #140

Earlier quoted context omitted.

"Don't use heap memory after it's been freed" is C++ (and C) 101 as well. Yet if the bar for C++ competence is "never wrote a use-after-free", then your bar for "competence" excludes essentially everyone in the industry. Whether a theoretically "competent" C++ developer makes mistakes related to object slicing is a completely uninteresting debate. Whether experienced C++ programmers make that mistake in practice is t…

> Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should i…

If you think about this as a correct/incorrect thing, you're going nowhere. There's this usability concept that so many people resist to apply to dev tools as if programmers were not regular humans.

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

#169

Post by xfer »

majewsky wrote: post #39
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.

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::…

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.

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

#170

Post by anderspitman »

pcwalton wrote: post #145

I'm obviously about as far from the modal Rust user as one can get, but at this point the language has completely melted away into the background. I'm often tempted to write smallish scripts in dynamic languages, but even for those I frequently choose Rust just for the Cargo ecosystem. In particular I never see a reason to use C++ unless I'm contributing to a codebase that's written in it. It takes different programm…

This is heartening.
Post reply on HN