Heck, so my secret project of slowly replacing every Perl script in the kernel with C might even get approved...
https://www.youtube.com/watch?v=yA_wUiNuhSc
C isn't a good software engineering language but it might be better than Perl. Or in this context, maybe not.
User-space part only. Kernel is C++.
I don't think that Rust has the same issue: it has a clear (albeit potentially complex) vision of what it is trying to do, which is distinct from C and more consistent than C++.
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.
It is _the_ language where most of the Functional Programming in the industry takes place (that's not to say that Haskell, F#, OCaml or Clojure are bad, they just aren't as widely used). And that also means that there are lot of open job positions available.
I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern-style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).
https://typelevel.org/cats-effect/
The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.
The tooling available is from good to great and Scala is big enough that there are good libraries for typical (if not vast majority of stuff) and Java libs as a reliable fallback.
Jokes aside, even Scala proper sees itself as an experimental testing ground more than a complete idea realized. That's why dotty became Scala 3, with a huge amount of backtracking.
It pushed the state of the art across the JVM landscape, but I think it's lost its purpose with Java, Kotlin, and Clojure around.
That's just something that Java, Kotlin, nor Clojure don't offer. And there is significant demand for Scala (and its pupose) in the industy (it just not may be as huge as Java or other more mainstream languages).
As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
I feel qualified to say such things as I've worked on a billion-line perl codebase before.
> As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
Perl gets quite unfairly picked on here, to the point where it's basically a meme. It's not like, just to pick a somewhat popular language, Ruby doesn't provide plenty of ways to write completely unreadable code that can only be understand by running it through irb, if even then.
I agree that there is plenty of bad Perl code out there, but there's plenty of bad code in any language that achieves general popularity for a time. Disciplined use can produce perfectly clear and readable code and the module system is perfectly adequate for separation of concerns.
The language does give you an absurd amount of rope to hang yourself with though. If I were managing a large Perl project today I'd have an extremely restrictive style guide and would enforce as much of it as possible via pre-commit hooks.
> I feel qualified to say such things as I've worked on a billion-line perl codebase before.
For a language that permits such densely expressive code, that's appalling. I'm so sorry.
This was surprisingly doable? Marshaling/unmarshaling Perl objects into Python ones isn’t difficult these days, and you can run Perl code via FFI so the transition can be piecemeal.
I have no opinions on Perl as a language (some constructs / patterns felt a bit hard to think about, but I’m far from an expert), but ultimately it’s a high level language and has been left behind tooling wise to another high level language, so it’s time to move. For us, one motivator was that having a large legacy Perl codebase (even one running well for years) hurt recruiting.
I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.
Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it.
This isn’t an indictment of Java. Just resume driven design.
Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff.
To be fair if I walked away from Rust for a year I'd probably be similarly lost.
The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way.
It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.
What, how?
Thats bigger than windows linux llvm chromium and 5 other compilers combined according to google
Linux is a pretty small codebase compared to most proprietary codebases in large companies to be fair though.
The commands supported by `sh` are... let's keep it at "fossilized from somewhere in the 80s", and so the only alternative was perl which has a ... history of being not exactly user-friendly to code for.
[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
1 - http://archive.debian.org/debian-archive/debian/dists/buzz/m...
fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed)
fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells.
fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked.
† If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.
I was referring to the `Box<dyn Trait>` one, as I'm at least 90% sure `Box<X>` passes a owned, dynamically-allocated X by reference (ie, Box<X> is a pointer to X).
If the function only wanted a reference to it, that would be &Box<dyn Bird> and then I wouldn't give up ownership by passing it to the function. But that's also a very strange thing to ask for, since we can instead pass a reference to a Bird, no need to Box it.
No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference").
> then my call moves the Box<Goose> into the function, I don't still have that Goose
Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
> are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
Whether I ask for a Goose or a Box<Goose>, it's mine now. The caller no longer has it, it's not just that they shouldn't use it, they can't, the compiler won't let them. Since it's mine, it is now my responsibility as owner either clean up, give it to somebody else or explicitly leak() it.
Rust doesn't promise how exactly this is implemented, and it is likely to be different for an object of 4 bytes than for an object of 400 bytes.
It is true, though, that there are differences. With the generic, you can refer to the type again later, whereas the type is anonymous with `impl Trait`. And `dyn Trait` gives you dynamic dispatch. But in my experience there are usually some differences between the multiple ways to do something in Perk as well.
Or should I learn C/C++ first and then learn Rust?
I've just done projects in Python,JS & Java so far.
If you want just to "play" and do some tiny projects as low level as reasonable - go for learning C first. You'll learn a lot - and then when you learn rust, the reasons why things are done that way will make a lot of sense. Also, so many low level utils are written in C - having a basic knowledge of it is really useful. But don't try to build a big complex thing in it unless you have a really good reason to (or you fall in love with C. Some people do!)
If you want to actually build something big and complex and for real world use - probably go for Rust.
If you want to build a big production system using an already established tech that's based on C++, learn that. (Eg. one of the C++ based game engines, or a C++ GUI framework, or whatever).
C++ has everything C has plus many layers of complexity deposited over it that can make you more productive but also obscure your relationship with the machine. If you're going to go on to Rust I wouldn't bother with C++ at all right now.
If you're coming from Java, the most difficult thing you'll need to learn is memory management, as all of those languages do that for you. The other difficult thing is threading, but that's 1) unnecessary and 2) not actually that different from Java.
Rust forces you (unsafe aside) to do memory management in one specific way, and verifies it in the compiler. C and C++ let you do whatever you want, though C++ encourages (without requiring) a Rust-like approach.
I think Rust will probably be better if you want to have a constrained environment that tries to prevent mistakes. C will be better if you want to explore on your own, learn from the mistakes, and thus understand why Rust wants you to do particular things. C++ frankly doesn't have a whole lot to recommend it unless you are working with a C++ codebase, already know C, or really need one of its features.
I'm coming from a largely Java background (though I program a lot of C and assembly as a hobby), and this statement is very true. Getting used to the borrow checker and reference lifetimes has been the largest obstacle so far. But once that is understood, the rest of Rust is basically learning the idioms and ecosystem.
I will likely change how I write C based on my experience with Rust's memory ownership model..
Moving from high-level languages to Rust is going to be a nice punch in the face :)
Some people suggest to learn C/C++ but that ultimately depends on the resources available. If one has infinite time, certainly it's ideal, but with limited time, I think learning Rust will already be very demanding.
My suggestion: find some small projects you find interesting. Follow the usual Rust learning path (reference book first, then find other books), and apply it to the projects you've chosen; after an year or so, ask the question again.
Other small suggestion: don't start from book that pretend to teach Rust by learning another topic, because the amount of Rust that can be taught in 100 pages is useless (a lot of books pretend to do so). On the other hand, there are way more books to find fun projects/topics than there were an year ago.
IMHO, if your end-goal is Rust, learn Rust directly.
The angle I am coming from: I've been doing C++ for 20 years and Rust for over a year.
Learning C/C++ can provide great value on its own, through gaining knowledge of how lower-level programming primitives work, but many of your C/C++ skills won't be subsequently applicable to Rust, except perhaps for core concepts such as a stack, a heap, owning memory, a `struct`, etc. This is caused by the fact that Rust takes many programming abstractions much _farther_ than C and in a substantially _different_ direction than C++. For example: where C uses manually managed pointers, Rust uses compile-time checked ownership and borrowing; where C++ uses inheritance, Rust uses generics and composition; where C uses void pointers ;) and C++ uses pure virtual functions, Rust uses traits and `where` clauses; where C and C++ use... a programmer's eyeballs to guarantee multi-threaded correctness ;), Rust uses compile-time "marker" traits; and so on.
Don't get me wrong: C and C++ are extremely able, powerhouse languages worth your time in their own respect, it is just that most of the C/C++ -specific knowledge you invest your time to learn beforehand won't be directly applicable to Rust later on, because Rust just does things in a significantly different way than C/C++.
Oh, don't forget to RTFM - Rust is easy to learn by reading (in order to understand its unique concepts), but Rust is hard to learn by experimentation alone (trying 100 different syntax variations to see what compiles).
You don't need to 100% the language, a few months experience will be be handy for the rest of your computing career. It'll be a perfectly reasonable stepping stone for reading C++ without really needing to learn all the details to write it.
As much as any language can be: C is still the lingua franca, a relative common denominator. As you explore different parts of the computing environment around you, you'll run into it constantly.
Learning about python? C. Digging into how your program talks to the OS? glibc and the man pages and most examples will be C oriented. Any documentation ever explains how something is laid out in memory? It'll be explained in C structs. How function calls work? The assembly will be explained in terms of C code and C's calling convention. Any language's FFI? C. Digging into the JVM, browsers, Javascript? It's C++ but you'll know enough to eyeball the code.
This is mostly about all the things you'll want to be able to read about well. Anything you'll want to know has been done in C or C++ — Nothing big exists that you'll want to explore is mostly written in Rust or Zig yet. And there are still things that can't reasonably be yet either (oversimplification).
There's no real problem starting with Rust, especially if you have some experience with other languages. The biggest difference is going to be getting used to dealing explicitly with memory, since all the languages you listed have a garbage collector; but this is true of all of C, C++ and, Rust. Be kind to yourself -- don't expect it all to click instantly.
Rust is it's own thing; I personally really like it but going from C to Rust is harder than just going to Rust as you have to "unlearn" C paradigms.
You'll probably be "better" if you go C first, but it will take a lot of time and energy.
In the end its completely up to you.
It will teach you how a PDP-11 thinks, at best. The cache hierarchy and speculative execution are completely hidden at the level of C, to start with.
You want to learn how computers think, pick up an assembly language. (Any one will do.) You want to build portable low-level software, learn Rust, Zig, C, or C++ (in my personal order of preference).
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
The performance gains of fine-tuned code is typically two orders of magnitude higher
A quick glance at Intel's Software Developer's Manuals [0] falsifies this:
>> TLB and Cacheability control: CLFLUSH, CLFLUSHOPT, CLWB, INVD, WBINVD, INVLPG, INVPCID, and memory instructions with a non-temporal hint (V/MOVNTDQA, V/MOVNTDQ, V/MOVNTI, V/MOVNTPD, V/MOVNTPS, V/MOVNTQ, V/MASKMOVQ, and V/MASKMOVDQU).
> [..] speculative execution are completely hidden at the level of assembly too
Section 18.1.13 specifically mentions side-channels for speculative execution, and there are more than 100 other matches for "speculative" across the document (some of which also refer to load barriers).
So no, these things are not completely hidden at the assembly level, and at least in the case of the (or one of the?) most popular consumer CPU architecture in the world, they are actively documented in the primary reference for an assembly programmer.
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
And error recovery (that is fucking crazy on x86), and wide instructions, and I/O, and stack management, and... I am not sure C is even a good approximation for the PDP-11.
For which you'd need to be familiar with a low-level language like C.
It's a good way of helping people with no programming knowledge get past the stage of "what are those magic colourful words you type that somehow make the computer do things?".
https://tobiasvl.github.io/blog/write-a-chip-8-emulator/
I haven't made a Gameboy emulator, just learned the assembly so I could modify some roms.
You can check out my blog post[1] if you're interested how I went about it (there are a couple resources at the bottom I used to build it, including the one that HideousKojima recommended).
As for language, in hindsight, C was fine. CHIP-8 is so basic that you don't really need to worry about performance or to implement a JIT compiler unless you want to learn how to do those things specifically. Just pick any one out of the three (assembly is a bit of a weird choice though, why not write a CHIP-8 emulator and then a brand new program to run on that emulator in CHIP-8 assembly if you want to learn assembly?)
As for Gameboy, it would have more instructions, a different graphics system, sound etc. and overall be more complicated than CHIP-8. Try it out if you either feel a bit more adventurous or have implemented CHIP-8.
[0](https://sr.ht/~gotlou/chip8-emulator) [1](https://gotlou.srht.site/chip8-emulator.html)
Check this post out - Should you learn C to "learn how the computer works"? (https://steveklabnik.com/writing/should-you-learn-c-to-learn...). Spoiler alert - no.
I think summarizing that article as "no" really undercuts how diplomatic and reasonable Steve Klabnik is in it.
But is it necessary to understand now a computer works? No.
You can also check out "C is how the computer works" is a dangerous mindset for C programmers (https://steveklabnik.com/writing/c-is-how-the-computer-works...)
If, however, we're talking about the kernel then perhaps we should listen to what Torvalds says about this topic.
"People who designed C, designed it at a time where the language had to be geared towards the output, so when I read C I can think about the Assembly that it will create":
http://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s
Consider that he said this in a time with C++, even if Rust was in its infancy: it is not as tied to the assembly it produces. Not by a long shot.
The issue with Assembly directly is that it's absurdly non-portable, too low level and too unstructured to do anything reasonable with it.
There's a reason that Linux is written in C and not ASM Directly.
Even interpreting this as charitably as possible--that you don't mean literally learning assembly but rather learning everything besides specific assembly syntax that you would have picked up from learning assembly--this claim doesn't hold water.
For starters, C isn't that much closer to hardware than, say, Java. The main differences you have with C are that a) C has a pointers-are-almost-integers model [1] and b) C has a more limited runtime than other languages. C is still a fundamentally based on an abstract machine semantics model, and that abstract machine doesn't have a close bearing on modern hardware.
In particular, C does not distinguish between registers and memory, and if I had to pick the single most salient feature of modern hardware you need to understand well to be able to say you understand how computers work, it's the register/memory distinction. If you think processors are mostly like they were in the 1970s--when you could say "add 1 to this memory location"--then C's shrugging off the register/memory distinction makes sense, but this is a situation that hasn't been true for several decades.
Another failure of C is that it's far less expressive than assembly. There are features in other languages that are impossible to express in C. How do you write a function with multiple entry points, as you can in Fortran? Or a coroutine, as you can in Algol? Or nested functions, as in Pascal? Or try-catch, as in C++? Or functions with multiple return values, as in Matlab? Indeed, how do you write something like JMP *reg in C, a useful primitive for state machines?
No, C does not come close to being a good description of modern processors, where "modern" means "anything that came out since I was born."
[1] Not going to open up the can of worms that is pointer provenance.
Just nitpicking, but doesn't C have the register keyword? (I know it does nothing at all nowadays, but AFAIK it did make a slight difference back in the dark ages.)
Your C compiler might conclude - even if it doesn't decide to put the variable in a register - that since the variable notionally doesn't have an address some optimisations are available which it can't otherwise be sure are safe.
[1] Okay, the official semantics of "volatile" strictly speaking are completely orthogonal to memory, but the practical effect that everyone agrees on (don't optimize this memory access) is inherently oriented towards memory, and the fact that the semantics are so vague about what it actually does is partially a reflection of the fact the semantics themselves don't distinguish between register and memory.
I don't believe this at all. You won't learn how to deal with limited numbers of registers. You won't learn about method prologues and epilogues. You won't learn about oodles of stuff.
Those things takes like an hour to learn, translating C to assembly is trivial, it takes time and will be verbose but it isn't hard at all. So even though you don't learn all the details you still learn all the higher level stuff related to assembly programming when you program in C.
This isn't true for other languages, translating arbitrary C++ or Java or Javascript to assembly is really hard, so they don't teach you to think like an assembly programmer.
I mean; you will likely end up stepping through debuggers where you will see registers being used. At least if you learned C like I learned C.
Similarly for Prologue and Epilogue.
"why does a function call have a cost" is a common question and it's solved forever after an hour googling.
If you're willing to accept, at face value, that certain easy tasks are convoluted for Good Reasons, you can go straight to Rust. If you want figure out why for yourself, start with C.
I always want to learn bottom up, and personally recommend starting with C.
A)
Rust gives you many great abstractions that you will want to use, even if you skip the standard library. This gets in the way of really learning to work with and understanding pointers and low level mechanisms. You can certainly do that in Rust, but you have to force yourself to ignore most oft the language.
B)
You will have to read and interact with C code eventually, and be it just calling out to libraries or wrapping libraries in Rust interfaces.
A solid understanding of C is critical to do that correctly.
There's also a lot of safety tooling that you rarely need with Rust, but should be comfortable with. (Like valgrind)
After learning Rust you will hate working with C (well, I do...), so it's better to do it early.
You don't want to get fooled into thinking C's abstract machine is what your actual machine is like, because it really, really isn't. A bunch of the stuff C is deliberately vague about because it wasn't portable in the 1970s is very concrete and important to understand about on a real computer. Rust's Wrapping<u8> and Saturating<i16> have behaviour that you could buy with a real CPU (indeed your actual CPU almost certainly can do Wrapping<u8> with no extra work) but C doesn't promise anything like this and names types things like "short int" which could be anything.
On the other hand, some things C makes seem obviously concretely real, are just being simulated convincingly and that's not necessarily how your CPU works at all. Nobody really promised "pointers" are just integers you can go around doing arithmetic with for example.
If your endpoint is Rust anyway, just start there. You can always learn C (and/or C++) later.
I don't think it matters (much) which language you start with. Any one of the suggested languages (or commonly suggested languages in general) will be fine. I think this applies in general too, at any levels of skill/experience, but probably matters more for someone with less experience.
Between C and Rust, Rust has better tooling and an easy to use library ecosystem. C is a smaller and easier to grasp language.
I would start with Rust if you want to write a real world project. And probably start with Rust if you just want to write some leetcode algorithms as well (but C is fine here too)
People that learn C or C++ first often end up fighting the Rust compiler a bit until they adjust their mindset.
Rust's borrowing and ownership semantics are not bizarre and novel solutions to things that aren't problems in other languages. Rust's borrowing and ownership semantics are a compiler-level reification of problems that exist in all languages, and especially multithreaded languages. This 100% includes C. You may not adopt Rust's exact solutions in all cases, but if your are programming at a system's level at all and you're not thinking about the problems that Rust exposes directly, you're in trouble and you don't even know it. Using Rust is a great way to work in an environment where the compiler is forcing you to learn how that all works, and will train you good and hard about how to think about issues of ownership and what code is allowed to touch what.
I primarily work in Go, a garbage collected language, and I heavily use the concurrency features. That doesn't mean I don't have to think about ownership because the language lacks any support for it, or that I don't have to worry about who is responsible for deallocating things because I work in a GC'd language. It means I have to think about those things, but I lack support from the language. My personal career experience means this is not a terrible tradeoff; as a result of all my time in Erlang and Haskell it is no big deal for me to operate concurrently in a manner that I know will work, because while they are different than Rust, they were also harsh taskmasters in terms of only allowing me to do certain things that work. Other tradeoffs make Go worth it for me despite this lack of language support. But the lack of support doesn't make the problems go away. It just makes it so you can't see them immediately at compile time.
I would expect that someone who learned Rust for a year, then learned C for a year, would probably produce better C code than someone who learned C for two years. Eventually, the C programmer will, by hook and by crook, learn all the things that Rust would have taught you, but you'll be learning it in an enviromnent that lets you make mistakes, then build on them for months before they finally blow up in your face. It is far easier to learn about what mistakes you are making in an environment where it instantly tells you that you made a mistake.
(Also, I should clarify something: By "C" here, I mean programming in raw C, without any particular additional support. For the sort of purposes I'm talking about here, I actually consider "C with a strong static analysis tool like Coverity" a separate language. If you use such a tool pervasively and work in a code base that has either been cleaned to its satisfaction or started from scratch under the analyzer's support, you can also learn in a fast-feedback environment what not to do. It won't be the exact same lessons as Rust, but it'll be good enough; there are many paths to enlightenment in this case, just as I trod a completely different one as mentioned above. The important point is to use one of these, or perhaps another, and not simply stand in front of the monster that is Raw C with nothing but your own wits to guide you. I don't care how smart you are. It'll eat you alive. You do not want to be responsible for trying to tame the thing yourself under your own power and nothing else.)
The story I’m seeing at most companies is that they have a few old guys taking care of maintaining their legacy C/C++ codebase, and there’s a diverse bunch of young folks shipping new components in Rust.
When the time comes you can start with Rust
Glowing endorsement from Torvalds right there. I'm really curious about how this will work out, Rust is my favourite programming language by a fair margin and seeing it being used more and more in places where C or C++ has traditionally dominated is very exciting. The future is looking bright (for those of us who like Rust).