The best approach to learning Rust

help
21

dylan.dpc https://users.rust-lang.org/u/dylan.dpc
December 3

donallen:

We are fortunate to be programming at a time when computing resources are
so plentiful (memory, processing power) that most of the time what we need
to optimize is software development time, because that’s where the costs are

That sounds like the PHP idealogy. Computer resources might be plentiful
but that doesn’t mean we can disregard performance.

I agree. But we also shouldn't prematurely optimize performance at the
expense of much greater development costs, because development is the time
and money sink these days. There's an awful lot of perfectly good software
out there written in interpreted languages. There's also a lot of software
out there written in C++ that shouldn't have been, because the performance
gain serves no useful purpose, but the projects took a hit in development
and future maintenance costs. And there are languages like Go that are
easier to learn and use than Rust that provide performance that's close
enough to Rust so that the difference doesn't matter in many (but not all)
cases.

22

It is true that computing power is much cheaper these days than it has been before. I would however complete this statement by advising against considering today's computing landscape through the 90s-era view that software efficiency does not matter anymore because hardware will get faster quicker than developers could ever optimize for it. For the developers that follow this philosophy, the truth is that computers have stopped getting any faster in the mid-2000s, and may even slightly slow down over time in the coming years.

The free lunch is over. CPU manufacturers have stopped increasing clock speed after hitting the thermal wall, and squeezed all the automatic instruction-level parallelism that they could get from naive sequential programs, all the while DRAM performance has been essentially stagnating as well, creating growing Von Neuman bottleneck issues as compute performance continues to grow. To make the most of modern computers is actually even more difficult than making old computers run fast ever was, because it requires leveraging multiple CPU cores, vectorization, and increasingly constrained memory hierarchies, not to even mention specialized hardware accelerators for which exception handling is impossible and even "normal" control flow like if/else is incredibly costly if done carelessly.

This is, in my view, one of the challenges that Rust was built to tackle. Not to squeeze more performance out of limited hardware, but to make the exploding complexity of current and upcoming hardware more tractable to software developers that need to make the most of it than any other language which I know of.

Now, who needs efficient software? A fair question, indeed. I would ask it to...

  • Data-center operators, who spend IIRC some 30% of their monthly bills in electrical power and cooling, consuming the production of one small power plant per site in order to operate a fleet of CPUs which are actually mostly idle most of the time because they are running unoptimized Java or PHP code.
  • Desktop users, who have seen every major productivity application they use get slower and more sluggish over time in spite of the underlying hardware supposedly getting exponentially faster. All this slow software also eventually leads to fortunes in wasted work hours.
  • Mobile device users, who wonder how come cellphones, which used to last a week on battery, now barely last two days with a battery that has 10x the energy density and get so unpleasantly hot during use (okay, the first one is also partially due to bigger displays, but that's a story for another day).

Not everyone has performance needs. Sometimes, a one-off quick Python is enough. But I would actually take the reverse stance from the "premature optimization is a waste of expensive manpower" view that you presented, and claim that too many developers also don't realize that they have performance requirements to meet when they do have some. And that's also a problem.

For those, we have Rust, trying to make efficient application programming less painful one let-binding at a time.

23

We're getting in a Rust vs other languages here. The main post was about what is the best way to learn Rust, not what is the best programming language. But I'll still put my two cents since we're already here:

Well, it depends. I don't see my Linux Kernel being written in something else than C. And dev. cost is relative. Let's take the C example: it's great for performance and maybe faster to write because you don't fight the borrow checker or lifetimes. But SEGFAULT is something you will see a lot. What I'm trying to say is that money will go into debugging. And C has been out for 45 years! Rust for only 7. Maybe in 10 years those concept will be widely used and understood, thus reducing costs. (Keep in mind that this is what I think)

Yes.

This is what I would call: bad choices.
For example, I always had in mind that Java is slow. Yet, all of Jetbrains' IDEs are in Java and now moving to Kotlin piece by piece. Seeing benchmarks for Java vs C++ there is a big difference, but they decided to stay on Java.

It does where it matters. Where safety and speed is really important. I don't want my web browser to be slow and have a lot of issues since almost my entire life is on the thing.

The borrow-checker is something that you get used to by programming in the language. I find myself fighting it very often, but when I'm done fighting it, it works. And lifetimes, as I said before, are a new concept. At least it has some kind of documentation and help online.

Just to leave here too, the community is a very disregarded aspect of a language. It seems like it doesn't matter to some, but for beginners, the Rust community is insanely good and I would consider it as a part of the language. If you have any issue of any complexity, leave it here, give it some hours maybe and you'll have a detailed answer proposing many options for you to use and in which situation.

EDIT: Forgot about generic documentation too, that, although it can be not well used, should be here for every crate and you won't have to go into the code, or read an unfinished or not updated wiki, etc.

24

HadrienG https://users.rust-lang.org/u/hadrieng
December 3

It is true that computing power is much cheaper these days than it has
been before. I would however complete this statement by advising against
considering today’s computing landscape through the 90s-era view that
software efficiency does not matter anymore because hardware will get
faster quicker than developers could ever optimize for it. For the
developers that follow this philosophy, the truth is that computers have
stopped getting any faster in the mid-2000s, and may even slightly slow
down over time in the coming years

The free lunch is over. CPU manufacturers have stopped increasing clock

speed after hitting the thermal wall, and squeezed all the automatic
instruction-level parallelism that they could get from naive sequential
programs, all the while DRAM performance has been essentially stagnating as
well, creating growing Von Neuman bottleneck issues as compute performance
continues to grow. To make the most of modern computers is actually even
more difficult than making old computers run fast ever was, because it
requires leveraging multiple CPU cores, vectorization, and increasingly
constrained memory hierarchies, not to even mention specialized hardware
accelerators for which exception handling is impossible and even “normal”
control flow like if/else is incredibly costly if done carelessly.

This is, in my view, the challenge that Rust was built to tackle. Not to
squeeze more performance out of limited hardware, but to make the exploding
complexity of current and upcoming hardware more tractable to software
developers that need to make the most of it than any other language which I
know of.

Perhaps your language experience needs broadening, then. Do you know
Haskell, from which Rust has borrowed (pun intended) heavily?

Now, who needs efficient software? A fair question, indeed. I would ask it
to…

  • Data-center operators, who spend 30% of their monthly bills in
    electrical power and cooling, consuming the production of one small power
    plant per site in order to operate a fleet of CPUs which are actually
    mostly idle most of the time because they are running unoptimized Java or
    PHP code.
  • Desktop users, who have seen every major productivity application
    they use get slower and more sluggish over time in spite of the underlying
    hardware supposedly getting exponentially faster. All this slow software
    also eventually leads to fortunes in wasted work hours.
  • Mobile device users, who wonder how come cellphones, which used to
    last a week on battery, now barely last two days with a battery that has
    10x the energy density and get so unpleasantly hot during use (okay, the
    first one is also partially due to bigger displays, but that’s a story for
    another day).

Not everyone has performance needs. Sometimes, a one-off quick Python is
enough. But I would actually take the reverse stance from the “premature
optimization is a waste of expensive manpower” view that you presented, and
claim that too many developers also don’t realize that they have
performance requirements to meet when they do have some. And that’s also a
problem.

I think you are overstating the need for ultimate-performance software. But
I do agree with you that future performance improvements will come from
multi-processing, not from Moore's Law.

For those, we have Rust, trying to make efficient application programming
less painful one let-binding at a time.

And we have the aforementioned Haskell and the amazing GHC compiler, which
makes it more difficult to accidentally write race conditions in
multi-threaded code, and is much easier to learn than Rust (I've done both
and have ported Haskell applications to Rust as an exercise) because it
doesn't impose the memory management burden on the programmer that Rust
does. Sometimes that burden is worthwhile, but when it's not, why pay that
price?

25

Luxed https://users.rust-lang.org/u/luxed
December 3

We’re getting in a Rust vs other languages here. The main post was about
what is the best way to learn Rust, not what is the best programming
language. But I’ll still put my two cents since we’re already here:

donallen:

But we also shouldn’t prematurely optimize performance at the
expense of much greater development costs

Well, it depends. I don’t see my Linux Kernel being written in something
else than C.

I wasn't discussing special situations such as kernel-writing. I was
talking about the tendency to view Rust as a general-purpose language for
application-writing. I think its use in many of those settings is not
justified, because its benefit is not needed (performance) and so it
doesn't make sense to pay the additional cost in development time vs. less
difficult languages.

And dev. cost is relative. Let’s take the C example: it’s great for
performance and maybe faster to write because you don’t fight the borrow
checker or lifetimes. But SEGFAULT is something you will see a lot. What
I’m trying to say is that money will go into debugging. And C has been out
for 45 years! Rust for only 7. Maybe in 10 years those concept will be
widely used and understood, thus reducing costs. (Keep in mind that this is
what I think)

I've written an awful lot of C over the years and debugging is just not the
problem you portray, at least in my experience. The tools are awfully good
-- gcc, clang, gdb, valgrind, etc. and the language is simple, easy to
understand, and extremely well documented. And you have to weigh the time
to find the cause of a segfault against the time required to make the Rust
compiler happy, which can be considerable, especially when you get into
obscure borrow-checker and/or lifetime errors.

I do agree with your point, though, that as time passes the Rust compiler
will get better and so will the documentation, resulting in less
head-scratching when using the language.

I would also argue that there are applications where dynamically typed
languages -- Scheme, Python, Ruby -- create more of a debugging headache
than C (or Rust or Haskell), because things that the compilers would catch
don't turn up until runtime and sometimes not exactly where the problem
occurs, depending on how much runtime checking is enabled. Unbound
variables, perhaps due to typos, are an example. So if you have an
application that requires a fair amount of runtime even when testing, the
edit-debug cycle can become quite long.

Look, the point of my initial comment was not to denigrate Rust. It's
simply a matter of choosing the best tool for the job at hand. I get the
feeling that some are so in love with this new technology that they want to
use it for nearly everything, ignoring more suitable tools in some cases.

donallen:

There’s an awful lot of perfectly good software
out there written in interpreted languages

Yes.

donallen:

There’s also a lot of software
out there written in C++ that shouldn’t have been, because the performance
gain serves no useful purpose, but the projects took a hit in development
and future maintenance costs.

This is what I would call: bad choices.
For example, I always had in mind that Java is slow. Yet, all of
Jetbrains’ IDEs are in Java and now moving to Kotlin piece by piece. Seeing
benchmarks for Java vs C++ there is a big difference, but they decided to
stay on Java.

donallen:

I don’t think the cost-benefit proposition justifies using Rust for most
userland applications.Said another way, most of those applications will
function just fine in an environment with memory managed by a garbage
collector

It does where it matters. Where safety and speed is really important. I
don’t want my web browser to be slow and have a lot of issues since almost
my entire life is on the thing.

But the choice isn't either write it in Rust or it will be slow and unsafe.
There are other languages that provide good performance and memory safety
and are easier to learn and write than Rust.

donallen:

But Go and Haskell offer the same static typing advantages, without the
tyranny of the borrow-checker and the still-not-adequately-explained
lifetime system.

The borrow-checker is something that you get used to by programming in the
language. I find myself fighting it very often, but when I’m done fighting
it, it works.

Sure, it works. But at what cost in time? You always have to weigh the cost
against the benefit. You could write the same application in assembly
language and eventually get it to work. Would it be worth it?

And lifetimes, as I said before, are a new concept. At least it has some
kind of documentation and help online.

This is an area where I think the documentation is simply not adequate. It
may be so because the lifetime rules are so complex. Just go through the
messages on this forum related to the lifetime issue and you will find a
lot of confused people.

Just to leave here too, the community is a very disregarded aspect of a
language. It seems like it doesn’t matter to some, but for beginners, the
Rust community is insanely good and I would consider it as a part of the
language. If you have any issue of any complexity, leave it here, give it
some hours maybe and you’ll have a detailed answer proposing many options
for you to use and in which situation.

I agree with that completely. Without that help, I would not have gotten
the ported applications I spoke of earlier working.

26

TL;DR I recommend reading the Rust book while completing Rust exercism and also running code in play.rust-lang.org. I have also started reading Programming Rust which has more in-depth content.

I wrote a post about learning Rust and Rust resources.

27

I agree 100% there, especially as there are already other topics around the question of how Rust compares to X or whether Rust's value proposition is worth it or not.

To all of those who want to pursue this discussion, let's shift it to one of these topics, or create a new one if none of the existing ones fit. This is not the place for a programming language holy war :slight_smile:

EDIT: Here's a topic proposal.

29

How was your experience translating C# components to Rust?
What have you learned in the process?
Do you have any rules of thumb?

30

Learning rust is one thing, learning systems programming is another. You may learn system's programming from university, industry and mostly c/c++ based content.

Learn rust is mostly like a spiritual journey specially if you skip the documentation and unable to internalize the rules. Because the concepts brought by rust are not taught or even discussed at most schools.

Regards

31

The same thing follows for other languages a well. One cannot expect everything to be taught at school. Rust does have a steep learning curve compared to other languages but I think that is good for the language.

32

(late reply - was out staging the gear, so was not online much)

Most of part of the code that I had ported was fairly straightforward. I picked Rust to begin with because of Diesel - I wanted to avoid doing too much SQL, while at the same time being as much database-agnostic as I could have. Having small components with rather simple functionality helped a lot to achieve very quick gratification in porting and meant I could always use the results, thus making it less stressful - worst case I would have ended up with a mix of C# and Rust components.

Specifically making an encapsulation for SSH allowed to get a lot of experience with borrow checker and I think by now I have a reasonable feel for it.

In the process of rewrite, I had a chance to rewrite some of the components in a much more efficient way, ironically due to missing functionality - i.e. for the pinger I had to dig into using raw sockets and doing multithreaded programming, so I would say it is definitely good to have freedom to change how the code works rather than being coerced into a 1:1 port.

The frontend is in C# (There is a lot to rewrite) but all the backend components are now Rust, and I am very satisfied with the results, and looking forward to battle-testing the code :slight_smile:

33

Feels great the community is so active. I'd like to share my thoughts. You can learn Rust from curated resources in order to save your time.

Ex - https://hackr.io/tutorials/learn-rust

34

I'm reading the O'Reilly Book. My goal is to learn rust over the spring where I can develop an application over the summer to pitch to my software department at work weighing the advantages/disadvantages of Rust compared to C++. I drive to work early every morning Mon-Fri and spend on average 1 to 1.5 hours/day learning Rust. All my work is version controlled and kept on GitHub. On the weekends I spend on average 10 to 15 hours. In these blocks of time...

  • I read through my O'Reilly book highlighting specifics to come back to or take notes on
  • I compare my notes to other online content arriving to a central idea/understanding
  • I sign in to the IRC channel daily and clear up any major confusion
  • For every example in the book I write five to ten more examples
  • I visit Rust by Example and exlicitly type them out

Over the spring I've been keeping a daily metrics (Excel sheet) of various stuff like...

  • Lines of code I wrote for the day
  • Amount of time I've spent each day learning Rust
  • My ever changing interest/skill set in the semantics/theory
  • Number of posts I've read and have created
  • Number of IRC chat sessions
  • What chapter I'm on in my book

These metrics don't really help me learn the language but they provide some data points I feel are helpful in staying persistent and actively engaged when tackling a new language.

  • Visualization (graphs) of my improvement over time to serve as self motivation in overcoming the initial learning curve
  • My community involvement showing what resources I'm leveraging the most or least

Example
image
image

I've tried to stay away from the crate system and just focus on the std libs in order to grasp some of the most fundamental concepts first (Ownership, Borrows, Lifetimes, Moves). I've also sparked some interest in my surrounding area to get any Rust meetups back up and going again. This may seem like overkill but for a young single guy like myself with OCD it's just right :wink:

Most importantly, do not let others destroy your morale or interest in learning Rust because they had an awful experience. I think it's important to hear out others opinions but more so in drawing your own conclusions through experiencing the language yourself.

Cheers~S

35

@shanedora it's really cool to see how you've approached learning the language and I'm impressed with how you committed you are!

Something to think about is that learning the language and standard library is only half the story. To produce any useful application you are going to need to use external libraries, and in turn interacting with the ecosystem gives you a chance to see how people have designed things and figure out what idionatic Rust looks like.

Additionally, libraries like serde, diesel, and rocket really help open your eyes to the different things which can be done in Rust and how you can take advantage of the type system to make your program correct by design.

I'm not saying your current approach is wrong (after all, it sounds like it's working really well for you!), just that there's a whole world outside std and it's okay to leverage the wealth of knowledge that is crates.io :slight_smile:

36

@Michael-F-Bryan
Thank you for that feedback. I definitely will consider looking into crates.io more moving forward. As a newb it's sometimes confusing which crates I should be using since on occasion I'll find more than one to solve the same problem.