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

81–90 of 405 posts

Re: Flattening Rust’s learning curve

#81

Post by MeetingsBrowser »

dmitrygr wrote: post #74
worik wrote: post #71

Earlier quoted context omitted.

I am working on a code base, that among its many glories and poo balls every list is a doubly linked list. Stop! If you are using a doubly linked list you (probably) do not have to, or want to. There is almost no case where you need to traverse a list in both directions (do you want a tree?) A doubly linked list wastes memory with the back links that you do not need. A singly linked list is trivial to reason about: T…

> There is almost no case where you need to traverse a list in both directions But you might need to remove a given element that you have a pointer to in O(1), which a singly linked list will not do

Getting the pointer to that element means randomly hopping around the heap to traverse the list though.

Linked lists are perfect for inserting/deleting nodes, as long as you never need to traverse the list or access any specific node.

Re: Flattening Rust’s learning curve

#82

Post by rafram »

rat87 wrote: post #75
LAC-Tech wrote: post #56

Earlier quoted context omitted.

I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.

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

Re: Flattening Rust’s learning curve

#83

Post by cozzyd »

LambdaComplex wrote: post #23
ants_everywhere wrote: post #16

A learning curve measures time on the x axis and progress on the y axis. A flat learning curve means you never learn anything :-\

"Flattening the derivative of Rust's learning curve" really doesn't roll off the tongue though

A steep line still has a flat derivative

Re: Flattening Rust’s learning curve

#84

Post by cadamsdotcom »

gerdesj wrote: post #34
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…

"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 people can learn more about correctness!

I’ll concede- “everyone” was too strong; I erred on the side of overly provocative.

Re: Flattening Rust’s learning curve

#85

Post by Const-me »

jandrewrogers wrote: post #58
sesm wrote: post #37

Is there a concise document that explains major decisions behind Rust language design for those who know C++? Not a newbie tutorial, just straight to the point: why in-place mutability instead of other options, why encourage stack allocation, what problems with C++ does it solve and at what cost, etc.

Rust has better defaults for types than C++, largely because the C++ defaults came from C. Rust is more ergonomic in this regard. If you designed C++ today, it would likely adopt many of these defaults. However, for high-performance systems software specifically, objects often have intrinsically ambiguous ownership and lifetimes that are only resolvable at runtime. Rust has a pretty rigid view of such things. In thes…

Interestingly, CPU-bound high-performance systems are also incompatible with Rust’s model. Ownership for them is unambiguous, but Rust has another issue, doesn’t support multiple writeable references of the same memory accessed by multiple CPU cores in parallel.

A trivial example is multiplication of large square matrices. An implementation needs to leverage all available CPU cores, and a traditional way to do that you’ll find in many BLAS libraries – compute different tiles of the output matrix on different CPU cores. A tile is not a continuous slice of memory, it’s a rectangular segment of a dense 2D array. Storing different tiles of the same matrix in parallel is trivial in C++, very hard in Rust.

Re: Flattening Rust’s learning curve

#87

Post by rafram »

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.

Not to mention that even though you can always refactor later, will you really? It’s much easier not to.

In my experience, hobbyist Rust projects end up using unwrap and panic all over the place, and it’s a giant mess that nobody will ever refactor.

Re: Flattening Rust’s learning curve

#88

Post by mikepurvis »

bloppe wrote: post #35
ameliaquining wrote: post #20

Earlier quoted context omitted.

Summarizing a set of concepts in a way that feels correct and complete to someone who understands them, is a much easier task than explaining them to someone who doesn't. If we put this in front of someone who's only worked with call-by-sharing languages, do you think they'll get it right away? I'm skeptical.

For me it really clicked when I realized ownership / lifetimes / references are just words used to talk about when things get dropped. Maybe because I have a background in C so I'm used to manual memory management. Rust basically just calls 'free' for you the moment something goes out of scope. All the jargon definitely distracted me from grasping that simple core concept.

"Rust basically just calls 'free' for you the moment something goes out of scope."

C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it.

The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fact that those supposedly stack-allocated containers are in fact allocating heap objects behind your back, and b) you cooperating with the restrictions given in the API docs, agreeing not to hold pointers to the member objects or do weird things with casting. You can use scoped_ptr/unique_ptr but the whole time you'll be painfully aware of how it's been bolted onto the language later and whenever you want you can call get() on it for the "raw" underlying pointer and use it to shoot yourself in the foot.

Rust formalizes this protection and puts it into the compiler so that you're prevented from doing it "wrong".

Re: Flattening Rust’s learning curve

#89

Post by rvz »

mdwhatcott wrote: post #42

[flagged]

Maybe Rust is so complex, it is even more complex for an LLM to generate correct code (one-shot) without hallucinating non-existent functions.

Would rather have that than all the issues that JavaScript or any other weakly typed and dynamically typed language.

Re: Flattening Rust’s learning curve

#90

Post by LAC-Tech »

worik wrote: post #68
LAC-Tech wrote: post #56

Earlier quoted context omitted.

I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.

There is a trade off. Rust gave us fast, and safe. It did not give us "easy to learn". I think it is a very good example of why "design by committee" is good. The "Rust Committee" has done a fantastic job Thank you They say a camel is a horse designed by a committee ( https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_b... ) Yes: * Goes twice as far as a horse * On half the food and a quarter the water of a h…

It's just a programming language, not a religion.
Post reply on HN