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

Exercises to Learn Rust

rust-exercises.com

Post reply on HN
Print view View original

121–129 of 129 posts

Re: Exercises to Learn Rust

#121

Post by maxbond »

mwigdahl wrote: post #113
anssip wrote: post #35

I blogged about my approach of learn by doing: https://anssipiirainen.com/post/learning-rust/

Thanks for that article! One line jumped out at me: "When I learned about async programming, I realized that for my CLI-based project, I didn’t really need async. So, I removed all async code and the Tokio runtime, which significantly simplified the code." This implies that you used async before learning it. Does async come along for the ride with "standard" constructs in Rust, such that you have to make an active ef…

No, it's not like Go, you have to opt into async. (There was a time before 1.0 where it was, but that was removed.)

My reading is that, since their technique was to learn something and then immediately apply it to their project, they began making it async before they realized it was better of without it. Seems like a good learning experience to me, I think this approach is good.

Re: Exercises to Learn Rust

#122

Post by pjmlp »

neonsunset wrote: post #118
pjmlp wrote: post #110

Earlier quoted context omitted.

And the strategic priority of those business units has been to take advantage of all the performance improvements that have come out of Midori toolchain into Core CLR/Native AOT toolchains, while exposing MSIL features only available to C++/CLI to C# as well. Just like Rust can take advantage of the LLVM IR features used by clang, so does C# in regards to the MSIL used by C++/CLI.

Given your interest in C++/CLI, I wanted to give some clarification in regards to its relationship with .NET platform as a whole. Indeed, there have been historical influences from Midori, C++/CLI, CoreRT[0], .NET Native/UWP and work done that got merged into earlier releases of .NET Core (up until 3.1), in particular, Span and compiler optimizations. However, pretty much all work done since Core 3.1 is independent,…

Thanks for the deep dive.

As a user I know C++/CLI, since it was initially released as Managed C++ in .NET 1, replaced by C++/CLI in .NET 2.0.

They have two ways of compiling code, fully managed, meaning pure MSIL, where the Assemblies are considered as safe as other .NET languages by the PE Verifier. In this way, some UB behaviours and not so sane stuff from C day's, is forbidden in C++/CLI and will trigger a compilation error.

Mixing in native code. In this way everything from C++ is allowed, the resulting Assembly will be a mix of MSIL and native code generated by the Visual C++ backend, and will fail verification as a safe Assembly, being only allowed in unsafe code contexts.

My reference to it, is because until the improvements started in C# 7, the only way to make use of specific CLR low level capabilities, was to either do Reflection.Emit(), or reach out to managed C++/CLI.

You are fully aware of this, but many keep forgetting MSIL was designed for C like languages as well, and just like the hyped WebAssembly has all the necessary features to take full advantage of it.

Re: Exercises to Learn Rust

#123

Post by jimbob45 »

jamil7 wrote: post #40
jimbob45 wrote: post #34

Earlier quoted context omitted.

He's right, though. Languages today shouldn't force you to jump through low-level hoops if you just want to write high-level logic. Likewise, the low-level devices should be easily and ergonomically accessible. Rust is phenomenal at the latter but weak at the former.

What languages scale better in that regard? Genuinely interested in recommendations.

C# and C++. In C#, you can use pointers but most people don't even know because they so gracefully become invisible. Also ref/in/out keywords are there when you need them and invisible when you don't. Likewise, you don't even need to know about move semantics in C++ to make a simple web server.

That said, C# and C++ most certainly have their fair share of issues.

Re: Exercises to Learn Rust

#124

Post by OptionOfT »

I've been doing Rust personally for a while now, and now that I got laid off I'm really looking for a job where I can do Rust.

Sad part is that there just aren't that many jobs out there that use Rust, let alone for someone with extremely little technical experience.

Re: Exercises to Learn Rust

#125

Post by maxbond »

OptionOfT wrote: post #124

I've been doing Rust personally for a while now, and now that I got laid off I'm really looking for a job where I can do Rust. Sad part is that there just aren't that many jobs out there that use Rust, let alone for someone with extremely little technical experience.

Hope you find something! There's a thread on the subreddit.

https://www.reddit.com/r/rust/comments/1cixuzr/official_rrus...

See also this account on HN.

https://news.ycombinator.com/user?id=whoishiring

Re: Exercises to Learn Rust

#126

Post by anssip »

maxbond wrote: post #121
mwigdahl wrote: post #113

Earlier quoted context omitted.

Thanks for that article! One line jumped out at me: "When I learned about async programming, I realized that for my CLI-based project, I didn’t really need async. So, I removed all async code and the Tokio runtime, which significantly simplified the code." This implies that you used async before learning it. Does async come along for the ride with "standard" constructs in Rust, such that you have to make an active ef…

No, it's not like Go, you have to opt into async. (There was a time before 1.0 where it was, but that was removed.) My reading is that, since their technique was to learn something and then immediately apply it to their project, they began making it async before they realized it was better of without it. Seems like a good learning experience to me, I think this approach is good.

Yes, I had some feature in an earlier version that I wanted to add and the example code I was looking at was async and that made me think that I have to go to that route and also include an async runtime (Tokio). Once I was there, I ended up using async versions of some other dependencies as well.

Later on I then realized that in my CLI app I’m not gaining anything from it as there is no need for any parallel prosessing. It was just making my code more complex.

Re: Exercises to Learn Rust

#127

Post by mwigdahl »

anssip wrote: post #126
maxbond wrote: post #121

Earlier quoted context omitted.

No, it's not like Go, you have to opt into async. (There was a time before 1.0 where it was, but that was removed.) My reading is that, since their technique was to learn something and then immediately apply it to their project, they began making it async before they realized it was better of without it. Seems like a good learning experience to me, I think this approach is good.

Yes, I had some feature in an earlier version that I wanted to add and the example code I was looking at was async and that made me think that I have to go to that route and also include an async runtime (Tokio). Once I was there, I ended up using async versions of some other dependencies as well. Later on I then realized that in my CLI app I’m not gaining anything from it as there is no need for any parallel prosess…

Thanks for the information!

Re: Exercises to Learn Rust

#128

Post by zelphirkalt »

LoganDark wrote: post #114
tialaramex wrote: post #97

Earlier quoted context omitted.

Certainly in regards to say, ownership, Rust has to be very explicit about things which you'll find in the literature make sense for other languages but maybe are barely mentioned when they're taught. For example the life of objects is something Bjarne Stroustrup's early editions of his C++ book neglect, basically saying yeah objects come into existence and then they're later destroyed and it's only in the third edit…

> Anyway, I think what you're feeling is more real than you've allowed for. This is concretely a better foundation, that's not an illusion. It's not perfect but the sense that this is how things should be makes sense compared to other popular languages. I know that things like ownership are universal concepts. They are relevant to all languages, even those that don't have a borrow checker. People who do not think of…

Although ownership only becomes necessary to think about, once you start mutating data. If you only use immutable data, then there is no need to think about ownership.

Re: Exercises to Learn Rust

#129

Post by 3dworldrunner »

rayxi271828 wrote: post #55

Wonder if there's anyone who (1) is reasonably comfortable in some popular programming language(s) and (2) has gone through these exercises could/would share their take on how helpful/useful these are? Context: I've been doing Java professionally for 10+ years, Python, JS a few years ago, C++ way earlier in my career (early 2000s).

So, I have a couple CS degrees, but due to a series of unfortunate events, basically 0’d out of industry pretty quickly out of uni, now years ago.

I just went through rustlings, and then this, and found both quite good. Rustlings is a little more gradual, perhaps, but basically just lists book sections to read for each problem set. This has a small outline of concepts for each exercise and is less reading.

I’d recommend either or both…and I found them both to be pretty accessible. Rustling is a slightly broader survey of topics just due to the reading. This is maybe a little quicker to the meat of it.

I don’t think either will give you 100% fluency in the borrow checker, but both will get you close enough to flesh out your understanding afterwards, and to make picking through readings more efficient afterwards.

Post reply on HN