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

271–280 of 342 posts

Re: A half-hour to learn Rust

#271

Post by infradig »

New to Rust, was excited to see Prolog anonymous variables make an appearance. But one thing struck me is the mismatch between variable and function declarations...

  let x: i32 = 42;
vs

  fn fair_dice_roll() -> i32 { 4 }
It seems the designers missed an opportunity, as the latter could quite easily have been:

  fn fair_dice_roll() : i32 = 4;
or

  fn fair_dice_roll() : i32 = { ... code that produces 4... }
at the slight expense of giving up the cutesy right-arrow. Maybe i'm just used to Prolog/Lisp code=data syntactic simplicity.

And that's as far as I got as I exited the page scratching my head to write this comment.

Re: A half-hour to learn Rust

#272

Post by mikepurvis »

projct wrote: post #266
mikepurvis wrote: post #243

Earlier quoted context omitted.

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…

If you get rid of unwrap and use `if let` and `match`, this code will clean up nicely. If the code is supposed to be maintainable, you could also make something like a FromRegex trait for Input. It would be a good idea to try exercism's mentoring thing to get better at writing it the easier way the first time. The mentoring thing really is what helped me to think in ways that made this mess easier to avoid.

Fair fair. To be honest, I think in a lot of these cases there are good helper crates/macros; for this I would now probably use recap: https://docs.rs/recap/0.1.1/recap/

The really horrendous scenario was when I was trying to navigate pest iterators for parsing according to a grammar.

Re: A half-hour to learn Rust

#273

Post by Geminidog »

simias wrote: post #209
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.

I find that advanced Python is quite hard to read. Well, I find that advanced dynamically typed languages tend to be hard to read in general, because you can never be sure what type your inputs and outputs are and what values they can take. Usually my At least idiomatic Python shuns wildcard imports that obfuscate where symbols are coming from (that drove me insane in Ruby). On the other hand Rust code tends to be ve…

Python now supports type annotations. With mypy those types can be checked. Any python shop worth it's salt should be switching or has switched.

Re: A half-hour to learn Rust

#274

Post by kag0 »

infradig wrote: post #271

New to Rust, was excited to see Prolog anonymous variables make an appearance. But one thing struck me is the mismatch between variable and function declarations... let x: i32 = 42; vs fn fair_dice_roll() -> i32 { 4 } It seems the designers missed an opportunity, as the latter could quite easily have been: fn fair_dice_roll() : i32 = 4; or fn fair_dice_roll() : i32 = { ... code that produces 4... } at the slight expe…

I thought the same. After how consistent Scala's syntax is, it's hard to adjust to what Rust has done here. In Scala

  val hello : String = "hello" // eagerly evaluated once
  def hello : String = "hello" // evaluated every time
  def hello(name: String) : String = s"hello $name" // parameters

Re: A half-hour to learn Rust

#275

Post by GrumpySloth »

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.

Yup, similar is 3.5->3.7. The community also doesn't seem to value backwards-compatiblity, judging from the libraries.

Re: A half-hour to learn Rust

#276

Post by yakubin »

fasterthanlime wrote: post #190
volta87 wrote: post #185

Earlier quoted context omitted.

I think that being able to write down the lifetimes in the language is beautiful. You don't have to do it, but if you want to do it, being able to do so in a way that's verified and enforced by the toolchain beats doing so in a documentation comment. Now every time I read a doc string saying that I need to "deepcopy" something in Python for some API usage pattern to work properly I cringe.

That's one of the things that get me about Rust discourse: it seems that "Rust is pain in exchange for performance" is a common misconception. Rust is discipline in exchange for performance and correctness . A GC lets you be relatively worry-free as far as memory leaks go (and even then..) but it doesn't prevent a lot of the correctness problems the borrow checker would. With a checker you're forced to think: do I re…

I don't see how a GC would do anything with memory leaks. When you have a data structure containing some elements, and you keep a reference to the structure, because you need some data from it, but you let it grow, then you have a leak, GC or no GC. If anything, GC encourages memory leaks by making freeing memory implicit, something a programmer normally doesn't think about. And yet a resize/push operation on a vector (sic!) is just another malloc. One that will get ignored by a GC.

GC protects you against double-free and use-after-free, but memory leaks? Nope.

Re: A half-hour to learn Rust

#277

Post by yakubin »

volta87 wrote: post #185
ithrow wrote: post #171

Earlier quoted context omitted.

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. All those lifetime annotations are not sheer beauty or pretty, sure they are necessary but not nice to look at if you are comparing it to a higher level language.

I think that being able to write down the lifetimes in the language is beautiful. You don't have to do it, but if you want to do it, being able to do so in a way that's verified and enforced by the toolchain beats doing so in a documentation comment. Now every time I read a doc string saying that I need to "deepcopy" something in Python for some API usage pattern to work properly I cringe.

For me it's also faster to read lifetimes, which have a standard concise syntax, versus ad-hoc documentation.

Re: A half-hour to learn Rust

#278

Post by felipellrocha »

christiansakai wrote: post #242
felipellrocha wrote: post #205

Earlier quoted context omitted.

> 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.

Agreed it could be a little more ergonomic, but it wasn't a blocker. I was able to figure it all out in a weekend, and write plenty of services with it.

Re: A half-hour to learn Rust

#279

Post by fasterthanlime »

throwaway894345 wrote: post #244
the_duke wrote: post #206

Earlier quoted context omitted.

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 p…

Libraries can be (and some actually are) designed with that in mind, with COW (copy on write( types that can be either borrowed or owned. Speaking of performance, kstring (of liquid) goes one step further with inline variants for short strings.

I want to say that seems like a valid concern but in practice I've seen it come up only rarely.

Re: A half-hour to learn Rust

#280

Post by fasterthanlime »

brabel wrote: post #55
CJefferson wrote: post #51

Earlier quoted context omitted.

I often use the "owl" , usually in Result .

Why use a Result whose error type is empty?

It's sometimes called a type-level boolean. Instead of trying to remember what true or false means, you have explicit variants associated with success or failure. (The underlying representation, including bit width, is the same)
Post reply on HN