Is there a way to learn the programming concepts to make it easier to learn Rust?

@Joe232 I would say that maybe the concepts that you mention wanting to understand more about, the stack and heap at least, are actually somewhat unnecessary to have a very competent understanding of Rust and the ability to put it to effective use.

More important are the basic concepts of borrowing and a thorough understanding of things like Options, Results, and Iterators and how to use control flow mechanisms such as loops, if statements and match statements and how you can use the strengths of Options and Results to idiomatically solve common programming patterns.

On top of those I would start to understand generics and traits a bit more, maybe. Then probably lifetimes. async is also really good to understand, but it depends on what you are working on whether or not you need it and how soon you should learn it.

Also important in a different way is getting a knowledge of the ecosystem and what crates are out there for accomplishing certain tasks. For instance, I spent a while early on really confused at how to accomplish certain things because I didn't know about the lazy_static crate ( don't worry about looking it up yet ).

These things will mix a bit and you will have to be exposed to certain portions of the more advanced components early on without understanding exactly why things are a certain way, but that is that nature of learning. You will build on the foundational pieces bit by bit and eventually you will learn things that make the things you learned earlier on make a lot more sense.

But you don't need to really dig into a lot of these topics way too much to write effective Rust. I actually don't have a full understanding of the stack or the heap, but I do have a great grasp on Rust. If you're still curious as to my picture of the stack and the heap ( it may not be 100% accurate, but it is good enough to understand Rust :slightly_smiling_face: ):

The stack: is a place in memory where you can store things that you know the exact size of at compile time. There is a limit to the size of the stack but it is also very fast to access and modify. In general local variables for types such as numbers, arrays, and anything that doesn't have a dynamic size such as Strings or Vec are automatically stored on the stack.

The heap: is like a big pool of memory that you can request chunks of from the operating system ( or allocator, actually, I think ) to store your stuff in. For example, you program can just go and ask the allocator for a spot somewhere on the heap that is 56 bytes long, and the allocator will go search its memory for a spot that can fit 56 bytes and it will give your program access to that memory so you can stick whatever you want in it.

The heap is where things like strings that aren't string literals go. Your program can't know at compile time what the length of a string is going to be before it exists, so instead of storing it on the stack, when running something like String::from("hello world"), rust will go find enough space in memory to store "hello world" and then the String object will point to that place in memory.

An important characteristic of the heap is that finding spots for stuff is slow ( relatively anyway ). This is referred to as "allocating". When you create a Vector like this, vec![1, 2, 3], the Vec will allocate enough memory to store 3 i32s ( the default integer type ). You program will have to wait for the allocator to find a spot in memory to put your i32s. This can happen as far as humans can tell, unless you have to do many, many allocations very quick.

When tuning for performance one key is to be conscious about making as few allocations as you can in the areas of your program that get executed very often or in loops.


I think you are right. A detailed understanding of stack and heap is not essential.

But I think the most important thing to understand is that local variables, only have a lifetime as long as the function or other scope they are in takes to run. Unless you move them elsewhere. Returning references to them is a no-no for example, as they will cease to exist before the reference does.

It's this basic lifetime understanding that I think is crucial to getting anything done in Rust. Even if one does not know about the stack as such.

Then there is this other place one can put data where it can live much longer, provided you can refer to it with a RefCell, Rc, Arc or whatever. Oh yeah, the "heap", but never mind the details of "heap".

Then one can get down to all the other Rust features on your list.


It was quite interesting discussion so I decided to throw my two cents. For me Rust is like Janus (two faced Greek god) and it's good to know both faces :slight_smile:

First face is a systems programing language - so I think it's really good to know how computers work on lower level - meaning OS level - although it's not really necessary to understand how stack and heap works, it's really good to know a bit about it (and about threads, processes etc.) - because if you do not care about these, why to care about language like Rust - other languages might provide valid alternatives. Recently I really enjoyed Operating Systems: Three Easy Pieces book to improve my knowledge in this area.

Second face is high level programing language, with features like generics, functional programing, algebraic types, pattern matching... where experiences with languages like OCAML (that was my case and this exposure was really useful) or Haskell can be quite useful and will help to create nice, understandable and well structured code.


As usual, Google is your friend:

Personally, my way of learning is to write code, and when I encounter something I don't know how to do, I google it and see what it says. I have trouble internalising things I read without actually doing some coding, so even if I read something, and understand it at that moment in time, I forget it.

This may be due to advancing senility, generally I am extremely forgetful, I can forget several things in a matter of seconds, learning is quite hard for me! But once I have solved a coding problem, generally it "sticks". I had been reading about interior mutability, and it sort of made sense, but only when I actually coded an example today did I really take it in properly. It was the same with macros.

But you may be quite different.


Maybe some good resource here:

And the initial post looks like a good one to read:

You might be interested in Libre-SOC, which is a free and open-source hardware project, we're building a hybrid between a CPU and a GPU. I've been designing some of the hardware and writing a Vulkan driver for it in Rust. We're going to have our first engineering sample chips with a simple working CPU made in October 2020. We have funding available from NLNet, so you can get paid for completing tasks.
Anyone is welcome!


Is the CPU and GPU going to be not Intel AMD and Nvidia and instead is a foss manufacture?

Yes. We have been designing it for the last two years. This year we presented at both the OpenPower conference and at XDC2020:
OpenPower presentation:

Article on Phoronix:


I will take a look at the video, this project seems very interesting. Is the GPU capable for gaming at this time or is this something that can happen in the near future?

Not yet, we still have lots of work to do. We're building some initial test chips in december, but they won't be complete enough to do a whole lot. We also have to do a lot of work on the drivers.

If your interested, feel free to join our mailing lists, though they are rather high traffic: Mailing Lists

There is funding available if your interested in helping out.

1 Like

Very interesting.

I'm surprised and saddened to hear LibreSOC could not get on with the RISC V Foundation. I'm curious to know what the problems there were, given that many in the world are progressing well with RISC V.

But all that is way off topic for this forum.

1 Like

I see, good luck with it I hope it does succeeed :slight_smile:

Yeah sure sure I will join it :slight_smile:

I wish I can fund it, maybe in the near future if I can get a job.

One thing mate, would the CPUs be compatible with current motherboards?

Another thing, is it by any chance being developed within Australia?

If you like, you can ask all about it on our mailing lists (preferred) linked above or our IRC channel #libre-soc on freenode.

1 Like

Well, NLNet pays enough for Libre-SOC's tasks that I haven't needed another income source for 2 years (admittedly I don't need a lot of money), you should definitely consider working on Libre-SOC, though I completely understand if you decide not to.

If you want to help fund Libre-SOC, NLNet accepts tax-deductable donations. If that isn't suitable, we can probably figure something else out.

Most likely not, the current plan is for it to be more of a Raspberry Pi or cell phone style CPU where it's soldered to a PCB, rather than socketed like in most PCs.

Yes and no. We have people from all around the world helping out (USA, UK, France, India, Brazil, ...), but I don't think anyone from Australia yet, though there are people in Australia we are working closely with who are/were from the OpenPower Foundation and the Microwatt CPU.

1 Like

I'm not quite that ancient but I empathise with the other commenter about learning the fundamentals from building stuff . .

Like one day I can do this, it won't be any time soon, only when I can get a job :slight_smile:

I see, would it one day be for a normal desktop/tower/laptop? I think that would be a good idea to have something for the desktop market as a suggestion?

I see, Is there some easy programming task I could potentially do, I am in the process of learning Rust?


Me too! I am in Australia but prob won't be up to speed with serious Rust programming anytime soon but I will keep working on it!


Potentially, though that would be farther out than we have currently planned. We are planning on potentially putting it in something like a netbook.

Probably not in Rust, currently, though there will most likely be simpler stuff to do later. Most of the code we're currently working on is written in Python (though I wish it were practical to move everything to Rust). We're mostly trying to focus all our effort to get the code ready in time for manufacturing a test chip in December, so we're in crunch mode for now.

Check back later in December and we could probably find stuff to do then.

You could also join in the weekly Jitsi video calls if you like, they're with us and others interested in OpenPower, we talk some about OpenPower & Libre-SOC and other random stuff, they're quite informal.
They happen every Tuesday at 22:00 UTC and go for 30m to 1h

edit: removed meeting URLs due to not yet figuring out Jitsi's security yet, contact me or Libre-SOC mailing list and we will send you the URL privately.

1 Like

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.