Live data from Hacker News

A half-hour to learn Rust (2020)

fasterthanli.me

61–70 of 86 posts

Re: A half-hour to learn Rust (2020)

#61
post #9

This is, more or less, how I learned Rust circa 2015 (might have been a couple years later). I quickly started to write programs like I would have in C but got completely thwarted by the borrow checker because I wanted pointers everywhere. This made me throw my hands up and leave for other languages. However, 8 years later I did eventually come to love rust after learning the One Weird Trick of using indices instead…

Can you contrast between both approaches? How can i use indices instead of pointers? Where can i learn more?

If you're looking for something with a narrative you can watch, the RustConf 2018 closing keynote https://www.youtube.com/watch?v=aKLntZcp27M is a great talk that has an overview on "generational arenas", which are effectively "just" a vector with a custom index type that holds the "pointed-to" generation, and the stored values also store their generation inline. This allows: all objects to be stored in a contiguous block of memory (increasing the likelihood of "pointer-chasing" style of code to have the pointed to value warm in cache, significantly speeding them up), allows relocation (because you're no longer dealing with pointers, but rather offsets to the beginning of the pointer), and doesn't have the pointer invalidation problem (because the "pointer" now asserts that the pointed to value hasn't changed, and if so return an Err/None). It also has the benefit that because you're not dealing with pointers you don't need to write any unsafe Rust code, out of bound accesses are checked, and the borrow graph becomes simpler because the arena owns all of its contents, instead of having to keep track of the lifetime of borrows at compile time (the famous "fighting with the borrow checker") nor is as "expensive" as the tracking an Arc> could be.

Re: A half-hour to learn Rust (2020)

#62
post #49

Earlier quoted context omitted.

I get the impression that Rust revisions are (at least intended to be?) backwards compatible: [0] Are there are good workarounds when breaking changes to occur? No idea if/how well breaking language changes can be isolated to stay within individual crates. [0] https://subscription.packtpub.com/book/programming/978178934...

> I get the impression that Rust revisions are (at least intended to be?) backwards compatible I don't think that matters at all. If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.

Is there any language toolchain that isn't absolutely static capable of having not only backwards compatibility but also forwards compatibility? If I try to open an MS Office XP file in MS Office 97, it will fail. If I try to run a new linux application that uses a new syscall in an older kernel, it will fail. If I try to use structural pattern matching in Python 3.9, it will fail. How is Rust any different?

If the concern is that projects are using "too new a rustc version", then your beef is with those projects, but be advised that demanding open source projects not use newer versions of their toolchains can be a big ask that increases their workloads and they might not be amenable to cater to your usecase.

Finally, because every Rust version is backwards compatibility, there's no reason for builders and developers to not use the latest stable release as quickly as feasible, all existing projects will continue compiling.

Re: A half-hour to learn Rust (2020)

#63
post #50

Earlier quoted context omitted.

Not sure if I disagree but your example is terrible. Let patterns in if statements greatly simplify things. The alternatives are a lot more convoluted. See example from code I wrote this week: https://github.com/trane-project/trane/blob/master/src/data/... Without the let, I'd have to do a match statement followed by an unwrap just to check if a field in an enum is set.

You are confusing shortening with simplifying. The `if let` syntax is an unnecessary addition to the language so it is by definition an added complexity. Of course the resulting code is much easier to read and I definitely agree that it's a nice feature but I wouldn't pretend it made the language simpler, just more comfortable once you already know it.

Exactly what I had in mind, thank you for explaining it so succinctly!

Re: A half-hour to learn Rust (2020)

#64

This might not be a popular opinion, but - I love the idea of Rust, but the language itself seems needlessly complex to me. It looks like the authors tried to cover so many esoteric usecases that the result is more like C++ than C (which is not good in my eyes). One example: > `let` patterns can be used as conditions in `if`: Anyway, this tutorial looks great, I'll give Rust another go when I have a good project for…

The problem with Rust is learning it for... > when I have a good project for it ... is a bad idea. I've heard this from several programmers who now use Rust professionally, but don't have first-hand experience about it. Their take can be boiled down to: Rust has a learning curve that will mean that the first version will invariably be throw-away. Developing a mental model for how to change memory management structure…

I understand it will be a throwaway project, that's fine. But it helps me learn if I have a goal in front of me.

Re: A half-hour to learn Rust (2020)

#65

Earlier quoted context omitted.

> got completely thwarted by the borrow checker IMvHO, Rust Ownership and Lifetime rules aren't really that hard to learn. The only trick is that a programmer cannot learn Rust exclusively by trial-and-error (which programmers love to do), trying dozens of syntax combinations to see what works. A programmer is forced to learn Rust by RTFM (which programmers hate to do), in order to understand how Rust works. That's a…

Rust has fabulous error messages, so I do a lot of programming by trial and error.

True, but because there are many ways to satisfy the borrow checker it is very easy to arrive at needlessly complicated solutions. Idiomatic solutions on the other hand aren’t always obvious.

Re: A half-hour to learn Rust (2020)

#66

This might not be a popular opinion, but - I love the idea of Rust, but the language itself seems needlessly complex to me. It looks like the authors tried to cover so many esoteric usecases that the result is more like C++ than C (which is not good in my eyes). One example: > `let` patterns can be used as conditions in `if`: Anyway, this tutorial looks great, I'll give Rust another go when I have a good project for…

> I love the idea of Rust, but the language itself seems needlessly complex Well, I have to agree Rust isn't one of the simplest PL-s on the planet. This is due to the fact that it is quite a modern PL and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all. It takes, inde…

> ...and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all.

Yes, exactly! Now can I have just a safe C without all the other stuff, pretty please? :) I understand Rust is not it, but I hope someone comes up with a simple PL which is also compile-time memory safe. I think it would be an instant hit.

Re: A half-hour to learn Rust (2020)

#67
post #50

Earlier quoted context omitted.

Not sure if I disagree but your example is terrible. Let patterns in if statements greatly simplify things. The alternatives are a lot more convoluted. See example from code I wrote this week: https://github.com/trane-project/trane/blob/master/src/data/... Without the let, I'd have to do a match statement followed by an unwrap just to check if a field in an enum is set.

You are confusing shortening with simplifying. The `if let` syntax is an unnecessary addition to the language so it is by definition an added complexity. Of course the resulting code is much easier to read and I definitely agree that it's a nice feature but I wouldn't pretend it made the language simpler, just more comfortable once you already know it.

You imply simple = better, complex = worse, but this isn't such a simple relationship.

If you keep removing redundant constructs from languages, you will end up with something pure and minimal like the lambda calculus or turing machine. But these aren't easy to program in!

Languages are an interface for humans. If the code density is too low or too high, it becomes difficult to for people reason about the programs. Concepts like readability and expressiveness are important, but end up requiring some level of complexity.

Re: A half-hour to learn Rust (2020)

#68

Earlier quoted context omitted.

> I love the idea of Rust, but the language itself seems needlessly complex Well, I have to agree Rust isn't one of the simplest PL-s on the planet. This is due to the fact that it is quite a modern PL and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all. It takes, inde…

> ...and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all. Yes, exactly! Now can I have just a safe C without all the other stuff, pretty please? :) I understand Rust is not it, but I hope someone comes up with a simple PL which is also compile-time memory safe. I think…

> Now can I have just a safe C without all the other stuff, pretty please? :)

Hmmmmm, if you are not being forced by others into any particular Rust feature set (standard) and you are not being forced into any preexisting Rust codebase, then perhaps just forget the entire standard library, traits, async, etc. and go Bare Metal Rust[1], using only the Rust language features that you need and interfacing with external C APIs through Foreign Function Interface[2].

[1] https://google.github.io/comprehensive-rust/bare-metal.html

[2] https://doc.rust-lang.org/nomicon/ffi.html

Re: A half-hour to learn Rust (2020)

#69
post #67
post #50

Earlier quoted context omitted.

You are confusing shortening with simplifying. The `if let` syntax is an unnecessary addition to the language so it is by definition an added complexity. Of course the resulting code is much easier to read and I definitely agree that it's a nice feature but I wouldn't pretend it made the language simpler, just more comfortable once you already know it.

You imply simple = better, complex = worse, but this isn't such a simple relationship. If you keep removing redundant constructs from languages, you will end up with something pure and minimal like the lambda calculus or turing machine. But these aren't easy to program in! Languages are an interface for humans. If the code density is too low or too high, it becomes difficult to for people reason about the programs. C…

Exactly, it's a smooth trade off curve from lambda calculus all the way to Haskell with 30 language extensions enabled.

You could learn lambda calculus in an afternoon, but then spend a month writing a single complex algorithm. You could spend 5 years learning Haskell, and then write the most powerful system in a couple minutes.

There's a sweet spot somewhere between those two, and Rust is definitely near it.

Post reply on HN