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

Flattening Rust’s learning curve

corrode.dev

Post reply on HN
Print view View original

261–270 of 405 posts

Re: Flattening Rust’s learning curve

#261

Post by ModernMech »

8s2ngy wrote: post #92

It took me a few tries to get comfortable with Rust—its ownership model, lifetimes, and pervasive use of enums and pattern matching were daunting at first. In my initial attempt, I felt overwhelmed very early on. The second time, I was too dogmatic, reading the book line by line from the very first chapter, and eventually lost patience. By then, however, I had come to understand that Rust would help me learn programm…

Your experience matches an observation I have made, that when C++ developers approach Rust for the first time they often "fight the borrow checker" when they use C++ idioms in Rust. Then they start to learn Rust idioms, and bring them back to C++, which causes them to write more robust code despite not having and borrow checking at all.

Re: Flattening Rust’s learning curve

#262

Post by jplusequalt »

rikafurude21 wrote: post #252
atoav wrote: post #204

Earlier quoted context omitted.

But it is true. My own biggest mistake when learning Rust was that I tried to torce Object Oriented paradigms on it. That went.. poorly. As soon as I went "fuck it, I just do it like you want" things went smoothly.

Sounds like an abusive relationship if im being honest. Your programming language shouldnt constrict you in those ways.

>Your programming language shouldn't constrict you in those ways

Says who? Programming languages come in all shapes and sizes, and each has their tradeoffs. Rust's tradeoff is that the compiler is very opinionated about what constitutes a valid program. But in turn it provides comparable performance to C/C++ without many of the same bugs/security vulnerabilities.

Re: Flattening Rust’s learning curve

#263

Post by amelius »

andromeduck wrote: post #259
amelius wrote: post #212

Earlier quoted context omitted.

Seems incomplete. E.g. what happens if a borrower goes away?

It stops being borrowed?! What kind of question is this.

A question about definitions. Some other options would be:

    - the object is destroyed
    - the program core dumps
    - it is a compile time error
Assuming the best possible outcome in case of missing information turns out to be a bad strategy in general.

Re: Flattening Rust’s learning curve

#264

Post by steveklabnik »

conorjh wrote: post #198
psychoslave wrote: post #131

Earlier quoted context omitted.

Well, it does look like there is a will to mimic religious social structure in the community, be it as a satiric form of it. I mean, I guess they purposefully named their pancakes cargo, as in "cargo cult", didn't they? Rustacean, rustomicon, and the other few words I saw leak out of the community all seem to go in the same spirit. I'm almost surprised they didn't went with more fancy terms for these core concepts of…

the dogmatic culture would probably be my first suggestion. i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly

> i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly

The answer is straightforward: bugs exist. Even in formally proven software, mistakes can be made. Nothing is perfect.

Additionally, memory safety is a property that when people talk about it, they mean by default. All languages contain some amount of non-proven unsafe code in their implementation, or via features like FFI. Issues can arise when these two worlds interact. Yet, real-world usage shows that these cases are quite few compared to languages without these defaults. The exceptions are also a source of the CVEs you’re talking about.

Re: Flattening Rust’s learning curve

#265

Post by steveklabnik »

swiftcoder wrote: post #191
bsder wrote: post #130

Earlier quoted context omitted.

> If a language needs an article like this, absolutely begging people to bite the bullet to learn it, maybe that's a language design smell. The problem with articles like this is that they don't really get to the heart of the problem: There are programs that Rust will simply not let you write. Rust has good reasons for this. However, this is fundamentally different from practically every programming language that peo…

> There are programs that Rust will simply not let you write. Can you specify a few of these programs? I can see where Rust might not allow you to write something the way you want to , but I fail to see how a program would not be expressible in rust...

They mean in Safe Rust. Unsafe is included in Rust for this reason.

Re: Flattening Rust’s learning curve

#266

Post by hbn »

rikafurude21 wrote: post #252
atoav wrote: post #204

Earlier quoted context omitted.

But it is true. My own biggest mistake when learning Rust was that I tried to torce Object Oriented paradigms on it. That went.. poorly. As soon as I went "fuck it, I just do it like you want" things went smoothly.

Sounds like an abusive relationship if im being honest. Your programming language shouldnt constrict you in those ways.

Every programming language has constrictions by the nature of having syntax.

In JavaScript you can declare a variable, set it to 5 (number), and then set it to the "hello" (string), but that's not allowed in e.g. C. Is C constricting me too much because I have to do it in C's way?

Re: Flattening Rust’s learning curve

#267

Post by jmull »

I'm not sure there are many cases where I would choose rust. I'm open to it. I just think in any given situation there would most likely be a better option.

Perhaps it will become prevalent enough that it will make sense in the future.

Re: Flattening Rust’s learning curve

#268

Post by ModernMech »

rikafurude21 wrote: post #252
atoav wrote: post #204

Earlier quoted context omitted.

But it is true. My own biggest mistake when learning Rust was that I tried to torce Object Oriented paradigms on it. That went.. poorly. As soon as I went "fuck it, I just do it like you want" things went smoothly.

Sounds like an abusive relationship if im being honest. Your programming language shouldnt constrict you in those ways.

Abusive relationships involve coercion, control, fear, and often violate personal autonomy and consent. One party dominates the other in a harmful way. Using Rust is not harmful.

Placing restrictions on the programs a programmer can write is not abusive. The rules exist to ensure clarity, safety, performance, and design goals. In an abusive relationship, rules are created to control or punish behavior, often changing capriciously and without reason or consultation. By contrast, Rust is designed by a group of people who work together to advance the language according to a set of articulated goals. The rules are clear and do not change capriciously.

Abuse causes emotional trauma, isolation, and long-term harm. Rust may cause feelings of frustration and annoyance, it may make you a less efficient programmer, but using it does not cause psychological or physical harm found in abusive relationships.

Re: Flattening Rust’s learning curve

#269

Post by geodel »

echelon wrote: post #241
xiphias2 wrote: post #128

Earlier quoted context omitted.

I think the most important lesson is this: Ownership is easy, borrowing is easy, what makes the language super hard to learn is that functions must have signatures and uses that together prove that references don't outlive the object. Also: it's better not store referenced object in a type unless it's really really needed as it makes the proof much much more complex.

> Ownership is easy, borrowing is easy 100%. It's the programmer that needs to adapt to this style. It's not hard by any means at all, it just takes some adjustment.

Indeed. Programmers are holding Rust wrong.

Re: Flattening Rust’s learning curve

#270

Post by agumonkey »

Animats wrote: post #18

It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff. Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples. - Each data object in Rust has exactly one owner. - Ownership can be transferred in ways that preserve the one-owner ru…

I often wanted to find writings about the 60s on how they approached system/application state at assembly level. I know Sutherland Sketchpad thesis has a lot of details about data structures but I never read it (except for 2-3 pages).
Post reply on HN