[dreta]

Writing Rust code isn’t that hard, sure. The annoyences start when you try modifying code or moving things around.

Prototyping and editing code makes for most of my work, and Rust makes that a chore. That’s my main gripe with the language. It’s more like moving through molasses than encountering a brick wall.

[steveklabnik]

It's interesting how perspectives differ; I love refactoring Rust code more than any language I've ever used, as it catches so many of my errors when doing so for me, at compile time.

[kenhwang]

I love Rust when it's refactoring time, the compiler essentially spits out a checklist that you just need to work through. And once it's done complaining it feels pretty confidence inspiring.

But I'll agree that Rust is unpleasant for prototyping. What I find myself doing a lot when starting out a project is just figuring out if some snippet of code will work. There's no REPL to just run it in. Then I have to either set up a scaffolding project just to run it, or just shove it somewhere along the working path and move it to it's real spot later. Except sometimes that messes up the borrow, or the signature and I have to decide between temporarily altering my working code to accommodate this small test or writing mode code without testing to reach the next test point.

And after everything works with your scaffolds and shims, you have to rip it all out and put your snippet where you wanted it in the first place. And then fill in all the gaps that prevented you from testing that snippet where it is in the first; hopefully it works, otherwise you're backtracking and rebuilding scaffolds you just ripped out.

There are times I just want to write a function and not declare return type, and not have the compiler complain about non-exhaustive matching cause there's only one usage and it's output is going straight into a `println!("{:?}", thingy)` anyway.

I guess the C++ equivalent is: I know when the code reaches this point it'll segfault and blow up, but I don't care because if it made it that far that means the thing I'm prototyping ran and gave me some feedback that I could act on. Rust just forces you to write everything instead of just things up til the prototype point.

[edflsafoiewq]

Do you know about unimplemented!()? I use #[test] functions for what I'd throw into a REPL and if it's not horrible you can keep them as actual tests later.

[kenhwang]

That's really nifty! Not quite was I was thinking of though, but it gave me a starting point for some research before I came across https://github.com/rust-lang/rfcs/issues/1911 which describes why unimplemented!() doesn't quite work and what I'd like instead.

[jdemler]

Ever tried changing an owned field in a struct to a borrowed one with lifetimes? Be prepared to change not only the struct and its fields but also everything else where it appears. Yes, the compiler will catch your mistakes, but no, it's not something I love.

[tormeh]

I think the Rust devs like C++'s abstraction level. Rust is about the same (more modern), it just catches your errors. I don't think it's possible to make Rust as ergonomic as Python, but I do think it's possible to move a little in that direction without losing Rust's strengths.

[pjmlp]

Actually that is the goal of the other languages, Swift, Haskell, OCaml, ParaSail...

Influenced by Rust's success bringing affine types into mainstream.

To keep using automatic memory management as their default way of managing memory, while offering some escape hatches based on affine types for low level optimizations.

[microtonal]

Indeed, this is painful. Plus that lifetimes tend to percolate through the codebase. This is logical and necessary, if a struct is bound to a lifetime, then another struct holding this struct is also bound to that lifetime. It can be painful regardless ;).

[steveklabnik]

I hear you. It’s an important thing though; it will get slightly easier soon...