261–270 of 342 posts
Earlier quoted context omitted.
Minor note,. Graydon created rust and worked on Swift. He didn't create Swift however. That said...both languages read like close siblings to me to the point I find it annoying switching between the two because I keep trying to use each ones language semantics in the other subconsciously.
I feel like I'm being bullied and nitpicked but you're speaking politely so I'm confused.
Earlier quoted context omitted.
As another Python programmer I also agree. Rust's features are very mature especially compared to an old dinosaur like C. I only wish its syntax was more like Swift's which is more pleasing to the eyes and was also made by the same guy.
Minor note,. Graydon created rust and worked on Swift. He didn't create Swift however. That said...both languages read like close siblings to me to the point I find it annoying switching between the two because I keep trying to use each ones language semantics in the other subconsciously.
Why am I flagged for standing up for myself like a good person should?
Newbie question: in the last example: fn make_tester(answer: &str) -> impl Fn(&str) -> bool + '_ { move |challenge| { challenge == answer } } why is there `move` needed, if both `answer`, and the arg of `Fn`, seem to be references (`&str`)? To a layman, this sounds like as if both "challenge" and "answer" should be borrowed - so why "move"? what's even to move here?
This is confusing, and Rust's error messages make it much worse. If you try to remove the `move`, you get an error: > closure may outlive the current function, but it borrows `answer`, which is owned by the current function. To force the closure to take ownership of `answer` use the `move` keyword. But 'answer' is of course not owned by the current function, and how can you take ownership through a shared reference?…
This applies to impl Trait as well. It should probably be there too...
Earlier quoted context omitted.
I'd argue the exact opposite. Languages that don't have a concept of ownership, and a borrow checker, and don't explicitly say if they want ownership, a reference, or a mutable reference, force you to keep all of these details in your head. Here, if I have a `&T` and I try to call a function that has a `&mut T`, the compiler will tell me that's not gonna work - and then I can pick whether I want my function to take a…
I think both points are right. There's times when it's useful and desirable to be specific about lifetimes, and there's also times where it's annoying noise. Bignum arithmetic is an example of the latter. You want to just work with numbers, and in Python you can, but in Rust you must clutter your code with lifetimes and borrows and clones. Swift's plan to allow gradual, opt-in lifetime annotations seems really intere…
Earlier quoted context omitted.
This is confusing, and Rust's error messages make it much worse. If you try to remove the `move`, you get an error: > closure may outlive the current function, but it borrows `answer`, which is owned by the current function. To force the closure to take ownership of `answer` use the `move` keyword. But 'answer' is of course not owned by the current function, and how can you take ownership through a shared reference?…
The + syntax is https://doc.rust-lang.org/reference/types/trait-object.html#... This applies to impl Trait as well. It should probably be there too...
Earlier quoted context omitted.
"Rust makes hard things easy and easy things hard." Disagree here. Like article Rust 2018 is very nice and ergonomic. Iterators, Lifetime Elision etc are nice to work. Regarding noise many people consider those noise but I find noises like return types etc very useful. Because I can be sure the return type. Regarding actual code actix doesn't look that bad from examples also. I use warp and its pleasant to work. The…
I'm a recent Rust fan (via AoC), but for "easy things hard", I would offer input/string processing as an example— regexes, string operations, grammar, etc. I know that Rust is forcing me to be correct and handle (or explicitly acknowledge that I'm not handling) my error cases, but from the point of view of just wanting to get the happy path working, it's a lot more noise to deal with compared with what it would look…
If the code is supposed to be maintainable, you could also make something like a FromRegex trait for Input. It would be a good idea to try exercism's mentoring thing to get better at writing it the easier way the first time. The mentoring thing really is what helped me to think in ways that made this mess easier to avoid.
As a Python programmer with limited experience with compiled languages, Rust code was more intimidating to read or look at than C++, Java or Go. After only an hour, I am overwhelmed by the sheer beauty and mature design of this language - it almost reads like Python or as well as any compiled language can. I cannot believe that I am smitten by Rust within an hour. Its features seem, obvious. My experience with Go was…
Rust is a complete pain for the types of problems Python is used for. Same for Go/Java.
At some point I just started writing these things in Rust instead. Describe what I want deserialized as a struct. List the fields I want as enum variants. What's that, rustc, the "name" field is optional? Ok, that makes sense, I'll handle this right away. Done. Hey, rustc, how come people talk about fighting you all the time when you're actually the world's greatest pair programmer?
Earlier quoted context omitted.
> I cannot believe that I am smitten by Rust within an hour This has been my, and a lot of my colleagues', experience with Rust. Never have I seen people fall in love with a programming language so strongly. And the love lasts for a long time.
Try to use that in real world and see if your love still stays put. An hour is not enough to validate Rust.
Earlier quoted context omitted.
> Rust makes hard things easy and easy things hard. I don't agree with this, and, if anything, this reads very biased. Insofar, Rust has made my life a lot easier, and I have not run into any major issues aside the borrow checker. And this was early on. Two years now playing with the language and I barely run into it anymore.
Async has ecosystem fracture issues. Creating graph data structures require you to understand more about borrow checker. Majority of people will probably want to use Rust for web? Which makes async needs to be ergonomic enough if it wants consider wide adoption.
Earlier quoted context omitted.
I think both points are right. There's times when it's useful and desirable to be specific about lifetimes, and there's also times where it's annoying noise. Bignum arithmetic is an example of the latter. You want to just work with numbers, and in Python you can, but in Rust you must clutter your code with lifetimes and borrows and clones. Swift's plan to allow gradual, opt-in lifetime annotations seems really intere…
Bignum arithmetic actually is pretty simple in Rust if you use the right library. Rug[0] makes using bignums look almost just like using native numbers through operator overloading. [0] https://crates.io/crates/rug
let a = Integer::from(10);
let b = a + a;