# Rust for C Engineers: Safe Systems Programming **URL:** \ **Category:** announcements\ **Created:** [April 13, 2026, 1:48am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536 "2026-04-13T01:48:50Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 13, 2026, 1:48am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/1 "2026-04-13T01:48:50Z")
Hello Everyone, _Rust for C Engineers: Safe Systems Programming_ is a book from FromC2Rust Publications is now live. The book is designed on establishing Rust foundation and written for C engineers to help them migrate to Rust. It presents C and Rust examples sequentially, explaining Rust fundamentals through direct comparison. FromC2Rust Publications > **[FromC2Rust Publications | Rust for C engineers](https://fromc2rust.com)** > > Rust for C Engineers by Rathi Kartheek. For C engineers adopting Rust. > **[Amazon.com: Rust for C Engineers: Safe Systems Programming: 9798995625100:...](https://www.amazon.com/dp/B0GWXYK8F7)** > > Amazon.com: Rust for C Engineers: Safe Systems Programming: 9798995625100: Kartheek, Rathi: Books Honest feedback is appreciated. ---
**Author:** ![spam\_detection](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/spam_detection/32/51372_2.png) [@spam\_detection](https://users.rust-lang.org/u/spam_detection)\ **Post date:** [April 13, 2026, 1:48am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/2 "2026-04-13T01:48:52Z")
---
**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/system/32/51372_2.png) [@system](https://users.rust-lang.org/u/system)\ **Post date:** [April 13, 2026, 2:41am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/3 "2026-04-13T02:41:13Z")
---
**Author:** ![steffahn](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/steffahn/32/47569_2.png) [@steffahn](https://users.rust-lang.org/u/steffahn)\ **Post date:** [April 13, 2026, 3:20am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/4 "2026-04-13T03:20:03Z")
I only have what’s available in the Amazon preview (first 20 pages of the book) but I’m noticing a problem in this section: ![Bildschirmfoto_20260413_044833](https://us1.discourse-cdn.com/flex019/uploads/rust_lang/original/3X/e/5/e5aad9d2695e47ac7d7531167088da3b3dd47716.jpeg) Using `rustc` manually like “`rustc hello.rs`” in a is in fact _not_ quite sufficient, nor is there any actual practice of “small programs use `rustc`”. The case for very small programs is actually [in the process of getting](https://doc.rust-lang.org/1.94/cargo/reference/unstable.html#script) nicer support from cargo. For users of manual `rustc` commands, you’ll _at the very very least_ always want to provide an `--edition=2024` argument, otherwise you’re setting yourself up for confusion if you run into any of the subtle details where editions can make a difference! ---
**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\ **Post date:** [April 13, 2026, 5:55am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/5 "2026-04-13T05:55:13Z")
Perhaps it could be worded as "small projects _can_ use rustc _directly_" implying larger ones will need something more ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 13, 2026, 6:15am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/6 "2026-04-13T06:15:52Z")
Thanks for pointing this out and for sharing the link. Will revise this section. Will present `rustc` as a way to understand the compiler and for quick experiments. Will present Cargo as the standard workflow for both small and large programs. Thanks for the nice point about specifying edition when using `rustc`. I will add a note recommending an explicit edition for consistency. The default edition depends on the installed compiler. ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 13, 2026, 6:16am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/7 "2026-04-13T06:16:30Z")
Thanks for the review comments. Sure, will frame it as " Perhaps it could be worded as "small projects _can_ use rustc _directly_ " implying larger ones will need something more" ---
**Author:** ![Jesper](https://avatars.discourse-cdn.com/v4/letter/j/49beb7/32.png) [@Jesper](https://users.rust-lang.org/u/Jesper)\ **Post date:** [April 14, 2026, 12:35am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/8 "2026-04-14T00:35:17Z")
It's rare to see a rust project that doesn't use cargo - the only one I can remember is Beazley's [lifty](https://github.com/dabeaz/lifty) - an interesting little program - and 1st one I have seen from him. If you are new to rust, I think it is nice to see the compiler first without the builder/package manager. ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 15, 2026, 6:51pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/9 "2026-04-15T18:51:45Z")
Thanks Jesper for the comment! Agree with you on the point that for new people adopting Rust , it can add lot of cognitive overload to know/learn about builder/package manager on day1. For the book, as you rightly said, have introduced compiler first and also based on review comments above, have added small section on cargo build as well . ---
**Author:** ![StefanSalewski](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/stefansalewski/32/36472_2.png) [@StefanSalewski](https://users.rust-lang.org/u/StefanSalewski)\ **Post date:** [April 15, 2026, 7:52pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/10 "2026-04-15T19:52:11Z")
> [@rkartheek](#): > > it can add lot of cognitive overload to know/learn about builder/package manager on day1. Sorry, but there is no "cognitive overload". All books I have read (and written 🙂 ) use Cargo from the beginning, and only shortly mention that for trivial programs rustc can be also used on its own. Cargo is a central component of Rust, and basic Cargo use is very easy (cargo new, cargo build, cargo run). Advanced cargo commands, and package management, is typically introduced later. I had a short look at your text, I think your writing style is quite nice. Are you a native English speaker? But of course, the first twenty pages of a book are not enough to judge it -- and actually, I have some doubts that 300 pages can teach even the most basic fundamentals of Rust. So whoever would buy and read your book, still would have to study another, more complete introductorial text, and later read some advanced books. Have you read my book? It was also intended for people who have already some experience in systems programming, and regard the official tutorials as a bit verbose. But it took me 500 pages, and I really tried to present only the most basic fundamentals. A final remark: You are discussing the term "variable binding", introduced by a nice description how variables are declared in C. Unfortunately I was not able to copy that text section here from Amazon, so I can refer only from my memory. I would suggest to emphasize a bit more, that Rust's term "binding" is only a formal description, and that internally variable declarations are in principle identical as in C, with the exception that Rust enforces that variables are always initialized before use. The term "binding" confuses actually some people, as it might indicate some form of indirection. So it might be a good idea to explicitly say that "binding" is more an abstract concept, and does not indicate that the generated machine code is different from C. Sorry -- yesterday I tried hard to not reply at all, but with your last reply you somehow provoke my ramblings. ---
**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\ **Post date:** [April 15, 2026, 10:52pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/11 "2026-04-15T22:52:36Z")
In fact "bindings" is a generic compiler internal term I've seen across several languages, useful to refer to any association between a symbol and a name. ---
**Author:** ![MOCKBA](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/mockba/32/41423_2.png) [@MOCKBA](https://users.rust-lang.org/u/MOCKBA)\ **Post date:** [April 16, 2026, 2:13am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/12 "2026-04-16T02:13:59Z")
I never used Cargo, it isn't in my tool chain. I'm an ordinary C programmer, I didn't read the book either, I use "vibe coding" and rustc. But I have right of keeping own opinion, Rust is for everyone, not only for few Rust experts. Am I right? ---
**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\ **Post date:** [April 16, 2026, 3:37am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/13 "2026-04-16T03:37:34Z")
Did anyone suggest otherwise? It's true Cargo may be the overwhelming default, and a huge pain to avoid if you want to pull in public crates, but I don't think anyone's made _value judgements_ on avoiding the use of it, at most just warning what you're getting yourself into? ---
**Author:** ![MOCKBA](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/mockba/32/41423_2.png) [@MOCKBA](https://users.rust-lang.org/u/MOCKBA)\ **Post date:** [April 16, 2026, 5:05am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/14 "2026-04-16T05:05:35Z")
> [@simonbuchan](#): > > at most just warning what you're getting yourself into When I started learning programming, I started from learning an assembler. Saying more, I even did my first programs in raw machine instructions, since an assembler even didn't exist for my processor. Later, I switched to C, and didn't touch an assembler anymore, just did some instructions occasionally. Rustc is a kind of an assembler for Rust programming, so it's obvious that the author of the book mention it first. Actually, rustc is a very powerful, simply people do not know all secrets of it. Regarding limitation yourself from [crates.io](http://crates.io)? I do not think so. I also use lot of third party crates. What I do? - search [crates.io](http://crates.io) for crates of my interest - inspect .toml of them for extra dependencies (actually [crates.io](http://crates.io) makes it for you) - if the crate has 0 or just few dependencies, check its repository out and build the crate using my manifest and build tool (manifest is same level of simplicity as .toml) Rebuild the crate .rlib, when update rustc or the crate itself. Everything is very simple. ---
**Author:** ![ZiCog](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/zicog/32/12216_2.png) [@ZiCog](https://users.rust-lang.org/u/ZiCog)\ **Post date:** [April 16, 2026, 7:34am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/15 "2026-04-16T07:34:53Z")
> [@MOCKBA](#): > > Everything is very simple. The process you describe sounds an order of magnitude more complicated that just typing: ```rust cagro run ``` Anyone using Make files to build their Rust? ---
**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\ **Post date:** [April 16, 2026, 7:36am UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/16 "2026-04-16T07:36:01Z")
Only in the happiest path is just running `rustc` on the crate source enough. Let's say you want to use the very popular `serde` crate: - There's a bunch of fiddly disabling default features in a dependency crate then re-adding them in your own default features that you need to figure out - You need to replicate the `build.rs` file behavior which sets a bunch of rustc cfg flags and generates a `private.rs` file. - You need to add the `serde-core` crate as it's dependency and implement it's `build.rs` cfgs - You probably want the `derive` feature, so also import the `serde-derive` crate - EDIT: make sure, _of course_ that you _dont_ try to replicate that `build.rs` file, since that's excluded from the published crate and is just for development. - That of course, has three transitive dependencies common for most proc-macro crates: `proc-macro2`, `quote`, and `syn`, which transitively depend on `unicode-ident` - `serde-derive` is a proc-macro crate, so make sure you set the right make deps to rebuild it on rustc version change, and to always use the host triple if you're cross-compiling! - probably a bunch more details I've missed... Compare this relatively easy case to the `cargo` experience: ```rust cargo add serde -F derive ``` I don't think it's at all sensible to compare these two experiences and say the _first_ is "very simple", before you even get to updating dependencies and resolving compatible versions. To be clear, _there are absolutely_ situations where you do want to go through the first route, I have myself (integration with an existing C++ build system), it's just not really a situation you should prefer. Even if you need hermetic builds, a simple `cargo vendor` locally then `cargo build --offline` for your automated builds is normally sufficient. ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 16, 2026, 6:44pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/17 "2026-04-16T18:44:10Z")
I agree. Thanks for this comment. ---
**Author:** ![emy](https://avatars.discourse-cdn.com/v4/letter/e/db5fbb/32.png) [@emy](https://users.rust-lang.org/u/emy)\ **Post date:** [April 16, 2026, 6:53pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/18 "2026-04-16T18:53:40Z")
> [@StefanSalewski](#): > > Cargo use is very easy (cargo new, cargo build, cargo run). > [@ZiCog](#): > > The process you describe sounds an order of magnitude more complicated that just typing: > > `cagro run` > [@simonbuchan](#): > > Compare this relatively easy case to the `cargo` experience: > > `cargo add serde -F derive` Even easier would be asking an LLM to do it for you. Simple and easy aren't the same thing, and IMO it's better to be biased towards the former than towards the latter, especially in educational materials. Cargo is easy to use, but it is not simple. ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 16, 2026, 7:03pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/19 "2026-04-16T19:03:31Z")
Nice to meet another author here. Thanks for taking the time to read and share detailed feedback. I agree that Cargo is essential and the standard workflow in Rust. The book starts with `rustc` to keep the initial focus on the core language and then introduces Cargo shortly after as the primary way to build and run programs. The intent is mainly to help C engineers build a simple mental model first, similar to using `gcc` directly before introducing a build system. The point about “binding” is very helpful. I will refine that section to make it clear that the term is mostly conceptual and does not imply indirection, and that in practice it behaves similarly to variables in C, with Rust enforcing stricter compile-time guarantees. Appreciate the thoughtful comments ---
**Author:** ![rkartheek](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rkartheek](https://users.rust-lang.org/u/rkartheek)\ **Post date:** [April 16, 2026, 7:17pm UTC](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536/20 "2026-04-16T19:17:16Z")
Thanks for the detailed explanation, that’s a very helpful breakdown. I completely agree that once dependencies, features, build scripts, and proc-macros come into the picture, using Cargo is the only practical approach. The intent in the book is limited to the early learning phase, where users write several standalone programs to understand Rust design differences with C like ownership model. Cargo is introduced shortly after and emphasized as the standard workflow. The goal is not to replace Cargo, but to sequence the learning so that the core concepts are clear before adding ecosystem complexity. Appreciate you calling this out, the distinction is important. Thanks for this clear and detail article. [Next page](https://users.rust-lang.org/t/rust-for-c-engineers-safe-systems-programming/139536.md?page=2)