Andre Bogus - Easy Mode Rust
Вставка
- Опубліковано 14 жов 2024
- Rust is often considered a hard to learn language. And sure enough, on just about every topic you can go arbitrarily deep and find new and fascinating things about how computers and/or math work. Also if you write code most of the community deems 'good', you'll invariably run into some hard topics, like ownership and lifetimes, async internals etc. But you don't need to know most of it to become productive! This talk shows some ways to simplify your coding at the expense of some duplication, runtime overhead or warm fuzzy feeling you don't get because you didn't just solve a complex puzzle.
lecture starts at 2:50 .
God bless you
Sorrow Checker was an underrated joke.
Glad you liked it.
That banjo tune was so good! The times are indeed changing.
Thanks for the talk, this is genious... code should be written to be as easy as possible to read ... in 99.9% of the cases, the easy mode rust will be already faster than all the other languages... so reducing the barries of entry should be the target... if the rust comminity understands that there will be no challenge to take over. I am a 20 years xp developer learning rust for the past weeks... I am in love but I recon that it might be hard for begginers. Cheers!
@6:36 What is sense of this code anway ? Iterate over items and add copy of them to the same collection if predicate is true ?
Also without a clone we may end in endless loop if we add items to collection we iterate ? (depends on iterator implementation).
Anyway doing it in any other language without using index or some form of .clone/.copy is asking for trouble.
Good talk! I think I understand the point of it. I just dont think match "is a bit harder to learn".. even PHP has match these days..
It would be AMAZING If these rules (and suggestions) could be codified into a beginner-level rust compiler. I am using Golang precisely because I’m productive first and then (semi) efficient later.
If code that “cheated” could be auto-tagged with a rule ID (sort of like a linter exclude token) then we could get working code first, then rely on a local code review to show how to go from “good”, to “perfect”
Well, it's not exactly cheating, and the only thing you incur by not following the suggestions is the need to learn the respective concepts. But for most of those things, building a lint would certainly be possible.
Isn't that what clippy is for? A lot of these things have lints you can enable for your codebase. Sometimes it even refactors the code for you.
@@yondaime500 well, yes and no. We do have a number of lints that will improve the "easy" Rust code people might write, but I don't know any that could be used to confine people to write easy style Rust code as of yet. We might add them in the future, but I don't see a lot of benefit to that.
@@llogiq Yeah, the former is what I meant, actually. For the latter, the only example I can think of is implicit_return. Maybe there are a few others in the restriction group.
@@yondaime500 There are a great many lints that improve style, help find the right method combinations (len_zero, iter_skip_next) or even catch beginner mistakes (clone_on_copy) leading to incorrect code (let_underscore_lock, ineffective_bit_mask).
The thing i disagree most with is the recommendation to use code gen, since making mistakes in it is easy (strings wont give you autocomplete or type queries!) and, like macros, can have more confusing error messages than in code you wrote.
I've done both, and I don't see a big difference here: With codegen you can start simple and output your generated code to ensure it is what you expect, in macros you can cargo expand to do mostly the same thing. Once things get complex, both ways offer little in the way of debugging.
I've been saying Rust is easy from the beginning. I just had to accept that not everything needs to be allocated on the stack.
7:45 It seems like `items.clone().iter()` will still have an issue with `modify(item)` being able to return an owned `T`. Perhaps `for item in items.clone()` to use IntoIterator directly?
Aah, I'm thinking too complicated... I suppose `modify` can clone the input
I watch a lot of videos at 2x speed so I can get through enough of them (so much stuff being throw at us).
The banjo at 2x was pretty cool.
This was a great talk.
Also, use easy frameworks - some are more involved than others.
Bevy actually is easy Rust imo because of the framework.
The sorrow checker 5:35
Yeah, that was a deliberate joke. I am a dad of three, so I need to do at least one of those in each of my talks... 🙃
The whole thing doesn't feel like an "easy" Rust. It feels more like a collection of weird, contrived dance moves that beginners need to learn in order to avoid those invisible, contrived barriers that the language put up for the name of safety.
"If you wanna avoid using lifetimes, use Arc. What is Arc you might ask? Well, let me explain about Rc first before we go into Arc, so that you can "easily" avoid lifetime annotations."
Only Rust people think this is ok.
Don't get me wrong. I'm totally onboard with the capabilities the language brings. But if those capabilities come with a learning curve, then just let people climb that curve, properly, and maybe even painfully to an extend, in order to bring them the full benefits.
i thought this was easy mode.
I think he means the easy mode to lecture someone or to start a project with begginers. From my understanding he is not trying to teach rust to the audiance... the rust book is a very nice place to begin the jouyrney, ot is free on rust site. Cheers
I think this talk is just a big joke, a bit "Bogus", I really hope I'm right - else it would go against all that Rust is about. Actually: If it's a joke, it should be clearly marked as such.
I agree. All the tips are just aweful xd
If the tips look awful to you, that's because you're looking at them from the wrong perspective. The idea behind my talk was to minimize the things people think they need to learn before they become productive in Rust.
If you want to sell Rust to a startup, for example, the initial training costs are often cited as breaking the camel's back.
So rest assured that despite my last name, I absolutely mean it.
You may have missed the premise of this talk -- the entire point is to explore the simplifications you can make to your code (in terms of how much Rust you must understand before writing that code) and their trade offs. I think these are good tips -- Rust is a complex language and I, as a beginner, wasted a lot of time trying to figure out how to write things more idiomatically when I should have just been getting the thing working (and let myself learn the idiomatic way to do things over time).
A lot of the tips are almost reminders that there was a way people did these things before these language features existed and you can still do those things in Rust, which seems obvious but for some reason in the beginner's mind its often not.
This talk is none of those things. Your comment misses the point. To say Rust must always be rigid enforcement against potential errors, ruthless efficiency, and new users must be forced to accept ALL these things before they have even mastered the most basic of syntax issues... that position overlooks the many improvements outside of the borrow checker.
To argue this is a "joke" is a hostile and narrow perspective, which you might expect on decades-old C Programming forums which slowly lose users. One should always have patience for those who learned differently than they did. Trying is trying.
If another, easier language had a "Rust mode" that exactly matched Rust, would that be any different?