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

281–290 of 405 posts

Re: Flattening Rust’s learning curve

#281

Post by coldpie »

jmull wrote: post #267

I'm not sure there are many cases where I would choose rust. I'm open to it. I just think in any given situation there would most likely be a better option. Perhaps it will become prevalent enough that it will make sense in the future.

It's the best fit I'm aware of for any task where correctness is worth the dev time hit. That includes systems programming tasks, where you're shuffling memory and files and system resources around and an error could kill your program or corrupt resources; or as a library for critical parts of your program, which could then provide an interface for other languages to use that allow for faster development & prototyping.

Re: Flattening Rust’s learning curve

#282

Post by steveklabnik »

swiftcoder wrote: post #278
steveklabnik wrote: post #265

Earlier quoted context omitted.

They mean in Safe Rust. Unsafe is included in Rust for this reason.

Is safe rust not Turing complete? I can see the argument that a purist "safe rust only" program might be slow, but it still will be expressible

Turning completeness doesn’t take efficiency into account, nor the reality of things like “call into the operating system so that you can display output” that are necessary when building real systems.

Re: Flattening Rust’s learning curve

#283

Post by vacuity »

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.

I think Java pointers wouldn't count as raw pointers despite having many similar characteristics.

Re: Flattening Rust’s learning curve

#284

Post by vacuity »

namuol wrote: post #102
cadamsdotcom wrote: post #26

Rust is wonderful but humbling! It has a built in coach: the borrow checker! Borrow checker wouldn't get off my damn case - errors after errors - so I gave in. I allowed it to teach me - compile error by compile error - the proper way to do a threadsafe shared-memory ringbuffer. I was convinced I knew. I didn't. C and C++ lack ownership semantics so their compilers can't coach you. Everyone should learn Rust. You nev…

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

Re: Flattening Rust’s learning curve

#285

Post by icedchai »

yodsanklai wrote: post #145
namuol wrote: post #101

Earlier quoted context omitted.

Sure, C++ has a more complex spec, nobody can argue against that. Complex is the wrong word. Baffling is a better word. Or counterintuitive, or cumbersome. If “easy enough for someone with experience in C++, OCaml, Haskell, and F#” were the same thing as “not hard” then I don’t think this debate would come up so frequently.

Of course, this is very subjective. For someone who only knows python or javascript at a superficial level, Rust may seem out of reach. But if you're ok with the most common programming paradigms, I don't find Rust baffling. I mean, you can't expect to learn a new language in a few days, it'll always take a bit of work. My feeling is that people complaining of the language being hard aren't putting the effort. My exp…

C++ is a huge and complex language. I worked in it, on and off, from 2002 through 2014 or so and never really felt comfortable, either. Everyone seems to use their own dialect.

(I'm working on learning Rust on my free time.)

Re: Flattening Rust’s learning curve

#286

Post by toprerules »

jmull wrote: post #267

I'm not sure there are many cases where I would choose rust. I'm open to it. I just think in any given situation there would most likely be a better option. Perhaps it will become prevalent enough that it will make sense in the future.

As systems programmer there are no better options. C is inherently unsafe, C++ is awful to work with and unsafe without careful use of pre-made safe abstractions that can't catch everything at runtime...

I have written C for decades and love the language, but Rust has convinced me that we need to evolve beyond the 70s. There's no excuse anymore.

Re: Flattening Rust’s learning curve

#287

Post by toprerules »

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 of an array, etc. But they might "feel" like they are doing great because there program compiles and sort of runs.

If you have already gotten to the journeyman or mastery experience level with C or C++ Rust is going to be easy to learn (it was for me). The concepts are simply being made explicit rather than implicit (ownership, lifetimes, traits instead of vtables, etc).

Re: Flattening Rust’s learning curve

#288

Post by ajross »

pkolaczk wrote: post #201
ajross wrote: post #100

Earlier quoted context omitted.

> Cloning small objects is lightning fast It's really not, it's the way python works. Heap allocations are "fast" on modern CPUs that are too fast to measure for most stuff, but they're much (much) slower than the function call and code you're going to use to operate on whatever the thing it was you cloned. Code that needs memory safety and can handle performance requirements like this has many options for source lan…

Cloning doesn’t imply heap allocation. Depends on the type.

If the object had a stack-bounded lifetime, the borrow checker would have been able to prove the analysis though. The advice is to clone things it can't, which pretty much requires that it go into the general heap. I'm sure there are some interesting counterexamples, but the situation you're imagining seems kinda academic.

Re: Flattening Rust’s learning curve

#289

Post by namuol »

Waterluvian wrote: post #222
namuol wrote: post #103

Earlier quoted context omitted.

I’ve found emulators to be a pretty poor first project for rust specifically for the reasons you alluded to: That you need to know to write it without heap allocation (or other hoop jumping so long as you avoid juggling lifetimes) when so much literature and example emulator code doesn’t do this is a recipe for a bad experience. Ask me how I know. If you’re going to write an emulator in this style, why even use an im…

These emulators already exist in basically every language, so why do anything? The point is the journey, which doesn’t need to be the shortest, most optimal path possible.

I’m saying it’s not optimal for learning the language, not that it’s not worth doing. I’ve worked on 3 different emulators for fun over the last few years, my first in rust. It was a bad experience for learning rust because I was following prior art which relied heavily on shared data structures and lots of poking randomly at blocks of RAM, a very natural way to think when you’re engrossed in the mechanics of an 8-bit CPU.

I had a better time writing a raycaster and later a path tracer, although by then I had learned to avoid dealing with the borrow checker…

Re: Flattening Rust’s learning curve

#290

Post by melodyogonna »

dsego wrote: post #242
melodyogonna wrote: post #141

Earlier quoted context omitted.

Rust design decisions are pretty hard to understand sometimes, Mojo is another language with a borrow-checker but it is not nearly as hard to learn as Rust due to making a few decisions. First is value semantics, in Rust people are told to always clone when learning, why isn't this semantics built into the language? It is what you have in most static languages - C, C++, Go, etc. This is the mental model many people c…

> but values will be destroyed immediately after their last use Is this reference counting?

Nah, deterministic compiler analysis. Something they call ASAP memory management
Post reply on HN