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

351–360 of 405 posts

Re: Flattening Rust’s learning curve

#351

Post by syklemil »

TheChaplain wrote: post #164

My problem with rust is not the learning curve, but the absolute ugliness of the syntax. It's like Perl and C++ template metaprogramming had a child. I just can't stand it. Python is my favourite, C is elegance in simplicity and Go is tolerable.

There's no discussing taste, especially with syntax. Personally I find the Rust syntax unoffensive, while the Go syntax comes off kind of … weird, with type signatures especially looking kind of like run-on sentences by someone who hates punctuation. C's type signatures come off as a turgid mess to me; stuff like this https://www.ericgiguere.com/articles/reading-c-declarations.... is just a design mistake as far as I'm concerned. And Python … kind of goes into the "ah, I give up, slap an `Any` signature on it" territory.

And some people love that! It just ain't for everyone.

Re: Flattening Rust’s learning curve

#352

Post by prmph »

pessimizer wrote: post #323
prmph wrote: post #236

Earlier quoted context omitted.

I think one can understand Rust and still dislike it? Not every criticism of Rust comes from thinking it is too hard. I appreciate it for what it is and the problems it tries to solve. I just don't like many aspects of design of the language, seeing it as unnecessarily ugly for achieving it's aims.

I think the person you replied to never said "only people who do not understand Rust dislike it," or anything similar to that. Even pretending that they did, I don't know if "appreciat[ing]" Rust means that you're saying that you "understand" it. It seems like choosing a different word in the second sentence of a two sentence argument may be an subtle way of hinting that you don't know Rust, although you've read arti…

I'm not sure you fully grasp what I'm saying.

I'm seeking to draw a distinction between disliking rust for the real (or perceived) difficulty of learning/using it, and disliking it on principle, because you don't like it's trade-offs, approach to achieving it aims, syntax, type system, etc. This dichotomy is meaningful irrespective of the level of experience one has with Rust, beyond a certain level (and for the record I believe I have the requisite level of knowledge of rust to have an informed opinion on it).

For example, I don't know much Haskell. It seems to me (and to many other I read online) like it would be difficult to learn (and maybe use), although I'm familiar with functional languages in general. However, based on the little I've learned about it so far, it is a language I'd absolutely love to dig much deeper into as time permits, because almost everything about it makes so much sense to me.

Here's something amazing, I started to design my ideal language, before I started learning Haskell, and almost every language construct in Haskell I learn about seems to match exactly how I'd designed my language by coincidence (even down to keywords like "where", "do" blocks, etc.)

Re: Flattening Rust’s learning curve

#353

Post by RealityVoid »

toprerules wrote: post #287

As a systems programmer I found Rust relatively easy to learn, and wonder if the problem is non-systems programmers trying to learn their first systems language and having it explicitly tell them "no, that's dangerous. no, that doesn't make sense". If you ask a front end developer to suddenly start writing C they are going to create memory leaks, create undefined behavior, create pointers to garbage, run off the end…

As a low level programmer, my biggest pain with rust was the type system. More precisely the traits and the trait bounds.

I suspect if you have C++ experience it's simpler to grokk, but most of the stuff I wrote was C and a bunch of the stuff Rust did were not familiar to me.

Re: Flattening Rust’s learning curve

#354

Post by Someone »

kibwen wrote: post #206
frankie_t wrote: post #186

Earlier quoted context omitted.

Maybe it's my learning limitations, but I find it hard to follow explanations like these. I had similar feelings about encapsulation explanations: it would say I can hide information without going into much detail. Why, from whom? How is it hiding if I can _see it on my screen_. Similarly here, I can't understand for example _who_ is the owner. Is it a stack frame? Why would a stack frame want to move ownership to it…

> Why can mutable reference be only handed out once? Here's a single-threaded program which would exhibit dangling pointers if Rust allowed handing out multiple references (mutable or otherwise) to data that's being mutated: let mut v = Vec::new(); v.push(42); // Address of first element: 0x6533c883fb10 println!("{:p}", &v[0]); // Put something after v on the heap // so it can't be grown in-place let v2 = v.clone();…

> // Put something after v on the heap

> // so it can't be grown in-place

> let v2 = v.clone();

I doubt rust guarantees that “Put something after v on the heap” behavior.

The whole idea of a heap is that you give up control over where allocations happen in exchange for an easy way to allocate, free and reuse memory.

Re: Flattening Rust’s learning curve

#355

Post by steveklabnik »

Someone wrote: post #354
kibwen wrote: post #206

Earlier quoted context omitted.

> Why can mutable reference be only handed out once? Here's a single-threaded program which would exhibit dangling pointers if Rust allowed handing out multiple references (mutable or otherwise) to data that's being mutated: let mut v = Vec::new(); v.push(42); // Address of first element: 0x6533c883fb10 println!("{:p}", &v[0]); // Put something after v on the heap // so it can't be grown in-place let v2 = v.clone();…

> // Put something after v on the heap > // so it can't be grown in-place > let v2 = v.clone(); I doubt rust guarantees that “Put something after v on the heap” behavior. The whole idea of a heap is that you give up control over where allocations happen in exchange for an easy way to allocate, free and reuse memory.

That’s correct.

Re: Flattening Rust’s learning curve

#356

Post by steveklabnik »

kazinator wrote: post #342
kibwen wrote: post #206

Earlier quoted context omitted.

> Why can mutable reference be only handed out once? Here's a single-threaded program which would exhibit dangling pointers if Rust allowed handing out multiple references (mutable or otherwise) to data that's being mutated: let mut v = Vec::new(); v.push(42); // Address of first element: 0x6533c883fb10 println!("{:p}", &v[0]); // Put something after v on the heap // so it can't be grown in-place let v2 = v.clone();…

The analogous program in pretty much any modern language under the sun has no problem with this, in spite of multiple references being casually allowed. To have a safe reference to the cell of a vector, we need a "locative" object for that, which keeps track of v , and the offset 0 into v.

That’s a different implementation, and one you can do in Rust too.

Re: Flattening Rust’s learning curve

#357

Post by pdpi »

School-Cotton wrote: post #334
tuetuopay wrote: post #215

Earlier quoted context omitted.

Nope. `&str` includes the length of the slice, which `const char*` does not. `std::string_view` is the proper analogy.

Another difference is that &str is guaranteed to be utf-8, whereas const char* can be any encoding (or no encoding).

Also, &str is closer to const uint8_t* than it is to const char*. Chars are signed by default and are at least 8 bits, but can be wider.

Re: Flattening Rust’s learning curve

#358

Post by gerdesj »

cadamsdotcom wrote: post #84
gerdesj wrote: post #34

Earlier quoted context omitted.

"Rust is wonderful but humbling!" It's an abstraction and convenience to avoid fiddling with registers and memory and that at the lowest level. Everyone might enjoy their computation platform of their choice in their own way. No need to require one way nor another. You might feel all fired up about a particular high level language that you think abstracts and deploys in a way you think is right. Not everyone does. Yo…

@gerdesj your tone was unnecessarily rude and mean. Part of your message makes a valid point but it is hampered by unnecessary insults. I hope the rest of your day improves from here. I don’t specifically like Rust itself. And one doesn’t need a programming language to discover themselves. My experience learning Rust has been that it imposes enough constraints to teach me important lessons about correctness. Lots of…

"@gerdesj your tone was unnecessarily rude and mean."

"You" are not human.

Re: Flattening Rust’s learning curve

#359

Post by zahlman »

ajross wrote: post #347
zahlman wrote: post #336

Earlier quoted context omitted.

People write non-trivial code all the time without worrying about that sort of thing. Quite a lot can be done with plain tree structures. In the real world, your data is flat and even your conventions for interpreting it as non-flat (such as, say, JSON) only create trees that perhaps simulate back-links with another informal protocol.

Sigh. The whole premise of the linked article is, in fact, that people hit validation problems with the borrow checker early on when learning rust and that attention is needed to "flatten the learning curve" to assist their understanding of what we all agree is a unique and somewhat confusing set of semantics relative to competing languages. Rust flaming is just so terribly exhausting. No matter how reasonable and ob…

... Would it help you to know that I don't even use Rust (although I'm interested in picking it up), and in fact have complained on HN before about program performance and other features being invalidly attributed to "it's written in Rust"? Especially in the Python ecosystem, that being my primary programming language?

I'm not making anything like the argument you seem to think I am. I'm only making a pragmatic observation about what real-world coding is like, based on my own experience.

Re: Flattening Rust’s learning curve

#360

Post by yung_lean »

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…

In my experience, understanding the rules of the borrow checker is not enough to be able to write rust code in practice. For example, ~6 months into using rust I was stumped trying to move data out of a mutable reference. Trying to do this directly by dereferencing gives compiler errors like "cannot move out of `*the_ref` which is behind a mutable reference". If you know rust, you're probably either yelling "you idiot! you can't move out of mutable references!" or "you idiot! just use std::mem::take!" (the latter of course being the right way to do this) but that's not obvious from the borrow checker rules.

My experience learning rust has been like a death by 1000 cuts, where there's so many small, simple problems that you just have to run into in the wild in order to understand. There's no simple set of rules that can prepare you for all of these situations.

Post reply on HN