Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A half-hour to learn Rust

fasterthanli.me

Post reply on HN
Print view View original

241–250 of 342 posts

Re: A half-hour to learn Rust

#241

Post by _nckn »

cute_boi wrote: post #219
christiansakai wrote: post #188

Earlier quoted context omitted.

Rust makes hard things easy and easy things hard. Also reading Python code is easier (less syntax noise) on the eyes. The article above is very beginner Rust, and I won't rely on that to look at actual Rust code in the wild. If you want to take a look at what actual Rust code in the wild, take for example, a web server Actix, and try to figure out what the documentation says.

"Rust makes hard things easy and easy things hard." Disagree here. Like article Rust 2018 is very nice and ergonomic. Iterators, Lifetime Elision etc are nice to work. Regarding noise many people consider those noise but I find noises like return types etc very useful. Because I can be sure the return type. Regarding actual code actix doesn't look that bad from examples also. I use warp and its pleasant to work. The…

Actual code examples from Actix isn’t that bad but take a look at the docs.

Re: A half-hour to learn Rust

#242

Post by christiansakai »

felipellrocha wrote: post #205
christiansakai wrote: post #188

Earlier quoted context omitted.

Rust makes hard things easy and easy things hard. Also reading Python code is easier (less syntax noise) on the eyes. The article above is very beginner Rust, and I won't rely on that to look at actual Rust code in the wild. If you want to take a look at what actual Rust code in the wild, take for example, a web server Actix, and try to figure out what the documentation says.

> Rust makes hard things easy and easy things hard. I don't agree with this, and, if anything, this reads very biased. Insofar, Rust has made my life a lot easier, and I have not run into any major issues aside the borrow checker. And this was early on. Two years now playing with the language and I barely run into it anymore.

Async has ecosystem fracture issues. Creating graph data structures require you to understand more about borrow checker.

Majority of people will probably want to use Rust for web? Which makes async needs to be ergonomic enough if it wants consider wide adoption.

Re: A half-hour to learn Rust

#243

Post by mikepurvis »

cute_boi wrote: post #219
christiansakai wrote: post #188

Earlier quoted context omitted.

Rust makes hard things easy and easy things hard. Also reading Python code is easier (less syntax noise) on the eyes. The article above is very beginner Rust, and I won't rely on that to look at actual Rust code in the wild. If you want to take a look at what actual Rust code in the wild, take for example, a web server Actix, and try to figure out what the documentation says.

"Rust makes hard things easy and easy things hard." Disagree here. Like article Rust 2018 is very nice and ergonomic. Iterators, Lifetime Elision etc are nice to work. Regarding noise many people consider those noise but I find noises like return types etc very useful. Because I can be sure the return type. Regarding actual code actix doesn't look that bad from examples also. I use warp and its pleasant to work. The…

I'm a recent Rust fan (via AoC), but for "easy things hard", I would offer input/string processing as an example— regexes, string operations, grammar, etc. I know that Rust is forcing me to be correct and handle (or explicitly acknowledge that I'm not handling) my error cases, but from the point of view of just wanting to get the happy path working, it's a lot more noise to deal with compared with what it would look like in Python, eg:

        let re = Regex::new("(?P[0-9]+)-(?P[0-9]+) (?P[a-z]): (?P[a-z]*)").unwrap();
        re.captures_iter(&contents).map(|caps|
            Input {
                password: caps.name("password").unwrap().as_str().to_string(),
                letter: caps.name("letter").unwrap().as_str().chars().next().unwrap(),
                min: caps.name("min").unwrap().as_str().parse().unwrap(),
                max: caps.name("max").unwrap().as_str().parse().unwrap()
            }
        ).collect()

Re: A half-hour to learn Rust

#244

Post by throwaway894345 »

the_duke wrote: post #206
throwaway894345 wrote: post #196

Earlier quoted context omitted.

Pretty sure if you’re deserializing a structure with borrowed references you need lifetime annotations. Copying things around to pacify the compiler hardly seems elegant.

Sure, but that's a performance vs ease of use decision. Often you don't need to care about the extra allocations and can just deserialize to owned types. The code for owned deserialization certainly ends up looking more elegant.

It’s not just performance, but you now have to go back and update every instance of that struct to reflect the change in ownership of that member if you can even change the member in the first place (e.g., you can’t change the type of a member of the struct itself is defined in a third-party package). Moreover, some instances of your struct might be in a tight loop and others might not, but now you’re committing to poorer performance in all cases. Maybe you can box it (although IIRC I’ve run into other issues when I tried this) but in any case this isn’t the “elegance” I was promised. Which is fine, because Rust is a living, rapidly-improving language, but let’s not pretend that there is an elegant solution today.

Re: A half-hour to learn Rust

#245

Post by mikeschmatz »

nitred wrote: post #161

As a Python programmer with limited experience with compiled languages, Rust code was more intimidating to read or look at than C++, Java or Go. After only an hour, I am overwhelmed by the sheer beauty and mature design of this language - it almost reads like Python or as well as any compiled language can. I cannot believe that I am smitten by Rust within an hour. Its features seem, obvious. My experience with Go was…

Rust is a complete pain for the types of problems Python is used for. Same for Go/Java.

Re: A half-hour to learn Rust

#246

Post by akavel »

Newbie question: in the last example:

  fn make_tester(answer: &str) -> impl Fn(&str) -> bool + '_ {
      move |challenge| {
          challenge == answer
      }
  }
why is there `move` needed, if both `answer`, and the arg of `Fn`, seem to be references (`&str`)? To a layman, this sounds like as if both "challenge" and "answer" should be borrowed - so why "move"? what's even to move here?

Re: A half-hour to learn Rust

#247

Post by throwaway894345 »

the_duke wrote: post #204
gpm wrote: post #186

Earlier quoted context omitted.

Most languages just clone all day long, it's not that bad, rust clones (like most languages) are just to the first reference counted pointer after all.

Well, yes and no. Eg cloning a string leads to an extra allocation and a memcopy. If you want to get a similar performance profile to GC languages, you have to stick your types behind a `Rc >/Arc ` or `Rc > / Arc >` if you need mutability. But modern allocators hold up pretty well to a GC, which amortizes the allocations. The extra memcopying can be less detrimental than one might think.

“Yes and no” is too generous; most languages clone only very infrequently (basically only for primitives where there is no distinction between a deep and shallow copy). For complex types (objects and maps and lists) they pass references (sometimes “fat” references, but nevertheless, not a clone).

Re: A half-hour to learn Rust

#248

Post by alexanderdmitri »

gpm wrote: post #240
unethical_ban wrote: post #237

Earlier quoted context omitted.

My only bone to pick with this commentary is that it is 2020 and people are still complaining about Python as being unstable because of 2 -> 3. It was a rough transition, to be sure. Python2 was released 20 years ago, and Python3 12 years ago. It is a pretty stable language.

My housemate was just rolling back from python 3.8 to 3.7 yesterday due to a backwards incompatible change breaking a library... it's not just 2 -> 3 that makes python relatively unstable compared to rust.

What the issue?

Re: A half-hour to learn Rust

#249

Post by throwaway894345 »

nobleach wrote: post #226
throwaway894345 wrote: post #197

Earlier quoted context omitted.

To be clear, JS doesn’t require cloning because it has a gc. Not sure what you’re getting at with reusing variables names...

What I mean is, if one does: const obj1 = { a: 32, b: 42 }; function foo(ref) { ref.a = 0; } foo(obj1); console.log(obj1); in JavaScript, one is just using the variable name as a "holder" of some value. One doesn't have to designate that that variable is being passed by reference. If one wanted to actually copy that object, they'd have to devise a mechanism to do so. In Rust, if someone doesn't specify, using the & s…

Oh, by “reuse variable names”, you simply mean that values aren’t moved, i.e., that JS lacks move semantics or an affine type system. That’s a bit different to “reusing variable names”, which you can do in Rust as well provided the variable holds a (certain kind of?) reference.
Post reply on HN