Hi, I am going to start learning rust. I am an prospective cloud engineer. I have read about the scope of rust in cloud computing. Aws's firecracker VMM has bern built using rust. My questions is how to learn rust to get hands dirty in cloud computing or which framework should i learn after learning rust basic for cloud computing? There is a roadmap for rust in github but that is for web development. I am not a web guy as I dont even know how write HTML code. But I am pretty much proficient in python. So, please share your valuable thoughts about my condition and choice. Thank you!
Fist thing first, have you had time to go through The Rust Book? That's probably the best place to start since you mentioned you haven't stated learning Rust yet.
Once you have the basics of Rust under your belt, the rest should be easier to find.
The best way I know to start learning something is to pick a project, something that interests you and you will be motivated to work on, and start working!
For whatever project you pick, you may want to look into learning resources for that. For instance, if you want a multi-threaded web server, you will want to learn how to use channels threads in Rust, and The Book, can be a good place to start.
So, what do you want to work on? "Cloud Computing" is a little too broad for me to give pointers on what to look into. If you make a cloud computing app/module/whatever you want to call it, what would it do?
Also, whatever you pick, come to the forum with questions! The community here is amazing and really beginner friendly so don't hesitate. I'm very experienced with Rust, but even when I have problems I'm often surprised at how many meaningful answer and different perspectives I get on even what seem simple questions sometimes.
Also a few general resources for getting started learning Rust, if you haven't seen it already:
I sort of agree in general.
However I would caution that it is somewhat more difficult to pick up Rust in dribs and drops in piecemeal/as required fashion while diving into a project compared to other languages.
It really does pay to make a good study of the The Rust Book first. From beginning to end. Trying out all the examples codes as one goes.
I feel this way because I made the mistake of quickly diving into a project after only a cursory study of the book. I had learned enough to be able to write Rust as if I were writing C. I'll just pick up the rest as I work on my project. Or so I thought. It's no so easy and quickly leads to some horrible Rust code.
Any way, having absorbed all The Book it's time to think about what "cloud engineer" means. No road map helps much if you don't know the destination!
Typically when I think "cloud" I see web server. No problem Rust had Rocket to make that easy: https://rocket.rs/. Or I see web sockets, no problem Rust has websocket - Rust for that. Or I see databases, no problem plenty of solutions for that.
But of course
cloud could include almost anything else, all the way to running neural nets or getting work done on FPGA, etc, etc.
So where does a "cloud engineer" want to go?
Yeah, I think that's a good point.
The Rust book really is a great foundation. I think I read through the first 10 chapters of the book, and then skimmed most of the others without following the examples before I actually started on my project. Then I was reading more in-depth into different chapters on and off while I worked on my project.
I was a little in a hurry at the time, but I still wanted more in-depth information than the Rustlings examples.
I had the same problem. Wanted to get into Rust, needed to get something running. Now!
The good news is that the project in question has been running in production for nearly two years without a hitch. Despite the fact that is a contorted mess that looks like C written in Rust. Rust won't actually let your create disastrous code:)
Only just now I am revisiting that project as it needs some new features adding. Having picked up a lot more Rust in the mean time I can see so many ways I could have done things better, simpler. If only I had absorbed the Book more fully back then...
This is going to take some major refactoring. Normally I would be nervous of changing such code for fear of breaking things in unfathomable ways. But this is Rust, I'm pretty sure I can do whatever I like and the compiler will not let me create mysterious crashes or data corruptions. "Hack without fear" as Niko Matsakis says: C++Now 2017: Niko Matsakis "Rust: Hack Without Fear!" - YouTube
Thank you for sharing, looks interesting.
I have been programming for a long time in a lot of different languages, mostly procedural and object-oriented ones, but also experimented a bit with Haskell. Learning Rust was particularly hard for me, and I gave up twice, until I finally went through with it in my third attempt.
A couple of lessons I learned (or rather: had to learn):
- Structs like
Arc, etc. are seldom needed, but if you need them, it does help if you already know them well (and know how to use them). So if you start learning with The Rust Book, don't skip these topics.
- There are often multiple possibilities to design an interface: do you pass a certain value by moving (transferring ownership), expect a reference (and possibly return a result with a newly generated datum), or expect a mutable reference (and modify values in place)? After playing with these options a bit and taking a look at other libraries, it felt like the best choice is most often the choice with the least effort for the callee.
- Sometimes Rust's standard libray offers certain functionality in a limited way only. It's good to be conservative (i.e. reluctant) about which functionality is added to the standard libraries, so that's not a critique. But for example, I quickly ended up with "
rayon" instead of using Rust's built-in threads. It's not always easy to decide which library to pick for a particular task (I try to avoid adding too many random dependencies to my projects). Websites such as The Rust Cookbook may help.
- Calling methods of traits that aren't imported with "
use" (or included in the prelude) aren't in scope and can cause a compiler error. This is actually great because it avoids collisions in the namespace while allowing types to implement multiple traits instead of having a restricted class hierarchy. But it can cause confusion sometimes as you may have a value but can't call its methods (unless you import the corresponding trait as well).
- It may help to read compiler errors carefully. The compiler errors are pretty helpful in many cases and often give hints how to solve a problem.
I'm sure I've missed some points. Working with Rust sometimes can be irritating if you're new to some concepts, but I feel like it totally pays off. I don't want to miss Rust anymore.
People on this forum have been very friendly in helping me with questions that I wasn't able to solve on my own. Thanks for that
Actually, I am not into cloud yet. So, I don't have in depth knowledge regarding what a cloud engineer do. Here, I meant with "cloud engineer" for working with AWS, Azure or GCP. Common roles of cloud platform engineers are cloud service development, cloud orchestration, cloud architect, DevOps, Sys-ops admin etc. I wanted to know, if anyone working in these role and dealing with rust or know how rust can be useful, If they would used rust, what framework/library they would used, or just standard libraries are sufficient? Like Python has Selenium, boto3, chalies etc. Btw, thanks for the comment.
Ah, I see. I'm actually very experience with cloud engineering then!
I've done a lot of work in cloud deployments, Docker and containers, orchestration, system administration, configuration management, AWS, and some full stack development related to such operations.
Interestingly, you don't really need Rust for that kind of role. But let me clarify that a bit more.
tl;dr: You don't need Rust as a cloud engineer, plain 'ol bash is enough. But with some hard work and dedication ( and the time budget from your employer ) you can use Rust to build full-blown applications or frameworks to really "step up your game" so to speak.
For essentially everything you do as a DevOps/cloud engineer, you are usually automating processes that involve other existing tools, such as Docker or Terraform or the system package manager inside or outside of a container, the build system such as Jenkins or Drone, etc., and the absolute most common language me and my colleague use by far is plain 'ol Bash scripting.
You almost never need anything else, and you don't have to install anything on any Posix system to get it to work.
Now I don't necessarily like bash. I mean, it's got all these weird things about it that just don't feel nice, but once you get over a few weird things and you get used to doing if statements and variable expansions, it's all you need.
Combined with tools like
awk and others, you've got what you need to access REST APIs, control docker, automate builds and deployments, etc. Almost everything has either a REST API and/or a CLI, and that gives you the control you need from Bash.
Now I'm sure different roles in different organizations will encompas different things in the vast field of "cloud engineering", but honestly, for me, a cloud engineers job is less programming and more solution designing.
It's about putting together all the other tools out there, such ad Docker, Terraform, and, dare I say, Kubernetes ( I hate Kubernetes, but there's a time and place for it ). You job is to take the companies problems and goals and find a combination of tools and workflows that, put together, help solve their problems.
Like setting things up so that you can push to a git repo and have your app automatically built and deployed to your cloud environment. Or providing a way to manage multiple environments for different use-cases such as development, performance testing, and production. It's about making sure you can quickly and efficiently manage your resources in the cloud or on-premise depending on your needs and automating things so that it doesn't take weeks to do things like getting HTTPS certificates for instance.
The most important thing is being able to take a problem, know your goals, and try to come up with the best solution to that problem using what tools you have available.
So where does Rust come in? While for most things you don't need Rust, or even Python for that matter, there are times where there is a hole in what you can accomplish with existing tools. These are opportunities for Rust. The caveat is that, in my experience, these holes, when they pop up, have not been small ones and they take serious development time to fill.
For instance, I made a framework called Lucky for the Juju DevOps orchestration tool. I was much newer to Rust at the time, but it took me about 5 months of development to finish, but it made Juju deployment development so much easier.
I also made the Juju Lens desktop application with Rust ( there's also a video here ). This was a custom GUI as a replacement to the less functional GUI that came with Juju, so that operators could manage their Juju cluster and SSH into them with ease. Rust was really awsome for Juju Lens because I was able to use Tauri and Rust bindings to
Juju Lens took me ~4 months to finish.
So, in summary, while I have found Rust to be an incredible tool for cloud engineering, all of the uses of Rust so far have involved a lot of time and effort to make them useful ( because it is a larger-scale app that actually needs to be made ), which requires the time and budget from your employer, and you have to convince your employer that it's worth the effort. Depending on who you work for or what you are working on specifically, this can be difficult.
Finally, what libraries or Rust resources did I use? The standard library in Rust is intentionally somewhat minimal compared to Python's, for instance. Start with the standard library and if it doesn't have it look for crates.
For different tasks there's often some stand-out crate that seems to be somewhat de-facto, but here's a list of some of the common things I've done and what crates I used for it:
- HTTP server: Warp, but it's not the only good one. I think Actix is good, too, and I've heard good things about most of the other Rust web servers.
- HTTP requests: reqwest
- Serialization ( aka. JSON, YAML, TOML, etc. ): Serde is king. Does all of the common formats and some uncommon ones with ease.
- SSH: ssh2
- Git: git2
- CLI argument parsing: structopt ( create CLIs by writing structs! ) and clap ( powers structopt )
- Thread synchronization: parking_lot (
Mutex's and locks ), crossbeam ( channels and thread utilities )
- Async executor and libraries: smol, Tokio ( but I prefer
smolwhen possible because it is smaller )
- Finding Rust crates: lib.rs ( an alternative to crates.io that has a better search engine and search ranking )
Also, feel free to use the forum to ask "what crate should I use to do X?". This forum, or rather the people behind it and the Rust community, is one of the most valuable resources for Rust.
I guess for all that wall of text, that doesn't exactly tell you where to start learning, though.
What you have described there as "cloud engineer", with "automating processes", "existing tools", "package manager", "Bash" etc, is what I used to know for some decades as "Systems Administrator". All be it moved out to computers one does not own and no doubt scaled up a lot.
I don't mean to dispute or demean any of that. There is a list of skills there that I do not have and will not live long enough to acquire.
But to my mind there is a whole other dimension to "cloud engineering". Somebody has to write applications that are tailored to the flexible, distributed environment the cloud offers. They have to make them efficient, fault tolerant and scaleable over tens, hundreds, thousands, of machines.
That is a whole different world of problems than writing applications in the good old days of single, huge, monolithic serves and applications. What about all those guys working on Google search or Facebook and so on?
Then somebody has to write the support software for all that cloud stuff. Be it distributed databases, messaging systems like Kafka or NATS, deployment systems and so on an so on.
It's not over yet. Surely there is a lot more of that cloud infrastructure that needs to be written. Then I feel sure Rust has a lot to offer when it comes efficiency, correctness and reliability.
Yeah, I think it's just that systems administration has just kind of moved to include the cloud and how to organize the way we deploy to it. It's not much different in concept to systems administration in general, it's just shifted I think. I'm relatively new to computing, having been deep in it for < 9 years.
Yes, I think you're right. The confusing part is the terminology. Maybe the role me and my colleague have played is more like "Cloud Architect" or "DevOps Engineer". In the enterprises that my colleague has worked in it tended to be for these big companies that are stuck writing or using old software, but wanting to move to the cloud. They didn't really write scalable, resiliant software, they more wanted a way to run their legacy software in the cloud. What our role would end up being is "how do we run existing software, with all it's quirks no matter how un-cloud-ready it is, in the cloud", not "how do we write awesome cloud native software". That's an entirely different subject, but with a lot of possible overlap in how the app is deployed.
I think that Rust would be incredibly useful for writing cloud native applications. It's safety and performance, plus a growing ecoysystem would be awesome for writing those kinds of apps.
Absolutely, everybody write those in Rust please.
Definitely. Me and my colleague actually feel like there are large gaps in the cloud ecosystem, and we dream of writing the best orchestrator out there one day, in Rust of course!
So I think there is a fairly clear division between writing cloud native apps ( use Rust! ) and making existing apps run on the cloud ( use Bash ).
And sometimes, when you are a cloud architect, you might get lucky and be allowed to write some cloud native apps in Rust.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.