5 ms·

Reading this document suddenly made learning Rust a lot scarier, and also increases my respect to Rust developers (people writing programs in Rust). It kind of

by antpls 6y ago

Reading this document suddenly made learning Rust a lot scarier, and also increases my respect to Rust developers (people writing programs in Rust). It kind of shows that increased safety doesn't come for free.

kd5bjo 6y ago
For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.
- Someone 6y ago
  If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.
  - kd5bjo 6y ago
    You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
  - naasking 6y ago
    > If fighting with the compiler is necessary for learning I don't think "fighting the compiler" is a useful concept. No matter what language you're learning, you have to learn both the language's syntax and semantics. If your program barfs up an error at runtime because you made a semantic error the language forbids, that's no better than barfing up an error at compile time because you made semantic error the language forbids. So it's both more accurate and more precise to say that a language's semantics might be complicated or subtle, but the compilation step is orthogonal to the actual problem you're talking about.
    - kd5bjo 6y ago
      The difference in when the error is flagged is a large difference, though. Usually, runtime semantic errors won’t be flagged until the program tries to actually perform some nonconforming action. That lets the programmer work on unrelated issues by simply not exercising the defective path. Compile-time errors, on the other hand, ensure that the entire program meets some baseline of correctness before any of it is run. Neither is necessarily better or worse than the other, but they are categorically different things that have their own effects on the experience of writing programs.
Measter 6y ago
In my (admittedly somewhat limited) experience, these don't come up that frequently. except number 5; I've had several times where I've had to be aware of where references are coming from. I would say give Rust a go anyway. Worst case is you end up not getting along with it, best case is you now have a new tool to reach for.
OJFord 6y ago
Don't let it, I've only skimmed it but I think you can get started and write some effective rust without even having or understanding the misconceptions. And even if you did gain a misconception, so what, apparently you'd just be joining other people writing rust who share the same one.
ChrisSD 6y ago
Tbh, I'm not sure that reading a list of falsehoods is the best introduction to actually programming in a language.
fluffything 6y ago
Pretty much all misconceptions named there can be avoided by following the advice that every Rust programmer will give you: read the damn book, it will save you a lot of time. If you are in the category of users that never RTFM, then I guess this article might be for you, but then kind of by definition, you won't read this article either, so... --- For example, in C++ a generic `T` can only mean an owned type: template<class T> void foo(T t); template<class T> void bar(T& t); You can't pass `foo` a reference to `T`, you'd need to pass it an owned type like `foo(std::ref(t))` instead or similar. In Rust, when you write fn foo<T>(t: T); you can call `foo` with an owned type or a reference, no problems, generic types are... well... generic. So if you start writing Rust code with a C++ background without reading the book, then you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell.
- gpderetta 6y ago
  > For example, in C++ a generic `T` can only mean an owned type: Wrong. template<class T> void foo(T t) { } int main() { int x = 0; foo<int&>(x); } Unadorned Ts as function parameters will by default be deducted as value types, but a generic T parameter can represent references just fine. This is especially important for template classes. > you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell. it seems to me that they are more similar than different.
  - fluffything 6y ago
    > Wrong. Indeed, thanks for the correction! > it seems to me that they are more similar than different. I think the Haskell vs Python comparison is accurate. Rust generics are strongly typed (definitions are checked), while C++ templates are "weakly" typed (type checked when they are instantiated). In C++ it is trivial to write templates that will never type check when instantiated, while in Rust this is impossible.
pretzelhammer 6y ago
Hi, document author here. I learned Rust because I was too scared to learn C++, lol. Rust has a steeper learning curve than most languages but it also has a very beginner-friendly and welcoming community. So don't be scared, you can do it! If you get stuck on something it's always easy to get help.
- wyufro 6y ago
  As someone who doesn't know Rust yet I feel there's a "do this instead" missing to point 8. It's not clear to me how to do it instead.
mikekchar 6y ago
I read this article with caution. I don't want to upset the delicate balance that is my intuition of how the borrow checker works. Articles that say "Don't think of it like X" are double edged swords ;-) In reality, though, while it took me a while to get relatively comfortable with the borrow checker (much longer than I expected as an old school C++ programmer), 99.9% of the time it works exactly as I expect. Of course the other 0.1% of the time takes a lot of my energy ;-)
isido 6y ago
This article is probably not aimed at Rust beginners and you shouldn't shy away from Rust, if you feel that you cannot possibly ever understand the lifetimes. The perspective of the article seems to stem from the author's own learning process, and might make sense only after you have some experience with the borrow checker and lifetimes. Most of the time everything might go smoothly, when you know the basic rules, but when the compiler gives you an error message, and you think it shouldn't have, then reading the article might give some insight on the problem. And the Rust developers indeed deserve respect in my opinion too. They are trying to solve a hard problem and not taking the worse-is-better-option.
mamcx 6y ago
I have programmed in something like 12 langs, and yes, the first 2 months of rust was kind of brutal to me. But a lot of it is UNLEARN. Before, I was doing mostly F# and believe back then I was a very functional developer, but now with rust I do more functional programming than before. Most of time, errors and problems show up because rust is trying to put you towards a way to design the code. The most you fight it, the harder is. I think, 90% of time rust is right. Doing ERP-like work I say rust is even more productive than F#, that was also great to me. -- Rust get truly hard when try to do pseudo OO, trying to do introspection (the harder stuff I think), and mix mutability inside the same struct. But most of that happend outside regular development (I'm building a toy lang and hit the hard stuff often)
jeffdavis 6y ago
In a way, it's liberating. Look at it as a service the compiler offers, where lifetime errors are a normal part of the development cycle. I use rust and I don't worry about the lifetime stuff. Just hack away and get the job done. Overall, rust is lower startup friction than most of the tools I use (though YMMV).
rq1 6y ago
It depends on your background. If you come from C/C++ then all the notions discussed should be familiar to you, because you used to do the borrowing and lifetime management manually, or you were doing something really wrong. :) Whereas the rust compiler helps you with all this (super hard and annoying) stuff.

by antpls 6y ago

kd5bjo 6y ago

For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.

Someone 6y ago
If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.
- kd5bjo 6y ago
  You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
- naasking 6y ago
  > If fighting with the compiler is necessary for learning I don't think "fighting the compiler" is a useful concept. No matter what language you're learning, you have to learn both the language's syntax and semantics. If your program barfs up an error at runtime because you made a semantic error the language forbids, that's no better than barfing up an error at compile time because you made semantic error the language forbids. So it's both more accurate and more precise to say that a language's semantics might be complicated or subtle, but the compilation step is orthogonal to the actual problem you're talking about.
  - kd5bjo 6y ago
    The difference in when the error is flagged is a large difference, though. Usually, runtime semantic errors won’t be flagged until the program tries to actually perform some nonconforming action. That lets the programmer work on unrelated issues by simply not exercising the defective path. Compile-time errors, on the other hand, ensure that the entire program meets some baseline of correctness before any of it is run. Neither is necessarily better or worse than the other, but they are categorically different things that have their own effects on the experience of writing programs.

Measter 6y ago

In my (admittedly somewhat limited) experience, these don't come up that frequently. except number 5; I've had several times where I've had to be aware of where references are coming from. I would say give Rust a go anyway. Worst case is you end up not getting along with it, best case is you now have a new tool to reach for.

OJFord 6y ago

Don't let it, I've only skimmed it but I think you can get started and write some effective rust without even having or understanding the misconceptions. And even if you did gain a misconception, so what, apparently you'd just be joining other people writing rust who share the same one.

ChrisSD 6y ago

Tbh, I'm not sure that reading a list of falsehoods is the best introduction to actually programming in a language.

fluffything 6y ago

Pretty much all misconceptions named there can be avoided by following the advice that every Rust programmer will give you: read the damn book, it will save you a lot of time. If you are in the category of users that never RTFM, then I guess this article might be for you, but then kind of by definition, you won't read this article either, so... --- For example, in C++ a generic `T` can only mean an owned type: template<class T> void foo(T t); template<class T> void bar(T& t); You can't pass `foo` a reference to `T`, you'd need to pass it an owned type like `foo(std::ref(t))` instead or similar. In Rust, when you write fn foo<T>(t: T); you can call `foo` with an owned type or a reference, no problems, generic types are... well... generic. So if you start writing Rust code with a C++ background without reading the book, then you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell.

gpderetta 6y ago
> For example, in C++ a generic `T` can only mean an owned type: Wrong. template<class T> void foo(T t) { } int main() { int x = 0; foo<int&>(x); } Unadorned Ts as function parameters will by default be deducted as value types, but a generic T parameter can represent references just fine. This is especially important for template classes. > you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell. it seems to me that they are more similar than different.
- fluffything 6y ago
  > Wrong. Indeed, thanks for the correction! > it seems to me that they are more similar than different. I think the Haskell vs Python comparison is accurate. Rust generics are strongly typed (definitions are checked), while C++ templates are "weakly" typed (type checked when they are instantiated). In C++ it is trivial to write templates that will never type check when instantiated, while in Rust this is impossible.

pretzelhammer 6y ago

Hi, document author here. I learned Rust because I was too scared to learn C++, lol. Rust has a steeper learning curve than most languages but it also has a very beginner-friendly and welcoming community. So don't be scared, you can do it! If you get stuck on something it's always easy to get help.

wyufro 6y ago
As someone who doesn't know Rust yet I feel there's a "do this instead" missing to point 8. It's not clear to me how to do it instead.

mikekchar 6y ago

I read this article with caution. I don't want to upset the delicate balance that is my intuition of how the borrow checker works. Articles that say "Don't think of it like X" are double edged swords ;-) In reality, though, while it took me a while to get relatively comfortable with the borrow checker (much longer than I expected as an old school C++ programmer), 99.9% of the time it works exactly as I expect. Of course the other 0.1% of the time takes a lot of my energy ;-)

isido 6y ago

This article is probably not aimed at Rust beginners and you shouldn't shy away from Rust, if you feel that you cannot possibly ever understand the lifetimes. The perspective of the article seems to stem from the author's own learning process, and might make sense only after you have some experience with the borrow checker and lifetimes. Most of the time everything might go smoothly, when you know the basic rules, but when the compiler gives you an error message, and you think it shouldn't have, then reading the article might give some insight on the problem. And the Rust developers indeed deserve respect in my opinion too. They are trying to solve a hard problem and not taking the worse-is-better-option.

mamcx 6y ago

I have programmed in something like 12 langs, and yes, the first 2 months of rust was kind of brutal to me. But a lot of it is UNLEARN. Before, I was doing mostly F# and believe back then I was a very functional developer, but now with rust I do more functional programming than before. Most of time, errors and problems show up because rust is trying to put you towards a way to design the code. The most you fight it, the harder is. I think, 90% of time rust is right. Doing ERP-like work I say rust is even more productive than F#, that was also great to me. -- Rust get truly hard when try to do pseudo OO, trying to do introspection (the harder stuff I think), and mix mutability inside the same struct. But most of that happend outside regular development (I'm building a toy lang and hit the hard stuff often)

jeffdavis 6y ago

In a way, it's liberating. Look at it as a service the compiler offers, where lifetime errors are a normal part of the development cycle. I use rust and I don't worry about the lifetime stuff. Just hack away and get the job done. Overall, rust is lower startup friction than most of the tools I use (though YMMV).

rq1 6y ago

It depends on your background. If you come from C/C++ then all the notions discussed should be familiar to you, because you used to do the borrowing and lifetime management manually, or you were doing something really wrong. :) Whereas the rust compiler helps you with all this (super hard and annoying) stuff.