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

191–200 of 405 posts

Re: Flattening Rust’s learning curve

#191

Post by swiftcoder »

bsder wrote: post #130
mdwhatcott wrote: post #42

[flagged]

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

Re: Flattening Rust’s learning curve

#192

Post by wepple »

make3 wrote: post #183
cyber1 wrote: post #180

"Safe" Rust is generally a simple language compared to C++. The borrow checker rules are clean and consistent. However, writing in it isn't as simple or intuitive as what we've seen in decades of popular systems languages. If your data structures have clear dependencies—like an acyclic graph then there's no problem. But writing performant self-referential data structures, for example, is far from easy compared to C++…

"raw pointers are one of the most important concepts in CS" that's a reach and a half, I don't remember the last time I've used one

The concept of being able to reference a raw memory address and then access the data at that location directly feels pretty basic computer science.

Perhaps you do software engineering in a given language/framework?

A clutch is fundamental to automotive engineering even if you don’t use one daily.

Re: Flattening Rust’s learning curve

#193

Post by imtringued »

throwawaymaths wrote: post #129
mikepurvis wrote: post #88

Earlier quoted context omitted.

"Rust basically just calls 'free' for you the moment something goes out of scope." C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it. The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fa…

the tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong . in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules. It's really too bad rust went the RAII route.

Okay, but an IDE could just visualize that for you. A linter rule could force you to manually drop if you want to be explicit.

Re: Flattening Rust’s learning curve

#194

Post by swiftcoder »

SkiFire13 wrote: post #134
baalimago wrote: post #120

>For instance, why do you have to call to_string() on a thing that’s already a string? It's so hard for me to take Rust seriously when I have to find out answers to unintuitive question like this

Just because a language is not high level enough to have a unique concept of "string" type doesn't mean you shouldn't take it seriously.

Even very high-level languages don't have singular concepts of string. Every serious language I can think of differentiates between:

- A sequence of arbitrary bytes

- A sequence of non-null bytes interpreted as ASCII

- A sequence of unicode code points, in multiple possible encodings

Re: Flattening Rust’s learning curve

#195

Post by kaycey2022 »

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 think the Brown University’s modifications to the rust book do an excellent job of explaining the borrow checker.

Re: Flattening Rust’s learning curve

#196

Post by guappa »

Salgat wrote: post #32
bigstrat2003 wrote: post #19

Earlier quoted context omitted.

"Just write everything async" is not remotely a good solution to the problem. Not everything needs to be async (in fact most things don't), and it's much harder to reason about async code. The issue is very much not overblown.

Why is async code harder to reason about? I've been using it in C# and the entire point is that it lets you write callbacks in a way that appears nearly identical to synchronous code. If you dive into concurrency (which is a separate thing but can be utilized with async code, such as joining multiple futures at the same time), that parts hard whether you're doing it with async or with explicit threads.

Because 1 mistake somewhere will make your whole application stuck and then you must locate which call is blocking.

Re: Flattening Rust’s learning curve

#197

Post by imtringued »

psychoslave wrote: post #116
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…

This explanation doesn't expose anything meaningful to my mind, as it doesn't define ownership and borrowing, both words being apparently rooted in an analogy with financial asset management. I'm not acquainted with Rust, so I don't really know, but I wonder if the wording plays a role in the difficulty of concept acquisition here. Analogies are often double edged tools. Maybe sticking to a more straight memory relat…

You think borrowing a lawn mower or owning a power drill is financial asset management?

Re: Flattening Rust’s learning curve

#198

Post by conorjh »

psychoslave wrote: post #131
LAC-Tech wrote: post #90

Earlier quoted context omitted.

It's just a programming language, not a religion.

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

Re: Flattening Rust’s learning curve

#200

Post by GenshoTikamura »

> Stop resisting. That’s the most important lesson

> Accept that learning Rust requires...

> Leave your hubris at home

> Declare defeat

> Resistance is futile. The longer you refuse to learn, the longer you will suffer

> Forget what you think you knew...

Now it finally clicked to me that Orwell's telescreen OS was written in Rust

Post reply on HN