Where all existing Rust books fall short is that they are not Rust books.

They are books on building software with Cargo framework.

A great "Understanding Rust" book would based only on using rustc for all examples, and in the context of that book e.g. GNU make could be used to orchestrate the builds.

Using Cargo is obviously fine but it is in the way of in-depth understanding of the language.

This also means that I really do not recommend any of the books written about Rust because they are all as useful as the Rust documentation, i.e. not that useful.

#rust #cargo

An example of “Hello World” with raw Rust:

#![feature(no_core,lang_items,start)]
#![no_core]
#![no_std]
#![no_main]

#[lang = "sized"]
pub trait Sized {}

#[lang = "copy"]
pub trait Copy {}

#[no_mangle]
#[start]
pub extern fn _start ()
{
    loop {}
}

You can compile it I think with:

rustc +nightly --crate-type bin -C link-arg=-nostartfiles test.rs

In such book you could obviously use core and std but this is as minimal as it can get (almost) ;-)

#rust #rustlang #cargo

Results 2.4 KB 64-bit ELF. From that most is metadata. Code and data is 337 bytes.

@jarkko ah dang I agree 100

@jarkko I would beg to differ. Understanding the language shouldn't be disrupted by having to figure out, how to turn it into machine code. Once we go beyond simple single file examples, just using rustc is not enough and burdening the user with the rather archaic Makefile syntax and details of compiling and linking would just distract from the topic. I would even argue, that single file examples benefit from the ability to do "cargo run".

@f4grx in order to hack one needs to touch the bottom of the ocean first before swimming on the water ;-)

@jarkko absolutely true!

@jarkko Even though my experience with Rustlang is minimal, I can 100% agree with this. Overall the usage of Cargo in documentation examples gives me NPM vibes even though Rustlang should appeal to those working with low-level systems (C, Cpp).

I really hope gcc-rs and the standardization process changes how these books introduce developers to Rustlang.

@jarkko based

@namenlos when I was young everyone started with Turbo Pascal just enough to generate lookup tables with it and then moved to Turbo Assembler :-) At least you have language constructs and a high-level build language. Don't get what you are complaining about TBH.

@laho So for low-level programming, or starting with it with any tool, you don't need that much information to begin with it as you don't have complex frameworks to learn. Just how you tell the toolchain where the entry point is and basic stuff like that...

Thus, it is good way to start Rust when you mind is still in virgin state and not been inducted by the cargo cult just yet ;-)

@jarkko well, we might be roughly the same age (although my journey did start with QBasic before moving on to Turbo C++). I'm not complaining about modern Dev tools. On the contrary. I just think that focus on Rust as a language isn't helped by using rustc and Makefiles instead of doing a simple "cargo run".

@jarkko I have bounced off rust several times because cargo is bloated unusable npm-rot. I see glimpses of a decent language under there, but it is basically undocumented as everything assumes you want the webdev experience.

@jarkko
Some people came to me to know how to learn programming and I told them to starts with logic, algorithmic and data structures then choose a programming language that resonates with them. I don't understand why people want to learn using to code by directly learning a language from books like the one you're describing.
What they actually end up learning is not how to program but just how to use a toolchain/framework ; this knowledge is perishable and isn't portable and leads to frustration.

@AMS So, I think Cargo is great (personally). It is just that in order to use I need to know how it works.

@jarkko you're probably trolling but I'll bite:

Most of the time "Linux programming" implies some kind of libc because it's explicitly part of the operating system you're programming for (vs 'just the kernel', that's what the GNU+Linux meme is about). This doesn't make your program "less Rust".

If you rather talk to the kernel directly you would use the x86_64-unknown-none target. There's a blogpost I wrote in 2023 on how to do this step by step: https://vulns.xyz/2023/03/linux-executable-from-scratch-with-x86_64-unknown-none-rust/

@jarkko Spoiler: I do use cargo in this blogpost.

Turns out having a reasonable build system doesn't stop one from in-depth exploring the Linux binary/assembly interface.

Also the code works on stable Rust, no nightly necessary. ✨

@kpcyrd why i need to read this?

@jarkko The "raw Rust" code you posted is lowkey kinda ass and you're (most likely) trying to butcher `x86_64-unknown-linux-gnu` into being libc-free (which explicitly targets glibc).

Check the output of `rustc --print cfg` vs `rustc --target x86_64-unknown-none --print cfg`.

@kpcyrd OK, I don't really comprehend you but I'll ignore this one, have a nice day :-)

@namenlos I have some real world situations mainly with custom JSON targets where without cargo does make sense or at least debugging binary output is easier with less layers. Like when I need to look at DWARF output that a compiler target generates. Obviously I use cargo when I possibly can because it obviously makes sense then ;-) To do Rust with cargo the existing books really have zero value or insight that I would find useful compared to the already pretty great documentation. For low-level hacking a book would be useful.

@jarkko ah. I had the feeling that you had a special use case (ok, maybe not that special for a systems language). I could imagine, that this use case is niche enough, that nobody bothers to write books for it.

@namenlos Honestly, I think you got this wrong. Usually books about internals are popular. In order to understand in depth what e.g. cargo does, you need to be able to imitate its behavior without cargo. Also it helps to debug e.g. bugs in cargo.

@namenlos Also at least once a month I end up in my professional life to a situation (could be related also e.g. C code) where I need to somehow verify whether a bug is:

1. A bug in software.
2. A toolchain bug.

In those situations a bag of tricks to cut out most of the toolchain is really an asset. 99,99% toolchain is not the stimulus but it is nice to be able exclude that because I've also bumped in to that 0,01% in the past ;-)

@namenlos Yeah also some comments seem to have misconception that I would somehow think that cargo is bad :-) I'll clear that one up: I think cargo is great.

Especially for complex software Cargo.lock and high-granularity version control for dependencies is an asset that keeps software safe and stable.