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

291–300 of 405 posts

Re: Flattening Rust’s learning curve

#291

Post by toprerules »

ModernMech wrote: post #271
greazy wrote: post #220

Earlier quoted context omitted.

> it has widely used macros that obfuscate a lot of things that further adds to the complexity. This is what's stumped me when learning Rust. It could be the resources I used, whixh introduced macros early on with no explanation.

Macros are introduced early in Rust for a couple reasons. 1. println!() is a macro, so if you want to print anything out you need to grapple with what that ! means, and why println needs to be a macro in Rust. 2. Macros are important in Rust, they're not a small or ancillary feature. They put a lot of work into the macro system, and all Rust devs should aspire to use and understand metaprogramming. It's not a languag…

Hard disagree, macros almost always lead the "too clever for you own good" even when the macro system is safe. Macros should always be used sparingly, and I think that Rust teeters on the edge of encouraging too much complexity for the sake of convenience. As a systems programmer I am allergic to unnecessary levels of indirection that make it more difficult for me to reason about what the system is actually doing and how performance and hardware interaction will be affected.

Re: Flattening Rust’s learning curve

#292

Post by namuol »

vacuity wrote: post #284
namuol wrote: post #102

Earlier quoted context omitted.

> Everyone should learn Rust. I know this feels like a positive vibe post and I don’t want to yuck anyone’s yum, but speaking for myself when someone tells me “everyone should” do anything, alarm bells sound off in my mind, especially when it comes to programming languages.

I think everyone should learn many different programming languages, because being exposed to different paradigms helps develop programming skill.

Yeah I agree, I enjoy the process. I don’t think that’s what’s behind “everyone should learn rust” in this case, and many cases. It feels like a “cause”.

Re: Flattening Rust’s learning curve

#293

Post by umajho »

steveklabnik wrote: post #273
umajho wrote: post #169

> …. For instance, “a trait is a bit like an interface” is wrong, … Wait. What's wrong with this statement?

I think this is just a mistake, in that “a bit like” is correct. The ways in which it are different depend on which language you are taking the concept of “interface” from, but the statement that it’s like one is accurate.

That makes sense.

Re: Flattening Rust’s learning curve

#294

Post by devnullbrain »

wepple wrote: post #192
make3 wrote: post #183

Earlier quoted context omitted.

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

>and then access the data at that location

Or many other locations, by many other authors, at many other times, or simultaneously.

Re: Flattening Rust’s learning curve

#295

Post by devnullbrain »

woah wrote: post #4

Does anyone still have trouble learning Rust? I thought that was kind of a 2015 thing

It's very flattering! It's perhaps the only time in internet computing circles where I repeatedly see people argue in a way that boils down to:

'I'm not as good as learning things at you'

Re: Flattening Rust’s learning curve

#296

Post by dgfitz »

hbn wrote: post #266
rikafurude21 wrote: post #252

Earlier quoted context omitted.

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?

I believe you can do that in C pretty easily with a void pointer, someone correct me if I'm mistaken.

Should you? Different question entirely.

Re: Flattening Rust’s learning curve

#297

Post by notnullorvoid »

echelon wrote: post #7
Havoc wrote: post #5

I thought it was quite manageable at beginner level…though I haven’t dived into async which I gather is a whole different level of pain

Async and the "function color" "problem" fall away if your entire app is in an async runtime. Almost 90% of the Rust I write these days is async. I avoid non-async / blocking libraries where possible. I think this whole issue is overblown.

Agreed. Function coloring is a solution (not a problem), one that's better than the alternatives.

The "function coloring problem" people are harming entire ecosystems. In JS for example there are very popular frameworks thay choose to wrap async in sync execution by throwing when encountering async values and re-running parts of the program when the values resolve. The crazy part with these solutions trying to remove coloring, is they don't, they hide it (poorly). So instead of knowing what parts of a program are async you have no idea.

Re: Flattening Rust’s learning curve

#298

Post by adastra22 »

Hackbraten wrote: post #279
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…

I think your comment has received excellent replies. However, no one has tackled your actual question so far: > _who_ is the owner. Is it a stack frame? I don’t think that it’s helpful to call a stack frame the owner in the sense of the borrow checker. If the owner was the stack frame, then why would it have to borrow objects to itself? The fact that the following code doesn’t compile seems to support that: fn main()…

I believe this answer is correct. Ownership exists at the language level, not the machine level. Thinking of a part of the stack or a piece of memory as owning something isn’t correct. A language entity, like a variable, is what owns another object in rust. When that object goes at a scope, its resources are released, including all the things it owns.

Re: Flattening Rust’s learning curve

#299

Post by devnullbrain »

jillesvangurp wrote: post #140

Rust has a few big hurdles for new users: - it's very different from other languages. That's intentional but also an obstacle. - it's a very complex language with a very terse syntax that looks like people are typing with their elbows and are hitting random keys. A single character can completely change the meaning of a thing. And it doesn't help that a lot of this syntax deeply nested. - a lot of its features are ha…

>it's very different from other languages. That's intentional but also an obstacle.

It's very different from a lot of the languages that people are typically using, but all the big features and syntax came from somewhere else. See:

>The type system and the borrowing mechanism are good examples. Unless you are a type system nerd a lot of that is just gobblygook to the average Python or Javascript user.

Well, yeah, but they generally don't like types at all. You won't have much knowledge to draw on if that's all you've ever done, unless you're learning another language in the same space with the same problems.

Re: Flattening Rust’s learning curve

#300

Post by winrid »

Const-me wrote: post #125
winrid wrote: post #113

Earlier quoted context omitted.

Hard in safe rust. you can just use unsafe in that one area and still benefit in most of your application from safe rust.

I don’t use C++ for most of my applications. I only use C++ to build DLLs which implement CPU-bound performance sensitive numeric stuff, and sometimes to consume C++ APIs and third-party libraries. Most of my applications are written in C#. C# provides memory safety guarantees very comparable to Rust, other safety guarantees are better (an example is compiler option to convert integer overflows into runtime exception…

I would definitely rather use C# or java in a GUI app, yes.
Post reply on HN