Live data from Hacker News

Flattening Rust’s learning curve

corrode.dev

231–240 of 405 posts

Re: Flattening Rust’s learning curve

#231
post #69

Earlier quoted context omitted.

The second bullet in the second section is overpromising badly. In fact there are many, many, many ways to write verifiably correct code that leaves no dangling pointers yet won't compile with rustc. Frankly most of the complexity you're complaining about stems from attempts to specify exactly what magic the borrow checker can prove correct and which incantations it can't.

A great teaching technique I learned from a very good match teacher is that when explaining core concepts, the simplified definitions don't need to be completely right. They are much simpler to grasp and adding exceptions to these is also quite easy compared to trying to understand correct, but complex, definitions at the beginning.

Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite.

That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.

Re: Flattening Rust’s learning curve

#232

Earlier quoted context omitted.

C is elegant because as an extremely powerful programming language used to create an uncountable number of high-profile projects it's simple enough that I feel optimistic I could write a C compiler myself if it was really necessary. It may be impractical for some tasks but the power:complexity rate is very impressive. Lua feels similar in that regard.

The mechanism for sharing definitions, 'include' aka "copy file here", is absolutely not elegant. The absolute minimum you could do maybe, but not elegant.

Not to mention the whacky preprocessor as a whole...

I would say includes/standard library/compilers going crazy on UB is part of the infrastructure or ecosystem around the language and not the language itself. And I agree absolutely, while C the language is beautiful, the infra around it is atrocious.

Re: Flattening Rust’s learning curve

#233
post #231

Earlier quoted context omitted.

A great teaching technique I learned from a very good match teacher is that when explaining core concepts, the simplified definitions don't need to be completely right. They are much simpler to grasp and adding exceptions to these is also quite easy compared to trying to understand correct, but complex, definitions at the beginning.

Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.

Ironically, most people understand "learning curves" counterintuitively.

If a "learning curve" is a simple X-Y graph with "time" and "knowledge" being on each axis respectively, then what sort of learning curve is preferable: a flatter one or a steep one?

Clearly, if you graph large increases of knowledge over shorter periods of time, a steeper learning curve is more preferable. "Flattening the learning curve" makes it worse!

But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out.

Re: Flattening Rust’s learning curve

#234
These replies mainly revealed to me the general response people have on being corrected. Its very easy to become a stubborn programmer after being in the industry for so long.

I'd advise these people to personally figure out why they're so against compiler suggestions. Do you want to do things differently? What part stops you from doing that?

Re: Flattening Rust’s learning curve

#235
post #33

Earlier quoted context omitted.

It’s completely overblown. Almost every language with async has the same “problem”. I’m not calling this the pinnacle of async design, but it’s extremely familiar and is pretty good now. I also prefer to write as much async as possible.

The "function color is a problem" people invented a construct that amplifies the seriousness. It's not really a big deal.

My biggest issue with the whole "function colour" thing is that many functions have different colours. Like, these two:

    fn foo() -> String
    fn bar() -> Result
I can't just treat `bar` the same as `foo` because it doesn't give me a String, it might have failed to give me a String. So I need to give it special handling to get a String.

    async fn qux() -> String
This also doesn't give me a String. It gives me a thing that can give me a String (an `impl Future`, to be more specific), and I need to give it special handling to get a String.

All of these function have different colours, and I don't really see why it's suddenly a big issue for `qux` when it wasn't for `bar`.

Re: Flattening Rust’s learning curve

#236
post #210
post #132

Earlier quoted context omitted.

Maybe people need persuading to learn Rust not just because they think it's hard, but also because they think it's bad? Not everything hard is worth doing. Difficulty is just one of the factors to consider. I started to learn Rust, but I was put off by the heavy restrictions the language imposes and the attitude that this is the only safe way. There's a lack of acknowledgement, at least in beginner materials, that by…

The thing is, if you want to learn Rust this site contains good advice on how to do it. I know, because I learned Rust. Rust isn't a language you should pick up if you're not ready to put in the work. Just like you shouldn't go for full blown automotive grade C coding if you just want to learn coding quickly to get a job or something. Rust has a steep learning curve, but the harder part (as mentioned in the article)…

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.

Re: Flattening Rust’s learning curve

#237
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…

It does not teach you any fundamental lessons about correctness. It teaches you lessons about correctness within the framework Rust imposes; that's all

Re: Flattening Rust’s learning curve

#238
Sorry, but it's easier to learn basic C++/C, and let beginner developers get lessons from a basic linter or clang-tidy for about the same result, for a fraction of the developer cost.

I want rust to be adopted and I believe companies should force it, but you will not get adoption from young developers and even less from senior C++ developers.

Not to mention rewriting existing C++ code in rust, which cost would be astronomical, although I do believe companies should invest in rewriting things in rust because it's the right thing to do.

Re: Flattening Rust’s learning curve

#239

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

CVE is not only for memory leak though, while eliminating (or even drastically reducing) such a class of issue is a fair point to advertise, it should not be confused as a magic safety facility that makes go away any security concern.

Re: Flattening Rust’s learning curve

#240
post #130

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

If you're writing purely safe code, I will say this is true in a practical sense, but you can almost always use unsafe to write whatever you think rust won't let you do.

Post reply on HN