Thx for the comment! that part of what I'm looking, but the harder part is found the concepts, in this case I know about "CPU Cache", so is a lot easier come here and ask.
So which other concepts are there, that complements Rust? if I would not know Heap, Stack, CPU Cache, how can I find them to use them in Rust? Which concepts are there where I can link and use in Rust?
These are parts of low level programming, often called systems programming. It is not really Rust specific, it is similar for other systems programming languages like C, C++, Zig, Nim, Ada, and some more. Perhaps a Google search for "Introduction to systems programming" may give you some results. But its is a wide area. I think at universities there are typically courses about variants of systems programming. Books might be available. All that also depends on the actual hardware, embedded systems might have no cache, no FPU, and some tiny microcontrollers might have no instructions for integer division at all, or might be very slow for divisions.
Maybe have a look at Reddit - The heart of the internet
GEB! I love that book! Blew my mind back when I was a university student. Blew. My. Mind.
Yay! finally! this is the core of this thread! With this type of answer we can search, look other concepts and find resources!
Would be ideal in Rust be able to have some docs to know and use as research, at first would be nice for example for a normal PC, (to do not extend to embedded systems or gpu for example) just thinking about nice complements in this journey!
@jumpnbrownweasel Your answer is also nice, not because it directly tell us how to do it, is because there is the path tell us is Rust behind who handle the optimizations, and because it tell us what we can and can't control directly and indirectly from Rust, which is very very valuable in learning.
Would be ideal be able to build more of this type of resources!
Warning: long-a** post ahead.
TLDR: there are none and there won't be any (most likely) any time soon.
This is a tricky subject. I'm assuming there's no harm in rephrasing your original title into a bit more "abstract" yet a whole lot more useful "non-X resources to learn Y" where X is a concrete specific tool / approach / philosophy (in this case: Rust) with regards to Y - the overall domain / theory / praxis within a given field of human endeavour (here: low-level/system programming as a whole).
The reasons it's a tricky one aren't that obvious. For one: the cost-to-benefit analysis in the short-term / immediate (the only real guiding force in most of the contemporary self-obsessed "market") is heavily skewed towards X over Y nowadays. Most couldn't care less about X or Y - to begin with. They're only in it for Z - the personal gain with the better job with the higher pay with the stock.
If all you're looking for is a comfy little MAMAA's spot for your backside (Z), it makes less sense to spend all the time and effort in the world to turn yourself into the most knowledgeable expert in the domain of your choice as a whole (Y), than it does to put sound-proof vanta black blinders on and proceed to happily specialize in one specific tool currently in-demand: be it C/C#/C++/Rust (X).
Perhaps, if the people in charge of hiring would make an effort in looking for Y as opposed to X, we'd see somewhat of a different picture. Which brings us to the point number two: the recruiting process. You'd think by this time most would have figured out that it's the depth of knowledge that matters, not the amount of checkboxes you can tick off next to any potential candidate's name.
Unfortunately, both for the people they are in charge of hiring and the company employing them as a whole: most recruiters are just as obsessed - with their own little Z, in their own little world, where their own little fears and desires and ambitions and concerns drive all of their day-to-day. Trying not to get fired, impressing their boss, ticking the same few lists of checkboxes, occassionally acquainting themselves with some "industry-proven" practices, looking smart while at it.
Filtering out "10+ years of experience with Rust"? Easy enough. Seeing how (poorly) someone handles some meaningless, convoluted, utterly detached from any real-world scenario Le3TC0De problem? No problem, boss. Making sure the potential hire understands the difference in between processes and threads and data races and CPU caching and low-level sync primitives? ... . Let's circle back on that. In the meantime, here is the "industry standard" that Google uses today ...
Which brings us the "educators". You'd think they, out of all people, would understand that it's not about the specific tool you're using (X) - be it C/C#/C++/Rust - as much as it is about your overall understanding of the capabilities and limitations and pros and cons of each (Y) - which are quite universal and don't require nearly as much as cramming of all the endless edge cases associated with any one particular environment: at least not if you understand the essentials well enough.
Unfortunately for you - and rather fortunately for quite a few of them - their own interests and incentives and goals (Z) strike again. Even if they know enough to be able to teach you about it (which would only apply to a select few individuals out there, nowadays): why would they willingly reveal it all in one go, if they can keep feeding you bits and pieces, here and there, that never quite fit and "click" into any proper and coherent whole, yet keep you firmly glued to their "content"?
Why risk losing you as a potential buyer to one of their courses luring you with some loud and juicy "learn X and land THE $100K JOBZ!!!" headline? Why turn you into a potential "competitor"?
Lastly: the "community". It hardly matters what exact PL we're talking about, though in the context of Rust in particular a few more aspects come into play. You'd have to search for quite some time before you stumble upon a plumber who would swear by any particular brand of utensils and call whoever uses anything other than his personal favorite a whole bunch of cute little nicknames.
Then again, a plumber's job doesn't depend nearly as much upon his expertise with/love of one particular brand as a programmer's job does on his own with/of his given PL of choice. Add to that any additional moral and ethical aspect at large ("it is right/wrong to use Rust/C as it will/won't help you avoid countless bugs and memory issues") and you'll get yourself a solid recipe for a cult.
In the context of the subject at hand - what matters the most here are, once again, the incentives. People who like Rust want to continue using Rust. People who like C++ want to continue using C++. Same goes for people who have a soft spot for C# and JS and Python and Haskell. If you're strongly biased inclined towards any of them, chances are: you don't simply want to continue using it yourself. You want to get as many people to use it as well. The more people you "recruit" in your camp, the higher the chances of it not only surviving - but growing and spreading, after all. [1]
Suppose you now wish to write a book that "bridges the gap". You pack it to the brim with all the gems and nuggets and essentials which are universal to all the low-level code: be it C or C++ or Rust or even D.[2] It's likely that it'll take you quite some time to finish it. In the meantime, you probably still have to eat. Which means you'll either have to work on it in your spare time alone, or take a break from any full-time retirement altogether to focus on and ask some people for support.
Want to go the hobby route? Well, that's cute. There's a ton of material you'll have to scavenge all over, make sure all of its builds - for every language and every OS you want to showcase - cross reference it up and again, proofread, etc. It's a gargantuan amount of work, and if at any point your full-time gig comes into jeopardy (maybe 'cause, dunno - layoffs?) the whole thing will just stop.
If it's the last option you settle on: who exactly are you going to ask? How many people do you think will be out there ready for you to offer your "encyclopedia of systems programming" to them? Out of those, how many would even consider paying you for it? How would they justify this purchase?
Do you expect the TikTok gen to take an in interest it, with their whole non-existent attention span of a brain-fried goldfish or less? The "me wanna job; me see job offer with X in title; me wanna learn X now" folks - for them to stop and think and reflect and reconsider priorities in life? The people in the camp of Rust or C++ or C who have already "made their choice"? Who is it going to be?
Combine all the points above and you'll get yourself a fairly exhaustive answer as to why:
will likely never see the light of the day. To be clear: I would love to see it happen, myself. My faith in the homo sapiens' ability to follow anything but their basic instinct and/or personal interest heavily incentivized by the lure of the clear-cut personal reward is a bit too low at this point, though.
Your best bet is to try and [1] get acquainted with as many languages as you possibly can, unless it's some obscure throw-away academic research project [3]; [2] avoid falling into any single camp yourself [4]; and [3] use every opportunity to experiment and explore and find out as much as you can about whatever it is you're currently working with. It's also the best way to make things stick.
Working through a pre-made path someone else has made for you will never teach you quite as much as you can teach yourself by building something that genuinely interests you on its own.
Do keep in mind, as well, than sooner or later you will have to specialize. People who focus on back-end infrastructure won't have the same amount of understanding for all the bits and pieces that go into making GPU's do fancy stuff - something which game programmers might very well be required to learn. Learn and explore and discover and experiment. Just don't over-stretch yourself.
Which will increase the amount of job offers you can find for it. Which will increase the amount of those you'll want to apply for. Which will increase the likelihood of you landing a job writing code in your favourite PL. Bonus points if you get to feel extra good and special about yourself since you're now writing in an extra good and special PL that is helping you not do so many bad and evil and vile things other PLs out there don't even think about to begin with. ↩︎
It is definitely a thing: https://dlang.org/ ↩︎
though there might be some merit in getting out of your comfort zone in that regard as well, if only just to stretch your boundaries and reinforce the core concepts you've learnt elsewhere even better; Haskell might have originally started as a purely academic experiment itself ↩︎
nothing wrong with having a preference for any particular tool or a programming language: but to adopt a pseudo-religious attitude about any of them, no matter how memory-safe and well-designed and awesome - is to no longer be as much as of a "professional" as you are a (cargo) cult member, be it for the glory of Haskell or Rust or C ↩︎
I did not thought that deeply about this subject, this a nice reflection about how to search or what and how to expect found information.
In my personal case, I learn some Rust things for work, but I think most of cases I learn just for fun, in that case I can just skip Z (or choose one by myself), but for ppl how is projecting their future they could try to look on X/Y, and if is for work right, we need to know Z at some extent to make it useful.
I think there is some middle points to make this work, balance and get some documentation.
The first one would be add a middle layer, before was from X (Rust) to Y (Some feature to take advantage), now can be:
Rust -> Expect something (like make some math in vec be faster) -> Features we could look at (GPU, SIMD, etc, etc, etc).
The second middle point about resources and money, right ppl, need to eat, and that means money, that here implies courses, books, etc, etc.
Now I'll give some personal thought, if I see a course that says "Master Rust and get 100% Job", I would not go there, the main reasons (we can found a lot of them), first we can't master it even if can a lot of time.
Second, the content, you have 100 books of Rust, we would not buy all of them, nor we have time to read them, we search which content they have, reviews of other ppl, and as a first step we can have some possibilities and combinations of them where we the most complete content, now we can choose ¿what do we want to learn? and choose a book or two that complement each other.
This last one is done, we an usually find that, so in this process we can also expend money, if we add this as a for layer:
Rust -> Expect Something -> Features -> Books, courses, docs suggested/review/commented by other ppl (we could also read here from Expect Something)
So in this chain at some extent we can organize this, obvs no course/book will enter on the details about the content, but there is usually enough (at least in books) to compare with other content.
at least not if you understand the essentials well enough I think would be good know what are the essentials, and where to learn this, would be even a Chapter 0 in a Rust book.
encyclopedia of systems programming Right, I think they are very valuable! but is my particular case, I ask myself how much ppl what an encyclopedia is, maybe if they know they exists would be more ppl interested. I would also add this to the Chapter 0.
get acquainted with as many languages as you possibly can I have used a lot of languages! a lot of them, the issue you could find is that all of them are a high ones, which in honor to our limited lifetime, would be nice know which ones would benefit us in Rust journey, above already someone suggested at least basics on ASM.
Working through a pre-made path someone else has made for you will never teach you quite as much as you can teach yourself by building something that genuinely interests you on its own.
Right! motivation make a lot of difference on this! but if we make the path by our own, we will have basic holes in our knowledge, so is nice be able to have some resources that have the path from... lets say from zero to what we are doing, so we can always go and check what we have missed. Actually I want to read the Rust book again to look on missed parts.
This comment has been very fun, thx for it!
I'd recommend Computers: A Programmers Perspective for a better understanding of how computers work as well as Code Complete for how to write software that is easier to maintain.
It would also be useful if there were a book explaining how the whole software development thing works (i.e, the steps of gathering requirements and designing a system - the steps you need to take before sitting down to hammer at the code), but I'm not aware of any that aren't downright boring to read.
A little tangent—perhaps to read after learning enough of the language but before starting bigger projects than "hello world!"—and related to @eugene2k's comment are a couple of good titles on test-driven development (TDD) that I'd recommend:
The first uses Java and Python for the example code, and the second uses Java. So there's some adapting to do, but the programming language hardly matters here; the text is well-written and the code is clear enough. Rust has a very good support for unit and integration tests, so learning the methodology should motivate the programmer to use it fully (or the other way round).