Hi all,

I started learning rust a few months ago on my free time. I went through the most difficult already like borrow checker and I used the Learning Rust book from Jim Blandy as reference especially for its first chapters.

This is not my first time learning a language I already have experience with Python, Go, JS, C, Lua … but with Rust it feels different.

Everytime I learned a new lang there was always a milestone I crossed that made me feel comfortable using the language, that milestone was always some side project or program I needed anyway.

I am trying to do the same with Rust but the slowness of learning and looking up the docs coupled with the verbosity of the language is not very motivating. Don’t get me wrong, I really want to use Rust and learn it as it looks very elegant and clean, I already learned a lot more about lower level details of programming. The documentation is probably the most elaborate one I ever used for a programming language.

To keep me going I am practicing Rustlings while a procrastinate to work on the side project I chose as first project.

I am just curious how others passed that milestone with Rust.

  • Dessalines@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    2 years ago

    I think the best way to learn any programming language, is to think of a project you’re enthusiastic about, and try to build it using that language. Then only refer to resources like docs and guides, when you don’t know how to do a thing.

    This gives you the drive to finish something you’re excited about, and avoids the monotony of reading through documentation, a lot of which you won’t use.

    In real-language-learning, they call this the map / territory distinction. You could spend all day looking at an overhead map of a place, but you won’t really know it until you actually go to that place and experience it.

    In learning a musical instrument, its called the suzuki method: spend 99% of your time playing your instrument, and less time memorizing other things.

    • blob42@lemmy.mlOP
      link
      fedilink
      arrow-up
      5
      ·
      2 years ago

      That’s usually how I tend to learn new things as well. It’s just that progress feels so much slower with Rust at my current level. I could build the same thing with python or go in a fraction of that time and I need to justify to myself the extra time is for learning purposes.

      I started working recently on a big TUI project which I would love to do Rust but unfortunately most of the ecosystem is in Python (AI). I am using Textual and it’s such a breeze to make a TUI with it nothing comes close in Rust. What I achieved in a few weeks would take me months in rust.

      Also it’s that I have spent much more time reading than coding in retrospective to the previous languages I learned. I need more discipline just coding.

      Thanks for the advice.

  • whou@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    2 years ago

    Time. No, really, time and experience.

    I just used and read Rust enough until it clicked. I didn’t try to read pages and pages of documentation explaining Rust’s nuances, since that would be extremely boring and I wouldn’t learn that much anyway.

    Just keep using it on projects you like doing, try to use new concepts and learn how to use them in practice rather than focusing on theory, I guess.

    At least that was my experience.

    • blob42@lemmy.mlOP
      link
      fedilink
      arrow-up
      5
      ·
      2 years ago

      Yes right now it’s mostly a lack of time. With age and the constant flood of information it’s difficult to keep focus, especially with Rust. There such a huge amount of documentation it feels overwhelming.

  • sgtnasty@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    2 years ago

    Im in the same spot, but every time I take a look at other folks code I cant read it, they use some syntactic sugar I cant wrap my head around (yet).

  • orclev@lemmyrs.org
    link
    fedilink
    arrow-up
    4
    ·
    2 years ago

    Looking at your languages listed what strikes me is that none of them are statically typed (C arguably is, but C barely even has a type system by modern standards). I suspect that’s really what you’re struggling with. Added to that is that the Rust type system is heavily inspired by Haskell, and OCaml which are quite unlike most other languages.

    My primary language I get paid to work in is Java, but I also had extensive experience in Haskell prior to tackling Rust so my biggest hurdle was just altering the way I thought about variable scope and ownership.

    Something very important that fundamentally shifted how I think about programming that I learned while studying Haskell is to think about types and transformation. Types are representation of State, and a program is just a current state and a series of transformations applied to it. Advice that is often given in the Haskell community and which largely applies for Rust as well is to follow the types.

    • blob42@lemmy.mlOP
      link
      fedilink
      arrow-up
      3
      ·
      2 years ago

      You’re right I never worked on big projects with a strong- typed language. I did C extensively in my University years and since then it has mostly been dynamic languages.

      Haskell was my top priority language to learn but the pragmatic approach and performance of Rust was more appealing. I have a copy of Haskell Programming from First Principles ready on the shelf and I’m thinking Rust will give me a softer introduction to Haskell later.

      I also think I am too much impatient since I got used to pickup dynamic languages fast and do something useful with them.

      • orclev@lemmyrs.org
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 years ago

        Pretty much anything is going to be a softer introduction than Haskell, it’s like the black diamond level course of strong typing and functional programming. That said learning it fundamentally shifted the way I think about programming in what I consider to be a good way.

        With Haskell, when you finally manage to get your code to compile without error, it will usually work and be bug free. The reason for that is that its type system and the constraints of its functional language design have forced you to really sit down and think about exactly how your code is going to react to every possible situation. Rust is similar but provides a lot more lazy options for you. For instance if you really don’t care if your code crashes at some particular point you can just slap .unwrap() on something and call it a day. That’s basically telling the compiler “I either don’t expect this to error, or if it does error I just don’t care, kill the program and call it a day”. This is in contrast to Haskell that would have forced you to explicitly handle the various error conditions and explicitly opt into killing your program at that point. In either case though the fact that something has returned a Result wrapped value (or the Haskell equivalent of Either) has explicitly forced you to think about the fact that whatever returned that value might have produced an error instead and what you want to do in that situation.

        Having to actually think about errors and how to react to them is a massive win for writing correct and bug free programs. Other languages let you just assume that everything is going to work, but there are all these places that errors can occur but often don’t so you get in the habit of thinking as if errors can’t occur there, then when they do it’s always a shock. C is particularly bad about this because there’s all kind of places where C functions return garbage results and you only know they’re garbage if you check the global error variable, which you totally remembered to do right?

        I guess the point I’m trying to make in a roundabout fashion is that Rust somewhat, and Haskell definitely, force you to spend a lot longer writing your code in the first place because you need to put some thought into how the code will react to various situations in an imperfect world where various things just don’t work like they should, but the end result is code that lacks surprises. It’s always going to behave like you expected it would (assuming your understanding of whatever algorithm or business rule you’re implementing is correct) which ultimately saves a ton of time debugging. Having a compiler error that points you at a particular line of offending code with a (hopefully) clear explanation of why that particular line is problematic is so much simpler to deal with than a cryptic error message at runtime that could be coming from a barely even related part of the code due to a whole series of assumptions having failed in the face of one unhandled error state.

  • Yuu Yin
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 years ago

    Using as backend for a very important Web app (with possible IoT applications in the very future also) for me which I already conceptualized, have some prototypes, etc—this is what motivates me. I feel, for this project in specific, I shall first learn the offficial Book (which I am) and have a play with the recommended libraries and the take of Rust on Nails. I also have many other interesting projects in mind, and want to contribute to e.g. Lemmy (I have many Rust projects git cloned, including it).