Ask HN: How do you learn a programming language (e.g. Rust) from a book?

Depends on the book, but in general type in every programming snippet and do most (not necessarily all) of the exercises they offer (if they have exercises, if not make your own by changing the provided code to do something else).

I have a habit of using Org mode and creating an outline of the book. Then I type in the code as I go along and use org-tangle to kick out source code that can be run. Sometimes I go ahead and set up monitors (fswatch) to see if files or directories change and run `make` or whatever is appropriate in a separate tmux pane. Stupid simple example, if it were a lisp book and one of the first programs was hello world:

  * Chapter 1
    Functions are declared with `defun`. Everything is in parentheses. Function being
    called first, then the parameters separated by spaces, no commas. "Hello world"
    looks like:

    #+BEGIN_SRC lisp :tangle src/hello.lisp
    (defun hello-world ()
      (format t "Hello, world!~%"))
    (hello-world)
    #+END_SRC

`C-c C-v C-t` would spit out that file so I can run it somehow, or `C-c C-c` would execute it (since emacs and common lisp work very well together).

Ultimately, the key to learning programming is to program. You can learn a lot about a language just by reading a book, but it won't be internalized until you use it.

Read book, type out the code from the book, check that it works. Then I try tweaking the code, seeing if it does what I expect. If it does not, I try to figure out why. Once I've finished a chapter or so, I see if I can do an exercise using the techniques from memory.

I would suggest reading through and practicing some of the snippets as you go along (however, I would _not_ suggest doing the little projects, often they can get you sidetracked). By snippets I mean things like `foo.chars().iter()` and such to understand exactly what's going on underneath the hood when you use (for example) a `.chars()` or a `.iter()`.

But the book will only go so far. To take things further (especially with Rust), I suggest "reading code". There's plenty of it on Github. And I would definitely add that Rust devs in particular are usually better than most at commenting code (which helps).

I will add... these books can often be useful as a reference more so than a strict learning guide. Most technical books seem to be more useful in that way.

I would suggest only using books as a guideline, nothing beats being practical and trial/error.

practice. write the code exmaples, change something, break things... and then learn to fix these.

Funny – I wanted to write a longer blog post about this topic (learning/growing with books) for some time now. The following is the abridged guide of how this works for me subjectively. Perhaps it gives you some ideas to develop your own style. Fair warning: I don’t know Rust.

First of all: You do not learn a programming language from a book, nonetheless a book can be a great way to support your learning.

For me getting proficient in a programming language is a combination of learning the language, the tools, the platform, API and having some structured understanding of the language.

Parallel to finding the right books you can already download/install the tooling for your language which translates to compilers, software development kits, package managers, a decent text editor or integrated development environment. Once the tooling is installed you will find plenty of examples on how to write a ‘hello world’ program.

If you have any chance to get more than one book about your topic of interest (cash to buy, access to a library, …) than you should try to get your hands on 2-3 books.

How to find your 2-3 books?

Do your research first: - Which books have good (non-fake) reviews? - Which books come regularly up in discussions? - If you have any chance, look at the table of contents, read a few pages and see if you feel comfortable with the authors writing style and if book covers topics which seem reasonable to you. - Check that the book as a decent index (bonus points for a good glossary).

Once you have your books, you do not read them front to back word by word.

First you get an overview of the book. For this you flip through the book and just read the first and last paragraphs of each chapter, read all headings, look at each picture and read all the source code examples you see. The point is to get an overview, idea of the idioms and concepts, not to understand each and every detail. Have a good look at the table of contents and at the index/glossary.

For a programming language you should now have general idea about the syntax, data types, control structures, way to organize code (methods, functions, classes, traits, closures, module system) and special features of the language (borrow checker, macro system).

Depending on your previous knowledge/interest you can now read about the topics you have questions about in the book(s). Again, the point is not to read every word from start to end but to find the information that answer your questions in an economic way.

Depending on your previous experience: If this is the first programming language you every learn, type the examples from the book yourself. Read the compiler/interpreter messages if something does not work properly and learn to correlate what the compiler/interpreter prompts to the errors you made.

If this is not the first programming language, find some easy tasks or challenges to program and start coding small programs until you become comfortable enough to tackle bigger projects.

Follow the classic cycle: 1. Make it work 2. Make it idiomatic for your target language 3. Make it fast

Bonus tip: Get into the habit to learn the more coarse grained structural elements of the language as fast as possible.

(Sorry for any typos and my grammar – English is not my first language.)