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

331–340 of 405 posts

Re: Flattening Rust’s learning curve

#331

Post by steveklabnik »

the__alchemist wrote: post #310

I seem to have eased into a rust programming style that dodges these, perhaps at the cost of some optimizations. Using the first example, for example (The article suggests this): Don't return an `&str`; use those for transient things only like function parameters; not for struct fields or returned types. I'm starting to wonder what I'm missing out by doing this. Not addressed in the article: Any tips for using the mo…

> I'm starting to wonder what I'm missing out by doing this.

It depends. In some cases, you aren't missing anything. In others, you may lose a bit of efficiency by doing some otherwise un-needed copying. Depending on what you're doing that may be irrelevant.

> Any tips for using the more abstract features, like Cow etc? I hit a problem with this today, where a lib used Cow instead of String, and the lifetime errors bubbled up into my code.

You can do the same thing as you do with &str by calling into_owned on the Cow, you'd get a String back.

Re: Flattening Rust’s learning curve

#332

Post by zahlman »

nmeofthestate wrote: post #276

"You will have a much better time if you re-read your code to fix stupid typos before pressing “compile.”" This is a strange one - I thought the rust compiler had famously helpful error messages, so why would I want to pore over my code looking for stupid typos when I can let the compiler find them for me? I am guaranteed to make stupid typos and want the computer to help me fix them.

Because if you're "guaranteed to make stupid typos" and you don't have the habit of repeatedly trying again after small changes (which becomes harder to establish when compilation takes longer), then you're likely to make multiple stupid typos at a time. And if you check for them yourself first, you have a decent chance to catch and fix several at a time - whereas it's often not the brightest idea to try to respond to multiple compiler errors at a time, no matter how helpful they are.

Re: Flattening Rust’s learning curve

#333

Post by ModernMech »

zahlman wrote: post #312
ModernMech wrote: post #256

Earlier quoted context omitted.

IME teaching students Rust, knowing C++ first actually is a detriment to learning because they have a bunch of C++ habits to unlearn. Those students "fight the borrow checker" much more than the blank slate students, because they have some idea about how code "should" be written.

Is this still true if they never learned pre-modern C++ and are accustomed to using all the std::foo_ptrs and expecting the rule of 3 (or 5) to be taken care of automatically that way?

The prereq for my Rust course is Java, but there are three kinds of students who come to me:

1) those who only know java

2) those who know java and were taught C++ by me. The way I teach that course, they are very familiar with pre-modern C++ because we also learn C.

3) those who know java and C++ but they learned it on their own.

It's the last group who has the most trouble. IME the exact issue they struggle with is the idea of shared mutable state. They are accustomed to handing out pointers to mutable state like candy, and they don't worry about race conditions, or all the different kinds of memory errors that can occur and lead to vulnerabilities. They don't write code that is easily refactored, or modular. They have a tendency to put everything into a header or one main.cpp file because they can't really get their head around the linking errors they get.

So when they try to write code this way in Rust, the very first thing they encounter is a borrow error related to their liberal sharing of state, and they can't understand why they can't just write code the way they want because it had been working so well for them before (in their very limited experience).

Pedagogically what I have to do is unteach them all these habits and then rebuild their knowledge from the ground up.

Re: Flattening Rust’s learning curve

#334

Post by School-Cotton »

tuetuopay wrote: post #215
scotty79 wrote: post #179

Earlier quoted context omitted.

Nah. &str is const char* exactly. It's as primitive as types in rust get.

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

Re: Flattening Rust’s learning curve

#335

Post by neonsunset »

Const-me wrote: post #328
dwattttt wrote: post #227

Earlier quoted context omitted.

It does sound like quite a similar model; unsafe Rust in self contained regions, safe in the majority of areas. FWIW in the case where you're not separating code via a dynamic library boundary, you give the compiler an opportunity to optimise across those unsafe usages, e.g. inlining opportunities for the unsafe code into callers.

> quite a similar model Yeah, and that model is rather old: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule In practice, complex software systems have been written in multiple languages for decades. The requirements of performance-critical low-level components and high-level logic are too different and they are in conflict. > you give the compiler an opportunity to optimise across those unsafe usages One worka…

> LTO

On some workloads (think calls not possible to inline within a hot loop), I found LTO to be a requirement for C code to match C# performance, not the other way around. We've come a long way!

(if you ask if there are any caveats - yes, JIT is able to win additional perf. points by not being constrained with SSE2/4.2 and by shipping more heavily vectorized primitives OOB which allow doing single-line changes that outpace what the average C library has access to)

Re: Flattening Rust’s learning curve

#336

Post by zahlman »

ajross wrote: post #324
zahlman wrote: post #317

Earlier quoted context omitted.

> 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. "Flattening the learning curve" is perhaps a wrong metaphor - you can't actually change what needs to be learned; you can only make it easier to learn. Saying something that is usually right and can be corrected later is a standard pedagogical approach - see https://en.wikipedi…

It's not "usually right" though. Rust can't compile a doubly-linked list[1] without unsafe! And people trip over this immediately when they start writing Rust, because that kind of code is pervasive in other environments. Thus statements like "Rust just doesn't like dangling pointers" are unhelpful, because while it's true it's not sufficient to write anything but the most trivial code. [1] Or basically any graph-lik…

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.

Re: Flattening Rust’s learning curve

#337

Post by zahlman »

ModernMech wrote: post #333
zahlman wrote: post #312

Earlier quoted context omitted.

Is this still true if they never learned pre-modern C++ and are accustomed to using all the std::foo_ptrs and expecting the rule of 3 (or 5) to be taken care of automatically that way?

The prereq for my Rust course is Java, but there are three kinds of students who come to me: 1) those who only know java 2) those who know java and were taught C++ by me. The way I teach that course, they are very familiar with pre-modern C++ because we also learn C. 3) those who know java and C++ but they learned it on their own. It's the last group who has the most trouble. IME the exact issue they struggle with is…

> So when they try to write code this way in Rust, the very first thing they encounter is a borrow error related to their liberal sharing of state, and they can't understand why they can't just write code the way they want because it had been working so well for them before (in their very limited experience).

Ah, well, a shame they didn't see the failing tests for the C++ code first ;)

Re: Flattening Rust’s learning curve

#338

Post by rat87 »

rafram wrote: post #82
rat87 wrote: post #75

Earlier quoted context omitted.

its not design by committee its design by Pull request It doesn't have a central https://en.wikipedia.org/wiki/Benevolent_dictator_for_life like python used to so people suggest and implement features as a group, with code counting for a lot (although theoretical issues with safety/design also matter) as opposed to companies arguing for their pet features endlessly without much difference. Look at how long it takes C…

> Look at how long it takes C++ to get any new features. I’m not sure “it doesn’t have enough features” has ever been anyone’s complaint about C++.

There are definitely some c++ features that some people have been clamoring for for over a decade

Pattern matching for one(although to be fair that's been in rust from the start)

Re: Flattening Rust’s learning curve

#339

Post by mkaic »

Oreb wrote: post #168
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.

Have you had a look at Nim? I think you may like it.

I love the look and feel of Nim, but found it to be stuck in a weird chicken-and-egg situation where it didn't have enough of a following to have a Convenient Package For Everything, ultimately turning me off it. Of course I recognize that the only way a language gets a Convenient Package For Everything is if it gets popular, but still...

Re: Flattening Rust’s learning curve

#340

Post by quietbritishjim »

dgfitz wrote: post #296
hbn wrote: post #266

Earlier quoted context omitted.

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.

But you can't add 2 void pointers and seamlessly get integer addition if they point at integers or concatenation if they point at strings.

(You could build your own custom data types that have type metadata in a shared header and an addition function that uses it, but then you're building your own custom language on top which isn't really the same thing.)

So yes C really does restrict you in some ways that Javascript doesn't.

Post reply on HN