3 ms·

I am going through the rust by example thing every weekend and also trying to write some Rust code on my own and I found the 'too much symbols'/unreadable code

I am going through the rust by example thing every weekend and also trying to write some Rust code on my own and I found the 'too much symbols'/unreadable code and just the general complexity of the language very off putting. If I have to write low level code, I might just stick with C or C++ - the devils I know rather than trying to tame a new incarnation of the devil that is Rust. The complexity and learning curve costs of Rust far outweigh the benefits at this point. Edit: If I sounded like I am giving up on Rust above, that's not yet the case. I am currently enjoying challenging myself to learn something complex and to that effect, Rust is holding my interest.

steveklabnik 9y ago
Did you try the book? Just curious.
- blinkingled 9y ago
  I started there, 1st edition IIRC - went up to refs and borrowing and then thought maybe the by example approach is something I would like better - and I do find the example approach keeps my interest better. Although I suppose I should go look at the 2nd ed draft when I need to look into more theory - reading the refs and borrowing section from 2nd ed right now :)
  - steveklabnik 9y ago
    Ah yeah, the second edition is just straight-up better, and does contain examples. For example, ownership, references, and borrowing are theory-based in 1st edition, but are with String/&str in the second. That said, both are great resources. For some people, the book doesn't work for them but RBE does, and for others, RBE doesn't but the book does.
    - pjmlp 9y ago
      I went through the books, yet it was a big challenge porting an old Gtkmm toy application to Gtk-rs, because of lifetimes on callbacks. Initially I was referring to the fields on the struct, but ended up passing them around as parameters. You have a referrence to this kind of problem on the NLL proposal. But unless I missed it, the books don't talk much about this.
      - steveklabnik 9y ago
        The book does, but it basically says "Don't do that", whereas since you're binding to a library that does that, you don't have a ton of choices. I haven't really used Gtk-rs enough to say more than that, really.
        pjmlp 9y ago
        Basically the idea of having structs implementing widgets, which need to respond to UI events and handle their state, stored as struct fields. On modern C++ you can easily use this approach with std::enable_shared_from_this.

steveklabnik 9y ago

Did you try the book? Just curious.

blinkingled 9y ago
I started there, 1st edition IIRC - went up to refs and borrowing and then thought maybe the by example approach is something I would like better - and I do find the example approach keeps my interest better. Although I suppose I should go look at the 2nd ed draft when I need to look into more theory - reading the refs and borrowing section from 2nd ed right now :)
- steveklabnik 9y ago
  Ah yeah, the second edition is just straight-up better, and does contain examples. For example, ownership, references, and borrowing are theory-based in 1st edition, but are with String/&str in the second. That said, both are great resources. For some people, the book doesn't work for them but RBE does, and for others, RBE doesn't but the book does.
  - pjmlp 9y ago
    I went through the books, yet it was a big challenge porting an old Gtkmm toy application to Gtk-rs, because of lifetimes on callbacks. Initially I was referring to the fields on the struct, but ended up passing them around as parameters. You have a referrence to this kind of problem on the NLL proposal. But unless I missed it, the books don't talk much about this.
    - steveklabnik 9y ago
      The book does, but it basically says "Don't do that", whereas since you're binding to a library that does that, you don't have a ton of choices. I haven't really used Gtk-rs enough to say more than that, really.
      - pjmlp 9y ago
        Basically the idea of having structs implementing widgets, which need to respond to UI events and handle their state, stored as struct fields. On modern C++ you can easily use this approach with std::enable_shared_from_this.