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

381–390 of 405 posts

Re: Flattening Rust’s learning curve

#381

Post by int_19h »

cmrdporcupine wrote: post #301
echelon wrote: post #280

Earlier quoted context omitted.

Programmers new to Rust, you mean. It's kind of like career Java programmers using JavaScript or Python for the first time and bringing their way of doing things.

It's more than that. Rust's value & reference passing semantics are completely different from the way most programmer's have trained their entire lives to think about it. When you pass an argument to a function in Rust, or assign a value into a struct or variable, etc. you are moving it (unless it's Copy). That's extremely different from any other programming language people are used to, where things are broadly pass…

I think sometimes that there's a niche for an alternative syntax for Rust that is generally more verbose (keywords instead of punctuation etc), and which specifically makes this behavior explicit. In other words, for every argument of every call you'd have to write "move" or "copy" and similarly with assignments etc.

Re: Flattening Rust’s learning curve

#382

Post by int_19h »

zahlman wrote: post #359
ajross wrote: post #347

Earlier quoted context omitted.

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 obser…

You should try picking up Rust, and then, based on your Python experience, see how quickly you run into one of those cases that GP is talking about. It's unlikely to take long.

Re: Flattening Rust’s learning curve

#383

Post by int_19h »

3vidence wrote: post #375
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 still haven't gotten into rust yet, mostly due to time and demand, but, I have been doing a lot of C++ in the past few years. Coming from that background these rules sound fantastic, theres been a lot of work put into c++ the past few years to try and make these things easier to enforce but it's still difficult to do right even with smart pointers.

The main problem is that a lot of things that are correct wrt lifetimes will still not compile because the borrow checker can't prove that they are correct. Even for fairly trivial stuff sometimes, like trees with backlinks.

Re: Flattening Rust’s learning curve

#384

Post by int_19h »

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.

Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases.

Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.

Re: Flattening Rust’s learning curve

#385

Post by int_19h »

0x000xca0xfe wrote: post #217
krior wrote: post #175

Earlier quoted context omitted.

C may be simple, but its too simple to be called elegant. The lack of namespacing comes to mind. Or that it is a staticly typed language, whose type system is barely enforced (you have to declare all types, but sometimes it feels like everything decays to int and *void without the right compiler incantations). Or the build system, where you have to learn a separate language to generate a separate language to compile…

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.

Modula-2 is elegant. C is hacked together. Both have equal power and mostly map 1:1, but design matters. Writing a Modula compiler would be easier.

Re: Flattening Rust’s learning curve

#386

Post by int_19h »

akewovtsn wrote: post #148
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

Python community famously learned the hard way that sometimes the programmer needs to know that there are multiple kinds of string. Personally, I’ve been using to_owned instead. Some of the people looking at my code don’t write rust, and I figure it makes things a bit easier to understand.

Modern Python has a single type of string.

What used to be called "string" in Python 2 is no longer called that, precisely so as to avoid unnecessary confusion. It's called "bytes", which is why the question of "why do I have to convert it to string?" doesn't arise.

Re: Flattening Rust’s learning curve

#387

Post by int_19h »

swiftcoder wrote: post #194
SkiFire13 wrote: post #134

Earlier quoted context omitted.

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

I can't think of many languages that differentiate between #1 and #2 in your list. And languages that differentiate between #1 and #3 generally don't refer to #1 as "strings" at all, so you still have a single definitive notion of what a string is (and some other things that are emphatically not strings).

Re: Flattening Rust’s learning curve

#388

Post by int_19h »

darthrupert wrote: post #185
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

On the other side where this question is not asked we have things like > "1" + 2 3 And it's utter madness that everyone does anything important with languages like that.

  Python 3.11.12 (main, Apr  8 2025, 14:15:29) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> "1" + 2
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: can only concatenate str (not "int") to str

Re: Flattening Rust’s learning curve

#389

Post by int_19h »

kaoD wrote: post #159
ajross wrote: post #67

> Use String and clone() and unwrap generously; you can always refactor later At that point you might as well be writing Java or Go or whatever though. GC runtimes tend actually to be significantly faster for this kind of code, since they can avoid all those copies by sharing the underlying resource. By the same logic, you can always refactor the performance-critical stuff via your FFI of choice.

> At that point you might as well be writing Java or Go or whatever though. And miss Option, Result, proper enums, powerful pattern matching, exhaustive pattern matching, affine types, traits, doctests... and the many other QoL features that I sorely miss when I drop to e.g. TS/Node. I'm not using Rust for the borrow checker, but it's nice to have when I need it to hold my hand and not that much of an issue when I do…

F#, then?

Re: Flattening Rust’s learning curve

#390

Post by swiftcoder »

int_19h wrote: post #387
swiftcoder wrote: post #194

Earlier quoted context omitted.

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

I can't think of many languages that differentiate between #1 and #2 in your list. And languages that differentiate between #1 and #3 generally don't refer to #1 as "strings" at all, so you still have a single definitive notion of what a string is (and some other things that are emphatically not strings).

Yeah, a bunch of languages don't strongly differentiate between all three of these.

For example, C++ differentiates between #1 and #2 (although it has woefully inadequate out-of-box support for #3).

Python (> 3) calls #1 bytes / bytearray, and calls #3 string. #2 is only really supported for FFI with C (i.e. ctypes.c_char_p and friends)

Post reply on HN