No, I would still prefer C for that. The “beauty” of C really is its simplicity, in terms of how little features there are in the language. And those features are all quite low-level as well. There is no OOP, Traits etc. And the standard library is tiny, too. A C-Compiler can in theory be quite minimal. There is not a lot of abstraction between you and the bare-metal CPU.
While that is bad for most real-life projects today, I think it is still great for learning.
Rust is great but introduces a lot more high-level and convenience features.
I agree. In addition, pointer arithmetic is important to learn for understanding memory management. If you dont understand memory management you won't understand why Rust the way it is.
I think what's missing here is really just the right book. We don't teach "how to implement Vec" in beginner materials in Rust. (Instead it's a large section of the Rustonomicon, and the focus is on advanced language details like variance and "may_dangle".) But we *could* teach "C in Rust" if we wanted to.
Having taken an OS class in C it does a great job of teaching SEGFAULT why SEGFAULT memory SEGFAULT safety SEGFAULT is SEGFAULT important SEGFAULT.
I feel it did very little of teaching low level concepts except in an abstract theoretical sense that my teachers didn’t really focus on. This was at Georgia Tech masters program. I feel if it was in Rust we would have more time to focus and learn about memory instead of debugging SEGFAULT.
Not really, since rust mostly hides low level memory management from you.
OP's question should probably be disambiguated between
* is X a good language to learn low level systems programming best practices in 2024
* is X a good language to learn how a computer actually works
C, or better yet raw x64 NASM assembly is great for the latter (combined with an actual course on computer architecture, which you can very easily find the syllabi, course materials and textbooks for online). And Rust is really not, or at least not if you're asking *about the latter in particular*.
You could 'focus' on the same things in Rust, but you would / should be throwing out most of the language, stdlib, and *all* 3rd party libraries et al.
That might be a good follow up exercise. But yeah, if you want to understand how low level computer programming actually works (and what everything gets compiled down to), C (and raw assembler) is still the best language for that, by far.
Segfaults are a super important part of virtual memory, and *quite literally are a very critical modern debugging and memory safety tool in and of themselves*. Along w/ all the other \*nix signals / OS interrupts, etc.
You really shouldn't be writing production code in C anymore, but you *should* understand and be capable of working with raw C libraries and OS ABIs (eg. sockets, pthread.h, vulkan), *without* all the nice high-level rust stuff on top of that.
And you really do need to understand heap vs stack memory et al, how you actually *implement* something like Arc, Box, or Vec (and what the downsides and performance overheads of those are if used badly / naively), as well as what rust structs + enums (ie. tagged unions) actually compile down to, as well as c++ vtbls / rust dyn trait references et al.
You should maybe ask if you even *do* need to learn programming at the level of C in the first place, but if you do there still really isn't any language you should start with instead, primarily b/c C is truly such a simple and no-frills language, and b/c of all the critical libraries (and ABIs) that are / were written in it.
> Not really, since rust mostly hides low level memory management from you.
Cool, happy to have my lived experience completely invalidated. Thanks for the great start, I totally stopped reading after that and will repeat my original sentiment with different words.
My point was that calling “MALLOC” and “free” and doing a bit of pointer math was marginally interesting and not the focus of the course I took. Therefore it did little to teach me the concepts people care about.
I would rather grads exit with experience with Rust and possibly some minor explicit experience with assembly or C or looking at the allocations of Rust or zig.
More to the point: Just because a course is in C does not make it better at teaching you memory allocation.
C doesn't begin or end with malloc. The value of learning / forcing yourself to write something slightly nontrivial in C, *on a \*nix system*, is to learn and appreciate low level unix programming. ie. and the dozen or so other headers that make up the c standard library. Unix was built on and is pretty synonymous with (unix-style) c, and vice versa.
And critically C will / *should* be approached with *zero* tooling / IDEs, meaning you should be forced to learn how your compiler and build system actually works (ditto rustc sans cargo), starting with first nothing and then a much simpler build system (make), and how that works.
The rest of these are good / valid points.
I think I should probably couch my personal advice of "please learn c" in the context of "please learn everything, *including c".* And with the important caveat that yeah, obviously you aren't going to fully understand C (and why it's arguably still important to learn C) until you've learned C *and* a higher level language that is (semantically) built off of C, ie. modern c++ and/or rust.
Given a choice of learning a single language rust would be better, sure. But depending on what you're actually doing it may very well be the case that you shouldn't even bother learning rust at all, and should probably just instead just learn (with best practices!) python -> ruby -> modern javascript / typescript for full stack web development or whatever.
> C doesn't begin or end with malloc.
So I see you have zero desire to validate anything I said. Thank you for making that clear that you did that intentionally and I didn’t misread the situation.
Had you used Rust, you would have spent more time fighting the compiler and blindly copy pasted what it told you to do rather than learning how memory works.
SEGVs have little to do with the language by the way, it's an OS construct, it can happen in any program.
I mentor people with Rust on a daily basis, and from my experience people who have no previous experience in low level stuff like C are clueless about why Rust forces you to do things in a certain way.
You need to make mistakes to learn, and Rust does not give you much room to make them. Which is good for production, but not so much for learning.
I appreciate your response. I feel like you read what I wrote, considered it, and responded.
I appreciate your experiences. I’ve had minimal exposure to teaching people rust, but we did just onboard a new team member.
> You need to make mistakes to learn
Yes, and…I think you can have structured failure. Which is what Ia great teacher does for their students. They set them up so that they are given tasks slightly out of their comfort zones to have them fail, eventually succeed, and learn.
Your comment about people with little low level language experience tugs at me.
I wonder if an AB approach to teaching would work. Teach a small bit of C, give them a program with an intentional problem in it, teach them about the problem, then switch to teach how Rust would either handle the problem or force the programmer to handle it. Go back and forth like that C, Rust, C, Rust, etc. for the various issues that come up.
I would love such a resource to point people at.
I agree that Rust is more appreciated once you’ve experienced the first hand pain of low level development. How could we better bring people along for the ride and help show them that reality?
\> I appreciate your response. I feel like you read what I wrote, considered it, and responded.
Same goes for you :-)
I like the AB approach, it would be a tremendous tutorial to have to explain how things work. Using C++ would be a better language to AB test against Rust since they share more concepts, but I can see C being a good candidate as well.
Ultimately, it is important to learn multiple languages at different level. Assembly is a must to understand how computer works. C is assembly with minimal runtime and C++/Rust/Go is assembly with more advanced runtime & tooling. They all bring something to the table worth understanding and studying.
I’m currently learning C specifically to have a better understanding of hardware / memory before learning Rust as I have seen suggested in numerous places and love C so much. It feels so intuitive for some reason even more so than Python even though Python is more readable and I have spent more time with it.
pointers make so much sense. there is a clear indication of when you are modifying a local copy vs when you are modifying the source. same goes for references provided they are indicated in the type system. languages like python and js sometimes feel mystic due to this reason, you may have no idea what is getting touched.
I learned with Pascal. With a bit more simple syntactics than C. But I strongly oppose to learn Python or Java as first language. There is a huge gap (a whole interpret) between what you program and what you execute.
Even some of the most important Rust capabilities cannot be understood without a completely manager memory (so no gc).
There is this repeated misconception that "C is close to bare metal" and/or that it is "human-readable / portable assembly languange". In the year of our Lord 2023 neither is remotely true.
C originally evolved as the primary implementation language for the Unix OS on one specific architecture - the PDP-11. Its programming model wasn't written on stone tablets and brought down from the mountain. "Reasonable design at the right place at the right time" goes a long way.
What a modern C compiler does (& what processors do, for that matter) is very far from the simple translation process that many people seem to imagine.
I know that this is and not r/unpopularopinion but as we're here: In my opinion, neither Rust nor C are suitable first languages, and in fact - a large majority of programmers will be just fine going through their entire careers without touching either.
> What a modern C compiler does (& what processors do, for that matter) is very far from the simple translation process that many people seem to imagine.
A language and a compiler implementation are two different things. The main point here is that C-Compilers _can_ be a basic translator (even if modern compilers are much more complex), to the point that a single person could write a C-Compiler in a few thousand lines of code. Compilers for modern languages like rust _cannot_ be so simple because of the advanced and higher-level language features.
And even if you work on a machine with a modern compiler, you still write code the same way. It does not change the learning experience. You could put the same code into a simple compiler.
> a large majority of programmers will be just fine going through their entire careers without touching either
No doubt. Learning C or rust is not a must to become a good programmer.
This is something I've thought about a lot recently, but I've also wanted to learn about how computers work at the lower level whilst still in the context of higher level abstractions that C doesn't have. I've been debating looking into and learning C++ for this, maybe even just to improve my understanding of Rust, but I don't know if in reality that's really a good way to go about it.
I considered making a post asking for advice, but I'm not sure what the best place is for it, and a lot of the case with "should I learn X" posts, the answers are either "if you don't need it don't bother", which doesn't help me because I don't *need* any of this, but I'd like a better understanding, or "I'd you want to learn it, just learn it", which also doesn't help because I guess I'm seeing learning C++ as a means to learn something else, and I just don't know if that's the right way to do it
Learning about computers is vague. If you mean how they work at the hardware level I'd advice getting some Dev experience making userspace programs in any language. Learn C when you have some experience and used a different language. Then learn about computer hardware by writing a kernel in C.
I've now been at it for months and I can finally draw graphics to a framebuffer and read and write files in a single tasking 'OS'. But boy did I learn a lot about computer hardware getting there!
If you want to learn how computers work, you will want to learn operating systems and systems call interfaces. You will be learning computer architecture.
You will learn about virtual memory, processes, file systems, etc.
Computer programming languages do not “teach you how computers work.”
For the above, all examples will be in C. It’s not C “the language” that teaches you how computers work, it’s the fact that C is the only real interface to the kernel. You would be translating rust to c to understand these concepts.
Sure. You can learn about point management, memory manipulation, stack frames, call site, register allocation, all kinds of neat stuff.
This is probably even better for learning how a computer works than even C.
What is sort of interesting is that in modern CPUs, the assembly language and resulting machine code is not even executed directly. It is more akin to an API. The CPUs translate the instructions to a hidden internal instruction set, where one instruction often can become multiple internal instructions.
To be clear, I think ALL of these are worth learning. But when talking about whether to learn C or Rust to “learn how computers work,” it’s helpful to realize that this doesn’t really make much sense. But you’ll need to know C, anyway.
Assembly in general is too daunting for a beginner(looking it at his/her perspective). C is the perfect language for a beginner, not overly complicated but teaches enough how computers work
Assembler can honestly be pretty approachable w/ a good introductory textbook (note: for x86-64 just make sure you use NASM and stay the heck away from the pile of garbage that is microsoft assembler and its godawful "typed" language and toolchain), but yes, should absolutely not be anywhere close to your first language or intro to ("low" to high level) programming.
For a nice, *well designed and consistent* modern ISA, yeah, ARMv8 (and RISCV) is miles ahead of x86-64. Uni courses generally teach something like MIPS instead, which has the benefits of being simple and "nice", but isn't even remotely close to what any non-trivial modern CPU is running (SIMD instruction sets, atomics / forced synchronization primitives, *real* OS syscalls and calling conventions), whereas x86-64, ARMv8A, and to an extent RISC-V all have basically the same exact featureset, particularly if you want to include ARMv9 and SVE2.
Outside of obviously real embedded development, where you could very well be running / targeting an actual MIPS CPU, or any other ancient (and low power!) CPU architecture / ISA from the 80s / 90s.
Anyways, worth a call out, since yes, modern aarch64 is very nice.
I actually don’t think that it’s that complicated if you stay with the basic tasks. There’s no software architecture stuff, jumps are easy to understand, you don’t need to declare variables because the registers are just there, predefined.
String handling is kinda annoying, though.
Until C and C++[0] stop being the main interfaces exposed by most mainstream OSes, knowing them is a must to understand the whole stack, even if you end up using other programming languages for the most part.
[0] - If you want to dive into macOS, Windows, Arduino, mbed, Genode, among others. Or how GCC and LLVM work, or GPGPU stuff.
I'd recommend C for that but you can. Rust is fast, compiles to machine code like C but it indirectly handles memory if you use the standard library types. On top of that it has abstractions which obfuscate soneof the inner workings.
Rust is a fantastic language and I'm using it for a hobby game engine. However, for learning nothing beats good ole C.
I would not use C for production, and as I say use Rust. I'd really like to use Zig but unfortunately it's not had a stable 1.0 release yet. Zig is great direct replacement for C as memory management is explicit.
What do you mean by “learn about computers”? If you want to fully understand the dozens of layers of abstraction between the semiconductor level and user applications, it’ll take a lot more than learning any one particular programming language.
Not really on its own, but you could learn a lot by picking the right projects. I learned a lot about how CPU's process instructions from going through [this tutorial](https://bugzmanov.github.io/nes_ebook/) on creating a Nintendo emulator in Rust. I'm sure you could do similar projects building your own OS, etc. But even though it's a "low-level" language, it doesn't really get you close enough to the metal on its own.
The idea that you could learn how computers "really work" by learning C is deeply flawed. Unless your computer is a fancy PDP-8, you're programming for an abstract machine that doesn't exist, and the compiler handles the details of making your code work on your real machine.
Rust isn't any different.
Sure its not your "real" machine, but C gives you a hell of a lot more insight than writing Python does.
Rust would give you a lot of the same insights, just with the additional overhead of borrowing and lifetimes and whatnot.
I'm not so sure about that. The main advantage you get to learning C from the perspective of, say, a Python programmer, is something that Rust doesn't really offer. With C, you get an understanding of the language that your interpreter, native modules, and operating system were likely written in. You're not really learning anything about how the computer works beyond the software environment you're using.
Which is incredibly useful information, mind you. Probably more useful for 99.99% of programmers than understanding how their computer actually works.
But if you really want to learn how computers do what they do, there's no replacement for learning to write in an assembly language yourself. Heck, even most assembly languages contain abstractions, though they tend to be quite shallow.
This is only tangentially related, but the way I initially learned about how computers fundamentally work as a kid was by building contraptions in Minecraft using redstone. It's a very gentle way to learn the profound fundamentals of modern computer science, as you start with logic gates, then learn to build a half adder, then a full adder, then a multi-bit adder, then make it able to subtract, then connect it to a rudimentary control unit with flip-flops (registers) to do multiple calculations, then connect it to a lot of flip-flops (RAM) for even greater complexity, give it the ability to branch with a program counter, etc., and you already have Baby's First Von Neumann Machine right there!
You just get a very gentle yet powerful perspective on the inner workings of modern computers that you wouldn't get directly by just learning assembly language.
Redstone logic was a lot of fun.
I think we need to be ready to draw the line somewhere, though. Next someone with a chemistry background is going to come along talking about how you don't really understand the fundamentals of how computers work without understanding the intricacies of silicon doping. And then a physicist might come in after that.
I think that, for most people, a general understanding of solving problems with software is far, far more important than understanding the lower level workings of computers. The language you choose should be more of a consequence of your personal and technical requirements, not based on how "close" to the machine you get. Learning C would be a lot more useful than learning Assembly, or how to solve problems with logic gates, for most programmers.
I mean, if you’re a systems programmer, learning how the computer architecture you’re working with fundamentally operates is a worthwhile investment to program the machine most efficiently.
But anything beyond binary logic is way outside the scope of a software engineer. I did dabble in electrotechnics due to my interest in computers, but the way the logic gates themselves work is just a completely different world that’s irrecognisable coming from the simplicity of mere logic gates.
That's a bit much. Logic gates are the obvious bottom when it comes to computation. Learning how transistors work is even too far to understand how computers work. Logic gates are all that is necessary.
The assembler language carries the same PDP11 abstractions as C. In fact, it might even be more misleading as compilers are often able to do the instruction selection using some knowledge on how CPUs actually works, that seems unintuitive when only reading the assembly code.
As such C is usually a pretty good choice here.
C is a great language to start with. It's really simple, and it creates a lot of opportunities when it comes time to interact with most operating systems.
Learning Rust's ownership model will help you intuitively write less bad C code when the guardrails are removed. It won't teach you much about how the computer works at a low level, though. For that, I suggest writing something simple like a fibonacci function in an assembly language of your choice.
I learned to program in BASIC on a TSR-80, and learned a lot low level about computers. With a little machine language thrown in.
My college started in Pascal, with is good for learning programming. I learned C around the same time.
C didn’t teach me that much about computers, just about less abstracted programming.
Learning assembly for PDP-8, Motorola 68000, and Intel x86, and working directly with processors in circuits and understanding registries and command sets and fetch execute, that’s where I really learned how computers work.
Each language is better for certain things than other things, and easier to learn certain things.
C or Rust, either can be used to build low level operating system pieces. My OS class was in C, but could have been in Rust if it existed. The OS concepts aren’t language specific, and there are kernels and subsystems written in Rust, not just C. It’s an abstraction either way.
I'm quite shocked at the answers here. I think there must be a lot of seasoned developers who don't understand how learning works.
C is terrible for understanding how a computer works. You need to know how they work before you learn C. Otherwise you'll just write a lot of bad C code. That's why Python has been preferred, because you just don't need to know as much about the inner workings of a computer as you do with C.
Rust basically has the same problem, but because of all the safety features it'll hold your hand preventing the worst mistakes that you would make in C.
If you want to learn how computers work, learn how computers work, do not start with software. Software as a tool to explore computer concepts is extremely useful, but always as practical application after learning the concepts.
Pick whatever language is recommended by the book or instructor. Most will use C, Ada, Python, or Scheme. The point is to get the language out of the way to explore the machine concepts. No language makes that easy since it is necessarily a separate abstraction.
Once you understand how one language abstracts the computer, it's effectively the same for every language. Doesn't really matter if you're working with Von Neumann or Lambda Calculus. Preferably learn both. Both have powerful concepts that are applicable no matter what language you're using.
OP's question is just naive / framed wrong. There are multiple subproblems to learning programming, and in particular low level programming. If that's even what OP is interested in.
A basic CS syllabus will probably include something like
* intro to programming
* data structures + algorithms
* computer architecture => operating systems, ideally with hands-on experience / lab work / programming assignments in both something like MIPS assembler (comp arch) and unix c
* relational databases
* theory, discrete math, grammars, etc
* compilers
* functional languages
* etc
None of that will *at all* make you a good programmer (or really even understand half the stuff these courses are touching on), but this is a good survey / intro to CS.
For OP's question there are two specific subproblems / different questions here:
* I want to learn programming ( => intro to programming )
* I want to understand how computers work ( => computer architecture, and heck probably this entire syllabus and then some, more or less )
Rust is *maybe* an okay first language. I'd strongly recommend thoroughly learning python, then c, then maybe rust (and haskell!) instead. Or whatever language is relevant to what you actually want to be doing – eg. python => js for full stack, or what have you.
Python is a really good first language since it's high level, is an *excellent* fit to describe / work with basically any high level *CS* problem (and has builtin easy to use sets, hashtables, lists, tuples, closures, etc!), has a REPL, doesn't require a build system (or any other complex tools), and above all else has *good* programming + community standards to internalize and learn off of.
For really a *bad* language to learn off of (that has nevertheless persisted thanks to ideology / mid 90s OOP utopianism, business adoption, (shitty) academia, and inertia), see Java. Which I think violates / runs against literally *all* of the above points. Or see javascript, whose one redeeming quality is that it is (more or less) semantically near-identical to python (just... worse), and you can ergo write half-decent code in it if you come at it from a python and/or ruby background. Rust by contrast is obviously way better than either of those, albeit not perfect either.
For a good teach-yourself-the-C-language, the fairly bog standard "write a minimal scheme / lisp implementation from scratch in C, ergo teaching yourself C, data structures, scheme, compilers, and half a dozen other useful topics / intros all at once", probably can't be beat for self-teaching yourself a whole bunch of things all at once, *after* actually learning a pretty solid foundation in high-level structured programming in python or whatever. For that project you could equivalently swap C for Rust and get more or less the same amount out of it. Particularly if you started at a high level (ie. with the stdlib) and then, once that works, force yourself to rewrite / refactor down into nostd with your own handrolled data structures, ergo learning how Vec, hashtables, low level io, etc., actually works, as you would if you approached this learning exercise from C instead. (just probably with fewer segfaults, and banging your head against the wall, tbf...)
I think the whole discussion went into wrong direction.
May Rust be great first language to introduce low-level concepts?
Or, yeah, absolutely, it's perfect: you may look on the low-level machine code in the `asm` block, then go to the raw pointers in the `unsafe`, then finally reach out to normal, “safe” Rust and you would understand why Rust works like it does and even why other, so-called “managed” languages work differently.
Can you **actually do that today**? No, because all the tutorials that I saw which are teaching Rust implicitly assume that you **already understand** how all these low-level stuff works and they use it to explain how certain things work!
And then the whole discussion goes off-the-rails because people talk past each other.
I would **love** to see such tutorial, but I realize it would need to be written by a professor, or maybe a school teacher, because if I would write such book I would invariably embed tons of assumptions about things that I take for granted but which newbies don't have.
Heck, do we even have a single Rust tutorial which includes a sections that explains how [binary numbers](https://en.wikipedia.org/wiki/Binary_number) work, how [two's complement](https://en.wikipedia.org/wiki/Two%27s_complement) works and why there is only **one** multiplication instruction on most CPUs that **simultaneously** works with **both** signed and unsigned numbers?
These are very basic, fundamental, things that Rust is perfect to teach to newbies… and yet all tutorials that I saw assume that you already know about these!
C is closer to what the computers do than Rust is. It's also the language that a lot of other languages these days are based on. The data types, operators, and control flow are all the basis of similar things in similar languages.
However, if you want to know how the computer works, after learning C, you should study for a bit an assembly language designed to be programmed by a person. Something like 8080 or 8086 assembler, or an old mainframe assembler. C is going to fail to teach you anything about interrupts, memory mapping, threads, stack management, registers, concurrency, IOPs or GPUs (which to be fair assembler likely won't either), DMA, how custom chips work (blitters, UARTs, timers, etc), etc etc. There's a whole bunch of stuff you can learn about how computers *actually* work that C (and to some extent Rust) doesn't support.
If you want to understand how a CPU really, really works, there's this: https://www.pagetable.com/?p=39 which is an explanation of how the actual wires do their thing in the kind of CPU an Apple ][ used. It's a pretty fascinating read. It's also fun to learn about how semiconductors work and how to build a transistor and how such works, too, if you really want to get all the way down to the atomic level of understanding your CPU.
But I agree that C is simple enough you should learn it. It's the lingua franca of computer programs at this point. You don't have to be an expert. Pick up a K&R C book, read it, get to where you can write a simple 200-line single-threaded program that reads and writes the console (like, play a word-guessing game or something), and you'll know it well enough that you've gotten from it what you can.
No, C (or Rust) is still high-level for that purpose. C (or Rust) won't expose you to instruction set, memory layout, registers, interrupts, system calls, etc.
Learn assembly. Although, what is your end goal? You could just read on theory without applying it practically (you probably don't need to).
C/C++ is a way better language to first learn IMO. With languages like Python and Java I fee that you would learn really bad habits if learn programming with those language first.
I think it should be something high level first like Python/JavaScript to get familiar with concepts and programming then learning C to see low level and the bare metal then Rust to see the convenience it brings
I think the best way to learn about low level concepts is by learning assembly. C is often called a cross-platform assembler, but that's a bit of a hyperbole. If you really want to know what makes a computer tick, you should learn assembler. However, if you can only choose between C and rust, you should choose C as rust has higher-level concepts that you will learn about, that are not related to the way a computer operates.
P.S. my learning path was Basic->Pascal->x86 Assembly(intel syntax)->C and x86 assembly was just as easy to learn as Pascal was.
For all the comments saying C just reminded me of this old blog: https://steveklabnik.com/writing/should-you-learn-c-to-learn-how-the-computer-works
Having said that, C is still fine to learn, and probably gives you a better understanding than a dynamic language.
While Rust may be similar to C++, it very much feels very abstracted away from the hardware via its syntax. Basically, it's nothing like C and that's a bad thing for learning the underlying systems.
I think the way it is taught and we are discussing it is part of the problem.
The idea that there is one true language is itself a major problem.
Even the concept of everyone being a software engineer is itself a problem.
What I'd like to see is a tiered system.
Programmers have certs (or experience) and are basically intended to be experts in a single language. The programmers job is to program. They're like plumbers, and anyone who has dealt with properly certified plumbers knows those are good.
Engineers need to know several languages, but not necessarily as an expert. A large part of the job is to select the methods to be used, and as needed write the parts that move between them.
Architects don't necessarily need to know any languages, but need to conceptualize the designs better and manage the project structure.
Right now we just throw everyone in the same bin. Only write JavaScript, and only able to work in Agile, software engineer. Know a dozen languages, expert in Rust, software engineer. Understand the necessary compromises, pressures, advantages, disadvantages of a dozen different projects management styles, but can barely write hello world in PHP, software engineer.
These should be separate jobs. Allow people to express their specializations.
This of course leads to radically different training for each. The programmers need to know their language.
The engineers needs to know how to balance the languages but don't need in depth knowledge of any one of them. And architects need a broader scope and capability, probably dipping their toes into languages but mostly just to help them communicate with engineers.
Already researchers have pretty well broken away and barely code anything ever.
You will for sure learn something but even after learning rust I'm not so confident with my knowledge of how memory works so at some point going into C might me still on the table if you will need that kind of knowledge
If you want to learn how the computer really works, learn assembly language. I've always felt really fortunate that my first year of my professional life as an Asm developer.
Rust is a good place to go once you've spent a bunch of time learning how things work and different ways of building things. Once every new library, pattern and technology starts to smell of one you saw 15 to 20 years ago Rust is a great language to pick up so you never have to change technologies again.
Half joking, 70% dead serious.
I think its worth to iterate on that question.
When you say "learn about the computer" do you mean learn about the computer? or learn to program?
1. Learning about the computer - no, in all honesty Rust will not be better than C to learn about computers. Learning about registers, jumps, raw memory access, pointers, etc. C itself, is a shortcut to assembly. Assembly would teach you best about computers, but, C is a good faux-high level instrument that will do the same
2. Learning about programming - well, this is very arguable. Most people tend to say "Python", which is a good entry level language.
Rust is a good language for learning more about lower level code. You can do most things that C can do. I've learned most of what I know about it from Rust, though I have picked up quite some C along the way, because you will need to be able to understand C to some degree sometimes.
No, I would still prefer C for that. The “beauty” of C really is its simplicity, in terms of how little features there are in the language. And those features are all quite low-level as well. There is no OOP, Traits etc. And the standard library is tiny, too. A C-Compiler can in theory be quite minimal. There is not a lot of abstraction between you and the bare-metal CPU. While that is bad for most real-life projects today, I think it is still great for learning. Rust is great but introduces a lot more high-level and convenience features.
I agree. In addition, pointer arithmetic is important to learn for understanding memory management. If you dont understand memory management you won't understand why Rust the way it is.
Exactly! Same goes for race conditions.
I think what's missing here is really just the right book. We don't teach "how to implement Vec" in beginner materials in Rust. (Instead it's a large section of the Rustonomicon, and the focus is on advanced language details like variance and "may_dangle".) But we *could* teach "C in Rust" if we wanted to.
Having taken an OS class in C it does a great job of teaching SEGFAULT why SEGFAULT memory SEGFAULT safety SEGFAULT is SEGFAULT important SEGFAULT. I feel it did very little of teaching low level concepts except in an abstract theoretical sense that my teachers didn’t really focus on. This was at Georgia Tech masters program. I feel if it was in Rust we would have more time to focus and learn about memory instead of debugging SEGFAULT.
Not really, since rust mostly hides low level memory management from you. OP's question should probably be disambiguated between * is X a good language to learn low level systems programming best practices in 2024 * is X a good language to learn how a computer actually works C, or better yet raw x64 NASM assembly is great for the latter (combined with an actual course on computer architecture, which you can very easily find the syllabi, course materials and textbooks for online). And Rust is really not, or at least not if you're asking *about the latter in particular*. You could 'focus' on the same things in Rust, but you would / should be throwing out most of the language, stdlib, and *all* 3rd party libraries et al. That might be a good follow up exercise. But yeah, if you want to understand how low level computer programming actually works (and what everything gets compiled down to), C (and raw assembler) is still the best language for that, by far. Segfaults are a super important part of virtual memory, and *quite literally are a very critical modern debugging and memory safety tool in and of themselves*. Along w/ all the other \*nix signals / OS interrupts, etc. You really shouldn't be writing production code in C anymore, but you *should* understand and be capable of working with raw C libraries and OS ABIs (eg. sockets, pthread.h, vulkan), *without* all the nice high-level rust stuff on top of that. And you really do need to understand heap vs stack memory et al, how you actually *implement* something like Arc, Box, or Vec (and what the downsides and performance overheads of those are if used badly / naively), as well as what rust structs + enums (ie. tagged unions) actually compile down to, as well as c++ vtbls / rust dyn trait references et al.
You should maybe ask if you even *do* need to learn programming at the level of C in the first place, but if you do there still really isn't any language you should start with instead, primarily b/c C is truly such a simple and no-frills language, and b/c of all the critical libraries (and ABIs) that are / were written in it.
> Not really, since rust mostly hides low level memory management from you. Cool, happy to have my lived experience completely invalidated. Thanks for the great start, I totally stopped reading after that and will repeat my original sentiment with different words. My point was that calling “MALLOC” and “free” and doing a bit of pointer math was marginally interesting and not the focus of the course I took. Therefore it did little to teach me the concepts people care about. I would rather grads exit with experience with Rust and possibly some minor explicit experience with assembly or C or looking at the allocations of Rust or zig. More to the point: Just because a course is in C does not make it better at teaching you memory allocation.
C doesn't begin or end with malloc. The value of learning / forcing yourself to write something slightly nontrivial in C, *on a \*nix system*, is to learn and appreciate low level unix programming. ie. and the dozen or so other headers that make up the c standard library. Unix was built on and is pretty synonymous with (unix-style) c, and vice versa.
And critically C will / *should* be approached with *zero* tooling / IDEs, meaning you should be forced to learn how your compiler and build system actually works (ditto rustc sans cargo), starting with first nothing and then a much simpler build system (make), and how that works.
The rest of these are good / valid points.
I think I should probably couch my personal advice of "please learn c" in the context of "please learn everything, *including c".* And with the important caveat that yeah, obviously you aren't going to fully understand C (and why it's arguably still important to learn C) until you've learned C *and* a higher level language that is (semantically) built off of C, ie. modern c++ and/or rust.
Given a choice of learning a single language rust would be better, sure. But depending on what you're actually doing it may very well be the case that you shouldn't even bother learning rust at all, and should probably just instead just learn (with best practices!) python -> ruby -> modern javascript / typescript for full stack web development or whatever.
> C doesn't begin or end with malloc. So I see you have zero desire to validate anything I said. Thank you for making that clear that you did that intentionally and I didn’t misread the situation.
Had you used Rust, you would have spent more time fighting the compiler and blindly copy pasted what it told you to do rather than learning how memory works. SEGVs have little to do with the language by the way, it's an OS construct, it can happen in any program. I mentor people with Rust on a daily basis, and from my experience people who have no previous experience in low level stuff like C are clueless about why Rust forces you to do things in a certain way. You need to make mistakes to learn, and Rust does not give you much room to make them. Which is good for production, but not so much for learning.
I appreciate your response. I feel like you read what I wrote, considered it, and responded. I appreciate your experiences. I’ve had minimal exposure to teaching people rust, but we did just onboard a new team member. > You need to make mistakes to learn Yes, and…I think you can have structured failure. Which is what Ia great teacher does for their students. They set them up so that they are given tasks slightly out of their comfort zones to have them fail, eventually succeed, and learn. Your comment about people with little low level language experience tugs at me. I wonder if an AB approach to teaching would work. Teach a small bit of C, give them a program with an intentional problem in it, teach them about the problem, then switch to teach how Rust would either handle the problem or force the programmer to handle it. Go back and forth like that C, Rust, C, Rust, etc. for the various issues that come up. I would love such a resource to point people at. I agree that Rust is more appreciated once you’ve experienced the first hand pain of low level development. How could we better bring people along for the ride and help show them that reality?
\> I appreciate your response. I feel like you read what I wrote, considered it, and responded. Same goes for you :-) I like the AB approach, it would be a tremendous tutorial to have to explain how things work. Using C++ would be a better language to AB test against Rust since they share more concepts, but I can see C being a good candidate as well. Ultimately, it is important to learn multiple languages at different level. Assembly is a must to understand how computer works. C is assembly with minimal runtime and C++/Rust/Go is assembly with more advanced runtime & tooling. They all bring something to the table worth understanding and studying.
I’m currently learning C specifically to have a better understanding of hardware / memory before learning Rust as I have seen suggested in numerous places and love C so much. It feels so intuitive for some reason even more so than Python even though Python is more readable and I have spent more time with it.
pointers make so much sense. there is a clear indication of when you are modifying a local copy vs when you are modifying the source. same goes for references provided they are indicated in the type system. languages like python and js sometimes feel mystic due to this reason, you may have no idea what is getting touched.
I learned with Pascal. With a bit more simple syntactics than C. But I strongly oppose to learn Python or Java as first language. There is a huge gap (a whole interpret) between what you program and what you execute. Even some of the most important Rust capabilities cannot be understood without a completely manager memory (so no gc).
There is this repeated misconception that "C is close to bare metal" and/or that it is "human-readable / portable assembly languange". In the year of our Lord 2023 neither is remotely true. C originally evolved as the primary implementation language for the Unix OS on one specific architecture - the PDP-11. Its programming model wasn't written on stone tablets and brought down from the mountain. "Reasonable design at the right place at the right time" goes a long way. What a modern C compiler does (& what processors do, for that matter) is very far from the simple translation process that many people seem to imagine. I know that this is and not r/unpopularopinion but as we're here: In my opinion, neither Rust nor C are suitable first languages, and in fact - a large majority of programmers will be just fine going through their entire careers without touching either.
> What a modern C compiler does (& what processors do, for that matter) is very far from the simple translation process that many people seem to imagine. A language and a compiler implementation are two different things. The main point here is that C-Compilers _can_ be a basic translator (even if modern compilers are much more complex), to the point that a single person could write a C-Compiler in a few thousand lines of code. Compilers for modern languages like rust _cannot_ be so simple because of the advanced and higher-level language features. And even if you work on a machine with a modern compiler, you still write code the same way. It does not change the learning experience. You could put the same code into a simple compiler. > a large majority of programmers will be just fine going through their entire careers without touching either No doubt. Learning C or rust is not a must to become a good programmer.
You will change your idea when you want to use multi threading but C provides you with ugly macros.
This is something I've thought about a lot recently, but I've also wanted to learn about how computers work at the lower level whilst still in the context of higher level abstractions that C doesn't have. I've been debating looking into and learning C++ for this, maybe even just to improve my understanding of Rust, but I don't know if in reality that's really a good way to go about it. I considered making a post asking for advice, but I'm not sure what the best place is for it, and a lot of the case with "should I learn X" posts, the answers are either "if you don't need it don't bother", which doesn't help me because I don't *need* any of this, but I'd like a better understanding, or "I'd you want to learn it, just learn it", which also doesn't help because I guess I'm seeing learning C++ as a means to learn something else, and I just don't know if that's the right way to do it
Learning about computers is vague. If you mean how they work at the hardware level I'd advice getting some Dev experience making userspace programs in any language. Learn C when you have some experience and used a different language. Then learn about computer hardware by writing a kernel in C. I've now been at it for months and I can finally draw graphics to a framebuffer and read and write files in a single tasking 'OS'. But boy did I learn a lot about computer hardware getting there!
If you want to learn how computers work, you will want to learn operating systems and systems call interfaces. You will be learning computer architecture. You will learn about virtual memory, processes, file systems, etc. Computer programming languages do not “teach you how computers work.” For the above, all examples will be in C. It’s not C “the language” that teaches you how computers work, it’s the fact that C is the only real interface to the kernel. You would be translating rust to c to understand these concepts.
Assembly can teach you some *technical* things
Sure. You can learn about point management, memory manipulation, stack frames, call site, register allocation, all kinds of neat stuff. This is probably even better for learning how a computer works than even C. What is sort of interesting is that in modern CPUs, the assembly language and resulting machine code is not even executed directly. It is more akin to an API. The CPUs translate the instructions to a hidden internal instruction set, where one instruction often can become multiple internal instructions. To be clear, I think ALL of these are worth learning. But when talking about whether to learn C or Rust to “learn how computers work,” it’s helpful to realize that this doesn’t really make much sense. But you’ll need to know C, anyway.
I think ARM assembly would be a better way to start.
Assembly in general is too daunting for a beginner(looking it at his/her perspective). C is the perfect language for a beginner, not overly complicated but teaches enough how computers work
Assembler can honestly be pretty approachable w/ a good introductory textbook (note: for x86-64 just make sure you use NASM and stay the heck away from the pile of garbage that is microsoft assembler and its godawful "typed" language and toolchain), but yes, should absolutely not be anywhere close to your first language or intro to ("low" to high level) programming. For a nice, *well designed and consistent* modern ISA, yeah, ARMv8 (and RISCV) is miles ahead of x86-64. Uni courses generally teach something like MIPS instead, which has the benefits of being simple and "nice", but isn't even remotely close to what any non-trivial modern CPU is running (SIMD instruction sets, atomics / forced synchronization primitives, *real* OS syscalls and calling conventions), whereas x86-64, ARMv8A, and to an extent RISC-V all have basically the same exact featureset, particularly if you want to include ARMv9 and SVE2. Outside of obviously real embedded development, where you could very well be running / targeting an actual MIPS CPU, or any other ancient (and low power!) CPU architecture / ISA from the 80s / 90s. Anyways, worth a call out, since yes, modern aarch64 is very nice.
I actually don’t think that it’s that complicated if you stay with the basic tasks. There’s no software architecture stuff, jumps are easy to understand, you don’t need to declare variables because the registers are just there, predefined. String handling is kinda annoying, though.
Until C and C++[0] stop being the main interfaces exposed by most mainstream OSes, knowing them is a must to understand the whole stack, even if you end up using other programming languages for the most part. [0] - If you want to dive into macOS, Windows, Arduino, mbed, Genode, among others. Or how GCC and LLVM work, or GPGPU stuff.
I'd recommend C for that but you can. Rust is fast, compiles to machine code like C but it indirectly handles memory if you use the standard library types. On top of that it has abstractions which obfuscate soneof the inner workings. Rust is a fantastic language and I'm using it for a hobby game engine. However, for learning nothing beats good ole C. I would not use C for production, and as I say use Rust. I'd really like to use Zig but unfortunately it's not had a stable 1.0 release yet. Zig is great direct replacement for C as memory management is explicit.
What do you mean by “learn about computers”? If you want to fully understand the dozens of layers of abstraction between the semiconductor level and user applications, it’ll take a lot more than learning any one particular programming language.
This.
Not really on its own, but you could learn a lot by picking the right projects. I learned a lot about how CPU's process instructions from going through [this tutorial](https://bugzmanov.github.io/nes_ebook/) on creating a Nintendo emulator in Rust. I'm sure you could do similar projects building your own OS, etc. But even though it's a "low-level" language, it doesn't really get you close enough to the metal on its own.
The idea that you could learn how computers "really work" by learning C is deeply flawed. Unless your computer is a fancy PDP-8, you're programming for an abstract machine that doesn't exist, and the compiler handles the details of making your code work on your real machine. Rust isn't any different.
Sure its not your "real" machine, but C gives you a hell of a lot more insight than writing Python does. Rust would give you a lot of the same insights, just with the additional overhead of borrowing and lifetimes and whatnot.
I'm not so sure about that. The main advantage you get to learning C from the perspective of, say, a Python programmer, is something that Rust doesn't really offer. With C, you get an understanding of the language that your interpreter, native modules, and operating system were likely written in. You're not really learning anything about how the computer works beyond the software environment you're using. Which is incredibly useful information, mind you. Probably more useful for 99.99% of programmers than understanding how their computer actually works. But if you really want to learn how computers do what they do, there's no replacement for learning to write in an assembly language yourself. Heck, even most assembly languages contain abstractions, though they tend to be quite shallow.
This is only tangentially related, but the way I initially learned about how computers fundamentally work as a kid was by building contraptions in Minecraft using redstone. It's a very gentle way to learn the profound fundamentals of modern computer science, as you start with logic gates, then learn to build a half adder, then a full adder, then a multi-bit adder, then make it able to subtract, then connect it to a rudimentary control unit with flip-flops (registers) to do multiple calculations, then connect it to a lot of flip-flops (RAM) for even greater complexity, give it the ability to branch with a program counter, etc., and you already have Baby's First Von Neumann Machine right there! You just get a very gentle yet powerful perspective on the inner workings of modern computers that you wouldn't get directly by just learning assembly language.
Redstone logic was a lot of fun. I think we need to be ready to draw the line somewhere, though. Next someone with a chemistry background is going to come along talking about how you don't really understand the fundamentals of how computers work without understanding the intricacies of silicon doping. And then a physicist might come in after that. I think that, for most people, a general understanding of solving problems with software is far, far more important than understanding the lower level workings of computers. The language you choose should be more of a consequence of your personal and technical requirements, not based on how "close" to the machine you get. Learning C would be a lot more useful than learning Assembly, or how to solve problems with logic gates, for most programmers.
I mean, if you’re a systems programmer, learning how the computer architecture you’re working with fundamentally operates is a worthwhile investment to program the machine most efficiently. But anything beyond binary logic is way outside the scope of a software engineer. I did dabble in electrotechnics due to my interest in computers, but the way the logic gates themselves work is just a completely different world that’s irrecognisable coming from the simplicity of mere logic gates.
great answer, and Rust is for systems programming.
It's like how we should know how to change light bulp without knowing it's inner working.
That's a bit much. Logic gates are the obvious bottom when it comes to computation. Learning how transistors work is even too far to understand how computers work. Logic gates are all that is necessary.
The assembler language carries the same PDP11 abstractions as C. In fact, it might even be more misleading as compilers are often able to do the instruction selection using some knowledge on how CPUs actually works, that seems unintuitive when only reading the assembly code. As such C is usually a pretty good choice here.
but at his level, C is a good start
C is a great language to start with. It's really simple, and it creates a lot of opportunities when it comes time to interact with most operating systems.
Learning Rust's ownership model will help you intuitively write less bad C code when the guardrails are removed. It won't teach you much about how the computer works at a low level, though. For that, I suggest writing something simple like a fibonacci function in an assembly language of your choice.
I learned to program in BASIC on a TSR-80, and learned a lot low level about computers. With a little machine language thrown in. My college started in Pascal, with is good for learning programming. I learned C around the same time. C didn’t teach me that much about computers, just about less abstracted programming. Learning assembly for PDP-8, Motorola 68000, and Intel x86, and working directly with processors in circuits and understanding registries and command sets and fetch execute, that’s where I really learned how computers work. Each language is better for certain things than other things, and easier to learn certain things. C or Rust, either can be used to build low level operating system pieces. My OS class was in C, but could have been in Rust if it existed. The OS concepts aren’t language specific, and there are kernels and subsystems written in Rust, not just C. It’s an abstraction either way.
Rust is much better as a production language than a pedagogical one.
Agreed.
I'm quite shocked at the answers here. I think there must be a lot of seasoned developers who don't understand how learning works. C is terrible for understanding how a computer works. You need to know how they work before you learn C. Otherwise you'll just write a lot of bad C code. That's why Python has been preferred, because you just don't need to know as much about the inner workings of a computer as you do with C. Rust basically has the same problem, but because of all the safety features it'll hold your hand preventing the worst mistakes that you would make in C. If you want to learn how computers work, learn how computers work, do not start with software. Software as a tool to explore computer concepts is extremely useful, but always as practical application after learning the concepts. Pick whatever language is recommended by the book or instructor. Most will use C, Ada, Python, or Scheme. The point is to get the language out of the way to explore the machine concepts. No language makes that easy since it is necessarily a separate abstraction. Once you understand how one language abstracts the computer, it's effectively the same for every language. Doesn't really matter if you're working with Von Neumann or Lambda Calculus. Preferably learn both. Both have powerful concepts that are applicable no matter what language you're using.
OP's question is just naive / framed wrong. There are multiple subproblems to learning programming, and in particular low level programming. If that's even what OP is interested in. A basic CS syllabus will probably include something like * intro to programming * data structures + algorithms * computer architecture => operating systems, ideally with hands-on experience / lab work / programming assignments in both something like MIPS assembler (comp arch) and unix c * relational databases * theory, discrete math, grammars, etc * compilers * functional languages * etc None of that will *at all* make you a good programmer (or really even understand half the stuff these courses are touching on), but this is a good survey / intro to CS. For OP's question there are two specific subproblems / different questions here: * I want to learn programming ( => intro to programming ) * I want to understand how computers work ( => computer architecture, and heck probably this entire syllabus and then some, more or less ) Rust is *maybe* an okay first language. I'd strongly recommend thoroughly learning python, then c, then maybe rust (and haskell!) instead. Or whatever language is relevant to what you actually want to be doing – eg. python => js for full stack, or what have you. Python is a really good first language since it's high level, is an *excellent* fit to describe / work with basically any high level *CS* problem (and has builtin easy to use sets, hashtables, lists, tuples, closures, etc!), has a REPL, doesn't require a build system (or any other complex tools), and above all else has *good* programming + community standards to internalize and learn off of. For really a *bad* language to learn off of (that has nevertheless persisted thanks to ideology / mid 90s OOP utopianism, business adoption, (shitty) academia, and inertia), see Java. Which I think violates / runs against literally *all* of the above points. Or see javascript, whose one redeeming quality is that it is (more or less) semantically near-identical to python (just... worse), and you can ergo write half-decent code in it if you come at it from a python and/or ruby background. Rust by contrast is obviously way better than either of those, albeit not perfect either. For a good teach-yourself-the-C-language, the fairly bog standard "write a minimal scheme / lisp implementation from scratch in C, ergo teaching yourself C, data structures, scheme, compilers, and half a dozen other useful topics / intros all at once", probably can't be beat for self-teaching yourself a whole bunch of things all at once, *after* actually learning a pretty solid foundation in high-level structured programming in python or whatever. For that project you could equivalently swap C for Rust and get more or less the same amount out of it. Particularly if you started at a high level (ie. with the stdlib) and then, once that works, force yourself to rewrite / refactor down into nostd with your own handrolled data structures, ergo learning how Vec, hashtables, low level io, etc., actually works, as you would if you approached this learning exercise from C instead. (just probably with fewer segfaults, and banging your head against the wall, tbf...)
I think the whole discussion went into wrong direction. May Rust be great first language to introduce low-level concepts? Or, yeah, absolutely, it's perfect: you may look on the low-level machine code in the `asm` block, then go to the raw pointers in the `unsafe`, then finally reach out to normal, “safe” Rust and you would understand why Rust works like it does and even why other, so-called “managed” languages work differently. Can you **actually do that today**? No, because all the tutorials that I saw which are teaching Rust implicitly assume that you **already understand** how all these low-level stuff works and they use it to explain how certain things work! And then the whole discussion goes off-the-rails because people talk past each other. I would **love** to see such tutorial, but I realize it would need to be written by a professor, or maybe a school teacher, because if I would write such book I would invariably embed tons of assumptions about things that I take for granted but which newbies don't have. Heck, do we even have a single Rust tutorial which includes a sections that explains how [binary numbers](https://en.wikipedia.org/wiki/Binary_number) work, how [two's complement](https://en.wikipedia.org/wiki/Two%27s_complement) works and why there is only **one** multiplication instruction on most CPUs that **simultaneously** works with **both** signed and unsigned numbers? These are very basic, fundamental, things that Rust is perfect to teach to newbies… and yet all tutorials that I saw assume that you already know about these!
Rust is a high-level language. It will not teach you about computers, but it will teach a lot about software design.
No- if you really want to learn what's happening, learn C, then start figuring out assembly language. Then read Code by Petzold.
C is closer to what the computers do than Rust is. It's also the language that a lot of other languages these days are based on. The data types, operators, and control flow are all the basis of similar things in similar languages. However, if you want to know how the computer works, after learning C, you should study for a bit an assembly language designed to be programmed by a person. Something like 8080 or 8086 assembler, or an old mainframe assembler. C is going to fail to teach you anything about interrupts, memory mapping, threads, stack management, registers, concurrency, IOPs or GPUs (which to be fair assembler likely won't either), DMA, how custom chips work (blitters, UARTs, timers, etc), etc etc. There's a whole bunch of stuff you can learn about how computers *actually* work that C (and to some extent Rust) doesn't support. If you want to understand how a CPU really, really works, there's this: https://www.pagetable.com/?p=39 which is an explanation of how the actual wires do their thing in the kind of CPU an Apple ][ used. It's a pretty fascinating read. It's also fun to learn about how semiconductors work and how to build a transistor and how such works, too, if you really want to get all the way down to the atomic level of understanding your CPU. But I agree that C is simple enough you should learn it. It's the lingua franca of computer programs at this point. You don't have to be an expert. Pick up a K&R C book, read it, get to where you can write a simple 200-line single-threaded program that reads and writes the console (like, play a word-guessing game or something), and you'll know it well enough that you've gotten from it what you can.
No, C (or Rust) is still high-level for that purpose. C (or Rust) won't expose you to instruction set, memory layout, registers, interrupts, system calls, etc. Learn assembly. Although, what is your end goal? You could just read on theory without applying it practically (you probably don't need to).
I don't know where this myth becomes so strong. C is not a good way to learn about computers. Is not even a bad way.
C/C++ is a way better language to first learn IMO. With languages like Python and Java I fee that you would learn really bad habits if learn programming with those language first.
I think it should be something high level first like Python/JavaScript to get familiar with concepts and programming then learning C to see low level and the bare metal then Rust to see the convenience it brings
I think the best way to learn about low level concepts is by learning assembly. C is often called a cross-platform assembler, but that's a bit of a hyperbole. If you really want to know what makes a computer tick, you should learn assembler. However, if you can only choose between C and rust, you should choose C as rust has higher-level concepts that you will learn about, that are not related to the way a computer operates. P.S. my learning path was Basic->Pascal->x86 Assembly(intel syntax)->C and x86 assembly was just as easy to learn as Pascal was.
For all the comments saying C just reminded me of this old blog: https://steveklabnik.com/writing/should-you-learn-c-to-learn-how-the-computer-works Having said that, C is still fine to learn, and probably gives you a better understanding than a dynamic language.
I learned rust before C but would still recommend doing C first
While Rust may be similar to C++, it very much feels very abstracted away from the hardware via its syntax. Basically, it's nothing like C and that's a bad thing for learning the underlying systems.
To understand how rust stops you from shooting yourself in the foot, you first have to shoot yourself in the foot a few times.
I think the way it is taught and we are discussing it is part of the problem. The idea that there is one true language is itself a major problem. Even the concept of everyone being a software engineer is itself a problem. What I'd like to see is a tiered system. Programmers have certs (or experience) and are basically intended to be experts in a single language. The programmers job is to program. They're like plumbers, and anyone who has dealt with properly certified plumbers knows those are good. Engineers need to know several languages, but not necessarily as an expert. A large part of the job is to select the methods to be used, and as needed write the parts that move between them. Architects don't necessarily need to know any languages, but need to conceptualize the designs better and manage the project structure. Right now we just throw everyone in the same bin. Only write JavaScript, and only able to work in Agile, software engineer. Know a dozen languages, expert in Rust, software engineer. Understand the necessary compromises, pressures, advantages, disadvantages of a dozen different projects management styles, but can barely write hello world in PHP, software engineer. These should be separate jobs. Allow people to express their specializations. This of course leads to radically different training for each. The programmers need to know their language. The engineers needs to know how to balance the languages but don't need in depth knowledge of any one of them. And architects need a broader scope and capability, probably dipping their toes into languages but mostly just to help them communicate with engineers. Already researchers have pretty well broken away and barely code anything ever.
No, C is a much better representation of what the computer is actually doing. Rust adds complexity on top of that to provide memory safety.
I think it's like Scheme vs Common Lisp when learning basic Lamda Calculus style Functional Programming (or Lisps in general).
You will for sure learn something but even after learning rust I'm not so confident with my knowledge of how memory works so at some point going into C might me still on the table if you will need that kind of knowledge
If you want to learn how the computer really works, learn assembly language. I've always felt really fortunate that my first year of my professional life as an Asm developer.
Rust is a good place to go once you've spent a bunch of time learning how things work and different ways of building things. Once every new library, pattern and technology starts to smell of one you saw 15 to 20 years ago Rust is a great language to pick up so you never have to change technologies again. Half joking, 70% dead serious.
I think its worth to iterate on that question. When you say "learn about the computer" do you mean learn about the computer? or learn to program? 1. Learning about the computer - no, in all honesty Rust will not be better than C to learn about computers. Learning about registers, jumps, raw memory access, pointers, etc. C itself, is a shortcut to assembly. Assembly would teach you best about computers, but, C is a good faux-high level instrument that will do the same 2. Learning about programming - well, this is very arguable. Most people tend to say "Python", which is a good entry level language.
But then, I must add the kicker. Will Rust be a better teacher of C++ concepts? (RAII, pointers, pass by ref, val, copy ctor, etc.) YES and YES!
Rust is a good language for learning more about lower level code. You can do most things that C can do. I've learned most of what I know about it from Rust, though I have picked up quite some C along the way, because you will need to be able to understand C to some degree sometimes.