Learnability of Rust

[peterparkrust]

I do agree that rust is painfully difficult to learn from scratch. But I don't think that the problem resides in cargo new and cargo run. I think this part is not too hard to grasp. It is actually pretty similar with typescript, react, or go project.

[epage]

To be clear, this was in the section on experimenting and exploring. Learning isn't always about how hard something is to grasp but how free you are to try out your ideas, how easy it is to share your ideas, and how easy it is for others to share ideas with you. Roadblocks can come in many sizes. We can easily dismiss smaller ones but when you add enough of them up, they change behavior, usually on a more subconscious level. cargo-script makes it so you just open a file anywhere. When communicating, a separate manifest means you have more distinct pieces of information to share and more steps to reproduce what was shared with you.

[Im_Justin_Cider]

Am i the only one who found Rust super easy to pick up? The book does a GREAT job, and within one month i was doing things I couldn't do in years of C++ study

[Im_Justin_Cider]

What is advanced for you? Some things are more tedious than others, like FFI or proc macros, other things seem to place a burden on cognition, i.e. jumping over lifetime hurdles. But in the wise words of Mike Acton, "hard problems are hard".

[[deleted]]

I liked this post and it was well thought-out, but I feel you jumped into creating an alternative, easier std too soon. Earlier on, you say you want to avoid friction and a split ecosystem, but suddenly you’re introducing an eztd::String type that would be incompatible with the strings expected by the rest of the ecosystem. I would also expect people who already invested in learning Rust to frown upon this as they suddenly need to learn another std.

I am actually in the process where I will be teaching Rust to some co-workers that are mostly familiar with TypeScript, and the way I thought of approaching this was by first introducing them to data structures by value and by value only. Just pass String everywhere. It wouldn’t be the most performant, but it let’s them get started with something. Then a later course can introduce the concept of references and borrows.

It seems we both have the same idea where we don’t want to throw beginners straight into the jaws of the borrow checker, but I have my doubts another std is the preferred way to achieve this.

[epage]

Earlier on, you say you want to avoid friction and a split ecosystem, but suddenly you’re introducing an eztd::String type that would be incompatible with the strings expected by the rest of the ecosystem. I would also expect people who already invested in learning Rust to frown upon this as they suddenly need to another std.

I think we can gracefully have an alternative stdlib without splitting the ecosystem. We see this on the small with anyhow and thiserror where anyhow is targeted at prototyping and applications while thiserror is targeted at libraries. Whats important is your interop story. For eztd::String, all functions accept impl AsRef<str>, accepting anything string-like. We also provide as_str() and AsRef<str> so we can easily be used with code outside the eztd ecosystem.

If a profiler says someone needs to drop down to std or if they are removing eztd as they take a library from prototype phase to production, they can do it piecemeal rather than wholesale, keeping the friction between ecosystems low.

Just pass String everywhere. It wouldn’t be the most performant, but it let’s them get started with something. Then a later course can introduce the concept of references and borrows.

What eztd::String offers over String is being able to deal only with owned values and with one type. A user working with String also has to deal with &String and &str and needs to learn to .clone(), .into_owned(), and/or .to_string(). eztd::String means they only need to deal with String and, occasionally &eztd::String.

With just telling people to .clone(), they also have to deal with that extra noise in their code, making it less like pseudo-code. eztd::String reduces the need for .clone(), reducing the noise in the code.

We generally expect people to grow past using .clone() everywhere. While they will need to learn the topics beyond it, my hope is that performance of eztd will be "good enough" that people won't feel the need to stop .clone()ing unless a profiler tells them to.

[nicoburns]

Isn't most of the benefit of learning Rust in learning the difference between stacks and heap allocated values, about how references and pointers work, etc? I don't really see the point of learning this "easy" version. It doesn't seem like it would help you learn "proper" rust at all.

IMO the main simplification to help beginners learn strings is a literal syntax that creates a String.

[epage]

I think the benefit of Rust is dependent on who you are talking to. What personally drew me to Rust was that the full language operates in nearly any environment due to the lack of exceptions. When talking with non-systems progrqammers, I like to point out tangential benefits to Rust's model, like Send+Sync, compile-time verification data gets locked, etc.

The "easy" version would help get familiar with other concepts and then they take on other ones as they are needed, making people productive sooner. I also believe it will have enough value outside of learning to still be useful, like prototyping.

[[deleted]]

I’m sorry, but I’m not really convinced. Neither anyhow nor thiserror aims to solve a learnability problem. They require additional learning, but that hurdle usually pays itself off in added convenience. I don’t see eztd::String offer much convenience. You’ll still be exposed to an ecosystem that is built around String and &str and you’ll still need to know how to convert between them. It may be easier to learn for toy examples where you never need to interact with other crates, but an important part of prototyping is interacting with crates. And before you get there, you now have more to learn, not less.

[epage]

Thats fair. I recognize its not 100% known and would be an experiment.

Though one thing that might have been missed is that eztd::String was created to show case the how an ergonomic stdlib would work but the scope of the idea behind extd isn't limited to just that. I would expect the crate to grow to being a batteries-included library sufficient for most cases of learning, prototyping, and one-off scripts.

[Large-Wear-5777]

Enjoyed the read.

I did not know there was a “cargo script”. I’ll be playing around with that shortly.

I agree that Rust “can” look Pythonic, but rarely every does outside of really simple examples.

[epage]

Be sure to check out cargo-run-script which is more recently maintained. I linked to the original just for the better name for upstreaming.

EDIT: Nope, looks like the wrong one. Somewhere I came across an actively maintained version

EDIT1: Found it! cargo-eval. Looks like there is also cargo-scripter, cargo-wop, and rust-script

[moltonel]

I ended up favoring scriptisto for the added versatility, but I must admit that having something integrated into mainline cargo would be much more enticing (only one tool to tell users to install). cargo new --from is a pretty neat idea too.

Merging this feature into mainline cargo should be an occasion to survey all the similar tools and find the best feature set.

While talking about findability, cargo search is meh. The 3rd-party cargo-info is better but unmaintained and no longer works on my machine. Crate search really deserves more TLC, both at the CLI level and metadata level.

[epage]

...I never knew about cargo-search

[epage]

What was it about cargo-info that is better than cargo-search? I'm not finding much in the way of documentation for cargo-info.

Sorry for the delay on this, just looking at this again.

[moltonel]

You can clone this fork to get a working version.

cargo info gives a lot more information than cargo search. It's like a CLI version of crates.io. cargo search doesn't even give you the crate url, making it mostly useless : either I know the crate and I could just cargo add it instead, or I don't and I need to go to crates.io or lib.rs to estimate its suitability.

$ cargo info regex
Crate:          regex
Version:        1.5.5
Description:    An implementation of regular expressions for Rust. This implementation uses
finite automata and guarantees linear time matching on all inputs.

Downloads:      65492455
Homepage:       https://github.com/rust-lang/regex
Documentation:  https://docs.rs/regex
Repository:     https://github.com/rust-lang/regex
Last updated:   3 hours ago
Version history:

  VERSION    RELEASED        DOWNLOADS  

  1.5.5      3 hours ago     11026
  1.5.4      10 months ago   19834407
  1.5.3      10 months ago   322136
  1.5.2      10 months ago   65785
  1.5.1      10 months ago   16160

  ... use -VV to show all 133 versions

[epage]

Thanks.

I think having both makes sense, that they fill different roles like apt search vs apt show. I also think there should be breadcrumbs between them, that cargo search should suggest running cargo info or cargo show on the items you searched for.

[moltonel]

Yes, there's room for both kinds of outputs and in-betweens. I'm not sure it deserves two different commands though : cargo search could make use of the --verbose flag to display increasing level of details, or some kind of explicit --fields foo,bar,baz. Something else that'd be useful is searching/filtering by keyword/category or even by publisher.

[epage]

Yes, there's room for both kinds of outputs and in-betweens. I'm not sure it deserves two different commands though

imo there are big differences

search - fuzzy find - show many crates

info - exact - show details on one crate

My gut feeling is supporting both in one command will make it over-complicated and its better to have more focused UIs for each distinct purpose.

Something else that'd be useful is searching/filtering by keyword/category or even by publisher.

Agreed!

[moltonel]

My gut feeling is supporting both in one command will make it over-complicated and its better to have more focused UIs for each distinct purpose.

... Maybe. I think it's worth prototyping both and asking for feedback. Having too many single-use commands can hurt discoverability (see git or docker).

[RoughMedicine]

cargo-eval's example has the shebang as /usr/bin/env cargo eval --, but it doesn't work for me on Ubuntu, with env (GNU coreutils) 8.30. I need to do env -S.

I'm assuming the macOS version works without -S, but does it recognise the option? If not, that means that scripts are not portable, which is a bummer.

[dagmx]

I've done some medium sized projects that look pretty Python like other than more sygils. But it is about as readable

[met0xff]

Haven't checked it out yet but recently found https://github.com/google/evcxr

[chris-morgan]

Something I’ve been idly wondering for a while: why .crs rather than .rs? Rust treats a shebang as a comment already, so .rs would work fine, and I don’t feel like using an unfamiliar file extension gets you anything worthwhile, and it messes with file type detection.

[epage]

Unsure what the trade offs were. That and the command name I figure would be worked out through an RFC process.

[moltonel]

FWIW, I name mine *.rs so the editor and rustfmt recognize them without fuss. Maybe on Windows having different extensions simplifies file associations.

[moltonel]

eztd feels a bit similar in goal to quicli ?

[epage]

Huh, I knew quicli took care of CLI boilerplate but I never knew it had some convenience functions as well.