Surprised 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.
The difference is that Rustlings requires the person to already know Rust whereas the link on this post (100 Exercises to Learn Rust) starts teaching Rust from the basics (assuming that the person knows another language).
That doesn't match with my experience: I learned the language from scratch just fine with Rustlings. (In fact, I found it more approachable than the Rust Book.) The first few groups of exercises in it walk you through the basic syntax and semantics, to the point that I found it almost tedious to work through, but I ultimately came to appreciate it.
I did Rustlings without any knowledge of Rust and I thought it worked great. There are links to guide & documentation pages for every exercise. It worked great to learn the basics through practice.
To me "the basics" means either no programming at all, or something rudimentary and half-remembered like you did simple Logo turtle graphic programming in math class as a ten year old and now you're thirty. Not "knows another language".
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 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 I had already developed for programming. Move semantics and such just felt right. I had used around 10–15 other programming languages by then, but none were even remotely Rust-like.
I don't know why this is. It can't be that Rust is the objectively or even subjectively right way to think about programming. It has to be that its concepts were simply already intuitive to me, but I wonder why that is, when so many people struggle.
Perhaps it's because of neurodivergence, maybe the language just matches the way I think in general and that's why it made sense so quickly. I'd probably make a terrible teacher, because I just do not understand the struggles people have with Rust, and I can't just teach someone to think the same way I do.
Maybe when existing Rust users try to write material for new developers, they write in a way that, for lack of a better way of wording it, is only really accessible to their own neurotype. In other words, it doesn't really help the people that genuinely struggle with Rust's way of thinking, it primarily helps people who already have this way of thinking.
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 edition once C++ has more powerful techniques for this stuff that suddenly it's important that C++ programmers care about this and there's IIRC a whole chapter of the book.
It is also said that although Rust looks like a semicolon language, like C or Java or something, it's actually not like those semicolon language at all, it's an ML, the syntax makes it more palatable for semicolon programmers to learn and looks more "serious" for a systems language.
As an ML, Rust gets a solid foundation in its type system. Rust has a type with no values, and a type with one value, Sum types and Product types, so we're on firm ground here, we can do type arithmetic. Languages like C++ struggle to have a type with one value†, and can't really do "no values" at all. It's like your system of arithmetic doesn't have zero. You can limp along, the Romans did, but it's an unenviable situation.
† The C++ language isn't really sure how to handle these types properly because its rules say they need at least one byte of storage - but that entire byte is just padding. It's not insurmountable but it's very silly.
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.
> 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 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.
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 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.
In C and C++, Undefined Behavior basically says it's safe for the compiler to assume this hasn't happened, because as a programmer it's your responsibility to ensure it's impossible. This might not have been so bad if completely normal things (such as signed integer overflow) weren't UB. It's not safe to assume the programmer did it correctly, and it never will be. So, these languages have tons of footguns.
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.
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.
Worth noting that this set of exercises was created by the author of "Zero to Production in Rust", the well-reviewed book with the crab-in-a-human-skull cover[1].
Oh nice ! I bought this book and forget to finish it for life reasons but it was really enjoyable.
Book’s name doesn’t lie , it’s literally the author taking you by the hand along the path of building a real application with real problems on a real production environment explaining everything from the basics of the language to how to keep it online.
The book is pretty opinionated (because well, since it guides you until production giving you basically all the code, choices are needed) but the author always takes the time to explain its choices and what the alternatives are.
I’m feeling like I want to come back to this book.
Also the same one who is making a new web server framework for Rust called Pavex, which is apparently pretty novel in how it works compared to others like Actix Web and Axum [0][1].
> Pavex is in beta, so you need to activate Pavex with an activation key:
> You can retrieve an activation from the Pavex Discord server’s #activation channel after you’ve joined the beta on Pavex.dev.
To be fair, there is no particular backstory. I picked a hermit crab as the book logo since crabs are strongly associated with Rust due to Ferris, Rust's mascot.
I then landed on that style (and the skull) because they looked sick and distinctive. The cover images of many technical books are incredibly dull these days.
Rust community members are known Rustaceans which is a play on the word crustacean. Crabs are a well-known crustacean. Crab in a human skull is a visual metaphor for learning Rust.
(Slightly more seriously, the project to replace the borrow checker was called Polonius[1], so it wouldn't be the first Hamlet reference in Rust land.)
To follow up that movie reference with the response in a different movie where that line is misquoted, “Where’d you hear that, a renaissance festival?”
I haven’t seen that movie a lot, but that scene (and really the entire movie) has been seared into my consciousness for 30 years. It was just the exact thing I wanted at that point in my life.
I skimmed through a few sections in which my rust knowledge is basic at best (threads). Really enjoy the no-nonsense, not-a-word-wasted style.
My first thought after spending 30 minutes with this that it could easily become my new no. 1 recommendation for rust onboarding, toppling the zero2prod book.
Then I figured out why this felt familiar, it's from the same author :D
And it also isn't 100% best-practise, more like all-practise. It tries to show any and every way you could approach a problem while somehow keeping it minimal. Really like it but if you follow the tutorial 1:1 you'll most likely get frustrated
I read the book while knowing almost nothing about the language, but yes I did complement it with "the rust programming language" book at the same time.
I still think zero2prod is extremely beginner friendly, you don't need to know rust well to follow it. You can just dive into rust concepts as you read it.
One suggestion: where you talk about using AsRef<[T]>, might be worth suggesting IntoIter, where it makes sense? IIRC that's what std uses for functions that aim at being generic over data structures and iterators (I might be remembering wrong, though).
In any case let's not digress from the truth: amazing list.
There are a few of these conversion traits (for turning some kind of Thing into a Thing with a different purpose)
You're thinking of IntoIterator, which is a trait for when you want an Iterator, maybe what you've got is already an iterator, but maybe it isn't yet and yet it could easily be transformed into one (like say an array), so in either case IntoIterator::into_iter() gets you an iterator instead of whatever you have now -- the thing you had before is consumed by this.
Another you may find uses for is ToString, which says this obviously could be a string and I want the string. Unlike IntoIterator this does not consume the thing you wanted a string for.
There are also a suite of generic traits for converting to another type, From, Into, TryFrom and TryInto. As the person consuming things, prefer TryInto if you're clear what should happen when you can't, or Into if you need it to always work. As the person who is implementing the traits, prefer to implement From or if you can't TryFrom. Rust automatically cascades the conversions in one direction, so if I implemented From<Goose> for Bird, and then you later write code which needs TryInto<Bird>, that'll work just fine with a Goose using the code I wrote, because Rust concludes how to use my conversion to make it work, automatically - Rust will even be able to see that your "What if I can't?" error handling code will never run, and optimise it out of production code since I provided From<Goose> so this cannot fail - its Error type is Infallible, an Empty type.
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.
I can’t get up to speed with rust using these kinds of material.
Haven’t looked deeply at this one in particular but they tend to teach you patterns and approaches. That works for a lot of languages. Got into zig pretty fast for example. You can start writing go in 2 days and even if you write shit code at first, it will run.
But I can’t get productive in rust and that kills my enthusiasm.
I went through zigling variant i did about 90 of the 110 plus after reading the documentation of zig, it helped solidify some of the syntax and concepts. I think it does help reduce what might have been a 3 week process to a 1 week process during the evening learning.
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 effort to avoid it?
Forgive my ignorance about Rust if this is a dumb question.
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.
One observation I have with Rust, looking at the code in wild, abstractions are usually (always?) leaky - implementation details are exposed/imposed due to the ownership feature of the language.
Ownership is not implementation. Ownership is contract. If you’re an owner of a house you can do more than if you’re only renting and if you’re renting you can do more than if you’re only looking at the house from the street. Ownership is a very useful concept that influences interfaces in real life so why wouldn’t it in programming?
This reads like the Rust equivalent of the OOP 'animal/cat/dog' intros of yore. Real world comparisons are almost never all that helpful when it comes to computing concepts.
Ok, point taken, indeed it reads like that. However, in programming and generally in engineering this is a very useful concept. There is a difference between "component X is part of Y" than "component X works / interacts with Y" or "component X has exclusive access to Y in this particular span", similarly how it is often very important to know if "component X can be safely shared" - and Rust allows to express that, while languages like Java are quite blind to that.
Consider a simple Java method signature:
public static MyCustomFileReader open(FileHandle someFile) { ... }
Who is responsible for closing the file after you're done with reading it?
Does the returned reader close the file handle on close, or should I issue another close on the file handle afterwards?
Can I open multiple readers on the same file? The only way to know is to check the javadoc comment, if someone took time to write it. In Rust there are no doubts like that.
Have been using go for 8 years now, and started with this. And to be quite honest, I still refer to this sometimes for quick lookup on certain things related to syntax, pools, waitgroups or channels. Beautifully done tutorial of Golang, can be done in a few hours and gets you a good base knowledge of the language.
To anyone who has done this and rustlings, how do you think they compare? I've been very happy with rustlings, but I'm curious if it's worth it to finish these too!
If it's coming towards the end of the year, solve Advent of Code in the new language you learned. AoC scales gently. On day 1 if you can't see how to do it that's going to be because you didn't really understand your new language. By day 25 it's very likely that you can't figure out how to solve the problem yet in any language, if you're up for it, maybe solve it in your existing favourite and then try the new one.
Because lots of people do AoC, especially in popular languages like Rust or C++, you can see other people's solutions in the AoC Reddit solutions thread each day, which are often inspiring -- you learn new idioms, library features, or even whole CS concepts.
I never got a proper chance to experience Rust at work but always wanted to give it a go.
So I went through the Build your own Redis challenge by https://codecrafters.io. It was a a good excuse to get my hands dirty with all the different Rust concepts (with a bit of structure).
I'm trying to write a Rust program to transform gamepad inputs to MIDI events -- mainly CC, so that one can control a filter with a joystick for example. But it should also be possible to play notes. (The field of MIDI controllers appears quite limited, and "pads" available on some keyboards are not fun to use at all.)
I implemented this in a webapp, but it's really awkward to have to go through the browser back in the DAW. An executable would be more elegant.
PS1: Some DAWs allow for gamepad input, but it's usually limited, difficult to configure, and buggy (Reaper for example has a bug that was first raised in... 2009 and never fixed).
PS2: I had hoped LLMs would help... but boy do they not! ;-)
Highly specific, but in my operating systems course, we wrote a shell in C, it was very fun. I plan to write it again, but in Rust (mostly out of fun), extend it, make it my daily driver.
I hate to be stickler, but on the very first page ("Syntax"), right after explaining comments, the text says "In previous exercise, you saw the greeting function..." Unless I'm missing something, this is the very first intro to Rust, and so there are no prior exercises...
I don't, but I'm doing something similar, and I've been using this video [1] about axum as a guide. My thinking is that I'll write something similar, but instead of kicking off a task when a request comes in I'll kick them off on a schedule.
I'm not very experienced, but by skimming the headings I can see that it covers almost all of Rust's core features. I'd say you're between a beginner and an intermediate Rust user if you complete the exercises and can be comfortable dealing with lifetimes.
Obligatory reference to the Rosetta Code site which shows a good number of popular and less known problems with solutions in many programming languages.
Exercism.io is not just limited to one language it has a track for most popular languages. I've used it a couple of times and can definitely recommend it. You get to compare your solution with other (top-rated) solutions and you also get mentorship at times (depending on availability I guess).
> I do not understand why there are so many zealots around the language.
Neither did I. But then I took the time to learn the language, and I understood what all the hype was about. Maybe you should too, instead of just whining about it.
Many of us program for fun, and Rust is a joy to work with (especially compared to the alternatives in its niche), so we talk about it a lot. Of course, when you need to get serious work done, the most fun and enjoyable tool is not necessarily the one that's best suited to the job.
Being the first language to contest C++ in places like the kernal is a pretty big deal, no? It helps that the borrow checker is a new idea around being safe without gc.
Java is tremendously unfriendly to actually use. Sure, it's tolerable inside a corporate environment with established build/deployment systems, but there are few languages that make the "build a random repo off GitHub" hurdle higher than Java.
This statement does a lot of work. Safety without compromise in speed on modern architectures is rather valuable. I dont think you understand the importance of that statement and why it is being used in the kernel. Depending on what you do, you may never need to code in rust (I dont) but dont underestimate how much humanity meeds that combination of safety and speed.
It’s a mixed bag. Yes there is a lot of hipster fanboyism. But I’ve also seen a lot of old timers coming from a career in C++ where Rust basically formalizes a lot of best practices and removes a lot of the worst footguns. I see the hope in their miserable faces and so there is definitely something real about Rust – and not necessarily Rust itself, but just the proof of concept of it, that it’s possible to solve many of the problems low-level programmers have just accepted as fact-of-life for a long time.
Me personally I’m not from that background, and coming from higher level languages the selling points are not nearly as compelling given the learning curve and less mature ecosystem around many things. For instance, language performance is rarely the limiting factor in say API/backend development. Usually you have networking, io and databases eating most of your lunch, and also horizontal scaling is typically already in place for other reasons.
I don't know rust, generally don't advocate writing things in rust but I find the people complaining about the people advocating for rust to be completely insufferable. People are talking about it because it's cool and new and shiny and they like it, you see it a lot because there's lots of people who find it cool and new and shiny.
This shows why I wouldn't use Rust for anything. Seems like a lot of verbosity for gains that don't really apply whatsoever for the kind of work I do (web apps and APIs). You have to remember let/mut fine, but then ownership/borrowing, and finally this `into()` thing - yuck! Like washing your face with sandpaper.
You get ridiculous performance gains with Rust a web backend. Even Microsoft is rewriting part of their C# backend to Rust on the 365 application side of things. Which is where you get to deal with the hefty ms-graph api which handles literal fucktons of data.
Anyway. It is more verbose than something like Go or Python. I’m not sure it’s really so bad compared to most languages, but some of the benefits you get from the verbosity is that you gain a lot of control over how you use mutability and the borrow checker or how you work with memory in general. Things which are foreign to many developers today, but you shouldn’t compare a Rust implementation to a C#/Java/Python/Ruby/Node/Go api, you should compare it to a c/c++ api… which is where Rust is just so much “safer” for production.
We have Node APIs in Typescript, we have Python APIs with FastAPI, we have C# web APIs and we have a few Go APIs. We’re perfectly happy with those, well maybe not the fact that we use so many languages, but we’re happy with them. Where we use Rust is where we used to use C, and the benefits are massive. You get the same sort of performance, but you also get an environment where programmers with less experience working without garbage collection can do work we just couldn’t have them do with C.
> It is more verbose than something like Go or Python
Quite debatable. My experience is different. I have ported some tiny amount of Go code to async Rust and it turned out to be simpler and shorter. Way less boilerplate related to cleaning up the resources - in Rust it was actually zero additional code thanks to RAII and really nice channel design, while Golang needed a lot of additional stuff like waitgroups or manual defers plus more channels to communicate obvious things which in Rust are simply passed by result of a future.
Rust also feels a lot more expressive than Go with functional collection transformation chains (map, reduce, filter, grouping etc) where in Go this is loops and ifs all the way down. Rust is very close to Python in this regard.
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 strategic priorities.
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<T> 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.
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.
`into()` just converts something from one type to another, like an integer to a floating point number. Would you have liked for such conversions to happen implicitly? Because let me tell you, that is one of the most painful features of C++, and modern well-written C++ typically disables implicit conversions in one way or another.
(Note: For the specific example of integer-to-float, Rust has an alternative built-in syntax, but `.into()` is the canonical way that also works in generic code.)
Also, just because these examples are verbose doesn't mean that all Rust code is this way. Accessors/mutators aren't used super often in my experience, and the builder pattern is used occasionally, but isn't pervasive.
(I have historically been very skeptical of Rust on the web, but by now, I find it pretty pleasant. I of course know Rust very well already though.)
Agreed. There's also another aspect at play: to build knowledge one step at a time with this learn-by-doing approach, you have to get learners to write code that's not perfectly idiomatic along the way. You then correct and refine those first drafts as you progress along.
In the case of setters, we get rid of them at the end of that chapter by using the newtype pattern thus guaranteeing that field invariants can't be broken even if you can access them directly.
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.
But who's forcing you? Oh .. the companies jumping on the latest "in Rust" hype. I see.
Just do your thing and be good at it.
PS: There was this VSCode extension to do BI stuff in the IDE (quarylabs/quary) showed here on HN and once I saw the CLI core having "Rust-based" as a feature I just closed the tab. What does "Rust-based" even mean? The tool may have been good but Rust is not a feature.
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.
Well, nobody forces you to use the setters/getters pattern. For internal implementation, you could access everything directly. For example, Zig encourages this style of programming.
In my experience in Rust, the use of getters and setters is less common compared to some other languages like Java.
> 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 on manjaro lol
[0] https://github.com/rust-lang/rustlings