Ask HN: Do you get impatient when learning new things?

Even when they ostensibly do that, "The main concept that makes Rust unique is called ‘ownership’. Consider this small example:" could be better-stated as a difference between Rust and (list the languages that don't have it.)

Tutorial authors and tool authors also waste INCREDIBLE amounts of time through dishonesty. For example, Functional Programming like Haskell is largely defined by the hoops you have to jump through syntactically and in program structure due to what it avoids. But a Haskell tutorial will NEVER make it obvious within the first two minutes that you are doing something fundamental different from C, Java, Python, C#, Perl, whatever - and that it has a whole concept, monads, just to get around this artificially imposed self-limitation.

They're just dishonest, waste incredible gobs of time, and don't get to the point.

When was the last time you picked up a language book that made it completely obvious in the first minute what it was and wasn't suited for, how many hours you would need to practice it before you made progress, and what the absolute bare minimum number of minutes you would need to invest before you could start doing anything in it was? It's a guessing game. "Wow, this only took me two minutes!" (json). "Wow this took me two weeks and I still can't do shit!" (haskell)

I Googled "I tried learning haskell for" to report on what I found. There happens to be one hit on that exact syntax. Guess how long the guy "tried" learning haskell for? A few months.

The practice is important. I plow through books too but you need a project to become proficient. I bought a laptop and started working on some small scala projects on my laptop and reading books. That was enough to let me submit some janky scala for an interview and land a job as a scala engineer.

Some material is harder to learn, some of it is easy. I think it's better to defer reading books for a bit and get some familiarity with the basics so you have a point of reference while reading. The other day I was assigned a pretty big feature with a piece of the domain I wasn't too familiar with. I spent a few days writing a parser to get closer to the spec before starting to work on design docs etc. Having the familiarity then allows me to make sense of the research and existing design documentation so I think having a point of reference is a really important part of the reading/learning. If it's too far away from my current experience, I can't draw new pathways so it just falls out of my head. If I have that basic seed, I can grow some new pathways and expand my position with reading etc.

Ultimately, I think the best way to learn is to actually present the information again to other people. This is the culmination of practice and research together. To write a detailed article on a topic, you'll have to both write the code and also do a lot of reading. Any gaps in your knowledge you'll identify while you're writing and then it's a simple bit of google-fu to get a really solid level of understanding on a topic as you fill out your article.

Re-implementing things is also a terrific way to expand your knowledge. If you read a pattern book, you'll have some high level understanding of how the patterns fit together. Once you apply the pattern once, though, you'll never forget it and you'll see how it works at a very different level. So couple that with writing an article, etc, and it's a super effective approach to learning.

Somewhat expensive, but worth it, I've found.

Why?

Well, logically, if you've started learning something I'm guessing its because you want to do something with it? So have some patience.