> To verify your solutions, we've provided a tool that will guide you through the course. It is the wr CLI (short for "workshop runner"). Install it with: > cargo install --locked workshop-runner I have no idea what this program / package manager is so I was going to throw my hands up and say great another mac-only tutorial, but apparently this is a package manager for rust, and also apparently it comes pre-installed…
Exercises to Learn Rust
111–120 of 129 posts
Re: Exercises to Learn Rust
#112Re: Exercises to Learn Rust
#113I blogged about my approach of learn by doing: https://anssipiirainen.com/post/learning-rust/
"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 effort to avoid it?
Forgive my ignorance about Rust if this is a dumb question.
Re: Exercises to Learn Rust
#114Earlier quoted context omitted.
> I think it might be interesting to develop Rust-as-first-language teaching materials, but that's not what this is. Move assignment as your primary assignment semantic, borrowing as your metaphor rather than introducing the confusing idea of "addresses" (in Rust many things we can borrow don't have a meaningful address, but it's fine) and so on. I found that when learning Rust, it approximated the mental model that…
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…
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 ownership generally do not write good code. They may not be aware of the concept or what it's called, but their thought process contains some implementation of it, even if indirect or limited.
In C, you very often need to know who is responsible for freeing a value, or when it is safe for the one responsible to free it. Someone may think of it in different terms, but the end result is the same. Even in something like Java you still might need to know who is responsible for managing a value.
Because Rust includes these things, teaches us to think about these things, and is generally designed with these things in mind, it is absolutely a better foundation than something like C or C++. A lot of C/C++ software, I'd say most of it, sorely deserves to be rewritten in idiomatic Rust.
But, you know, it's the "right tool for the job" thing. Sometimes Rust isn't the best for a particular application. Just because it's better at what it does, doesn't mean it's also better at what it doesn't do, if that makes any sense.
Re: Exercises to Learn Rust
#115Earlier 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…
Or on safety we should not write new codecs in general purpose languages, including Rust, because these languages necessarily (Rice's theorem) can not check the semantic constraints we want to deliver safe codecs. We should use WUFFS. WUFFS is also a hard language to learn and as a special purpose language it's not applicable to most problems people have, but it is inherently safe† and delivers extraordinary performance so that's the right choice for this particular work.
† In C++ bounds misses are Undefined Behaviour, likely a security disaster. In Rust bounds misses cause a panic, likely premature program exit. In WUFFS any code which can have a bounds miss isn't valid, you get a compiler diagnostic saying you wrote this wrong, fix it.
Re: Exercises to Learn Rust
#116Surprised no one has mentioned another great and similar resource called Rustlings [0] (yes very punny name). You are given some files with todo statements which you'll need to fix and make the code compile and pass all the tests. It's an interactive way to learn which is what got me through learning Rust a few years ago. [0] https://github.com/rust-lang/rustlings
Re: Exercises to Learn Rust
#117Earlier quoted context omitted.
> 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…
Of course. I can buy for example that it's hard enough to learn Rust that you wouldn't want to teach say, Chemists to write Rust rather than Python when showing them some Computational Chemistry, even if maybe the ones who "got it" would be better programmers your focus is Chemists, not programmers. Or on safety we should not write new codecs in general purpose languages, including Rust, because these languages neces…
UB also exists in Rust, however it's only supposed to exist in unsafe code, and even within unsafe code, you still benefit from Rust's great RAII, move semantics, deterministic destructors, and so on. It's still UB to index past the bounds of a memory region (well... uhh, insert Stacked Borrows or Tree Borrows here, this gets much more complicated, but you get the idea) but you can only do this unchecked from unsafe code, otherwise it'll always be checked and will panic if you attempt an out of bounds access.
When unsafe code is a special delineated section, you're less likely to forget to be very careful.
Re: Exercises to Learn Rust
#118Earlier quoted context omitted.
But like the Office services, these are all significantly older than Rust. Bing the branding is like 15 years old, the underlying service is older still (as "Live Search") So when this stuff was built the high performance option was C++ and there is an obvious reason to avoid that if you can. Rust means you can have the excellent performance without the absurd foot guns. Whether you chase that depends on other strate…
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.
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, rather than "migrating of features from". The last and only exception would be NativeAOT which still uses project RedHawk name in some places in the code that haven't been renamed, referring to Midori and .NET Native (because NativeAOT has started with a big chunk of the codebase from the latter). But NativeAOT aside, pretty much all .NET features are exposed through IL and surrounding metadata, making it possible for any language to target these (rather than being related to C++/CLI), even if initially designed with C# in mind.
As far as I'm aware, C++/CLI itself uses MSVC to compile C++ code and then just generates bindings and glue code with other .NET assemblies, embedding itself into final .NET assembly produced that would use it. It did not target CIL with C++, like that new project for targeting CLR with Rust does, but rather CTS which is a quite old concept at this point. It is also limited to Windows only[1].
So the more accurate comparison would be between projects that produce .NET assemblies containing IL and projects that produce LLVM bitcode files containing LLVM-IR.
[0] https://devblogs.microsoft.com/dotnet/performance-improvemen... search for CoreRT and this is pretty much the only reference you can find in terms of work migrated from earlier projects
[1] https://learn.microsoft.com/en-us/dotnet/core/porting/cpp-cl...
Re: Exercises to Learn Rust
#119Earlier quoted context omitted.
Office team never was a big .NET fan, and they were partially responsible for Longhorn's failure, see also Hilo C++ tutorial made by the team as part of Vista SDK tutorials, or their love for Webwidgets to C++ code, so that isn't that surprising. It isn't as if C# vlatest wouldn't be able to take up the task, Bing, XBox game servers, and other large scale services are fully on .NET.
But like the Office services, these are all significantly older than Rust. Bing the branding is like 15 years old, the underlying service is older still (as "Live Search") So when this stuff was built the high performance option was C++ and there is an obvious reason to avoid that if you can. Rust means you can have the excellent performance without the absurd foot guns. Whether you chase that depends on other strate…
Re: Exercises to Learn Rust
#120Does anyone have good examples how to write a service that does a lot of data fetching? E.g. analytics events?