100 days with Rust: a series of brick walls • Hacker News Board

Re: 100 days with Rust: a series of brick walls

#261

Post by kenhwang » Sat, Mar 24, 2018, 4:53 AM UTC

steveklabnik wrote: post #219

dreta wrote: post #217

Earlier quoted context omitted.

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.

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.

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.

Re: 100 days with Rust: a series of brick walls

#262

Post by sanxiyn » Sat, Mar 24, 2018, 5:12 AM UTC

pcwalton wrote: post #145

I'm obviously about as far from the modal Rust user as one can get, but at this point the language has completely melted away into the background. I'm often tempted to write smallish scripts in dynamic languages, but even for those I frequently choose Rust just for the Cargo ecosystem. In particular I never see a reason to use C++ unless I'm contributing to a codebase that's written in it. It takes different programm…

Same here. But then I have 5 years of experience writing Rust. Wow, that feels like a totally ridiculous thing to write, but it's true.

These days I work at a startup where we are writing everything in Rust and then write C binding and Python binding to Rust code in order to connect to the outside world.

Re: 100 days with Rust: a series of brick walls

#263

Post by red75prime » Sat, Mar 24, 2018, 5:21 AM UTC

xfer wrote: post #247

arghwhat wrote: post #230

Earlier quoted context omitted.

We have gone a bit down a tangent here. My original complaint was about the friction of different error types compared to other languages (like, say, Go). Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersom…

There is zero friction if you use either error_chain/failure crate and you can still recover the precise underlying errors. The only thing is it allocates.

failure has no_std feature for the no-heap cases.

Re: 100 days with Rust: a series of brick walls

#264

Post by [deleted] » Sat, Mar 24, 2018, 5:26 AM UTC

tveita wrote: post #238

gnode wrote: post #47

Earlier quoted context omitted.

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

[deleted]

Re: 100 days with Rust: a series of brick walls

#265

Post by sanxiyn » Sat, Mar 24, 2018, 5:40 AM UTC

encoderer wrote: post #160

I consider myself a good enough engineer, and I've picked up a lot of languages. Recently I built and launched a server agent for Cronitor. Going in I knew it needed to be portable and compile to an executable. I considered Go, Rust and C. I decided to spend a day and build 3 versions of a basic Usage block to get a feel for each. I'd never written Go or Rust, and only passable C. I did C first and then tried Rust. I…

While people can learn Go in a day, it is basically impossible to learn Rust in a day.

The only reason people can learn Go in a day is that Go is similar enough to a language the person already knows. Rust is different enough to every other language in existence (including C and C++) to make learning in a day impossible.

I don't think "deciding to spend a day" is the right way to evaluate programming languages. Unfortunately, it is the common way to evaluate programming languages and Rust fares very badly in such evaluation, in my opinion, much worse than its fair score.

Re: 100 days with Rust: a series of brick walls

#266

Post by steveklabnik » Sat, Mar 24, 2018, 6:02 AM UTC

xfer wrote: post #248

steveklabnik wrote: post #194

Earlier quoted context omitted.

The new async/await stuff will help a lot with this; it'll enable borrowing across futures, which will remove this requirement and make things a lot simpler.

Are there any plans to make them happen this year?

Not just this year, but by the third quarter.

Re: 100 days with Rust: a series of brick walls

#267

Post by riquito » Sat, Mar 24, 2018, 6:12 AM UTC

kibwen wrote: post #156

riquito wrote: post #124

Earlier quoted context omitted.

> Ah, it sounds like you're using traits as types directly, which is very much discouraged by Rust (especially in conjunction with taking references to those traits). What the language really prefers for you to do is to use traits as bounds on generic types Can you write an example?

Sure thing. [Preemptive postscript: damn this got long. TL;DR don't use trait objects, just use generics. You'll thank me.] Here's the setup: we have several different types, and those types implement the same trait (think of it like an interface from other languages). // Define two different types struct Chihuahua; struct GreatDane; // Define a trait with a method trait Bark { fn bark(&self); } // Implement that met…

Thank you for your time, it was really useful!

Re: 100 days with Rust: a series of brick walls

#268

Post by microtonal » Sat, Mar 24, 2018, 6:51 AM UTC

arghwhat wrote: post #185

kibwen wrote: post #110

Earlier quoted context omitted.

> My code was littered with .as_str() and .to_string(). PSA: If you have a variable that's a String, you can easily pass it to anything that expects a &str just by taking a reference to it: fn i_take_a_str(x: &str) {} let i_am_a_string = "foo".to_string(); i_take_a_str(&i_am_a_string); Every variable of type &str is just a reference to a string whose memory lives somewhere else. In the case of string literals, that m…

Ah, I found that out later but had forgotten all about it. :) I don't remember how I found out, but it seemed oddly magical until I just now read the docs: String implements Deref . Makes more sense now. I still had a bunch of to_strings()'s, though, as things tended to take String whenever I had &str's. I found this to be a very unexpected nuisance. EDIT: Maybe I needed as_str() as the & trick doesn't work if the ta…

as things tended to take String whenever I had &str's

Functions should prefer &str or perhaps T where T: AsRef. Note that if you write code that needs an owned String, you could consider taking some T where T: Into, because this allows you to take many kinds of string types, such as &str, String, Box, and Cow.

Re: 100 days with Rust: a series of brick walls

#269

Post by microtonal » Sat, Mar 24, 2018, 6:59 AM UTC

jdemler wrote: post #226

steveklabnik wrote: post #219

Earlier quoted context omitted.

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.

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.

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

Re: 100 days with Rust: a series of brick walls

#270

Post by b0rsuk » Sat, Mar 24, 2018, 7:02 AM UTC

vvanders wrote: post #101

andromeduck wrote: post #32

Earlier quoted context omitted.

The traits implementation section is god awful and in an utterly unusable order because the ordering makes no sense. I find myself always just looking at the source to make sense of things rather than the docs which kind of defeats the point.

That's because the trait section only shows what traits a type implements. If you want to see how to use a trait just click that trait's name for the trait specific documentation.

Except that for some types traits form the bulk of functionality. Sorry I can't remember off top of my head, I'm a Rust novice.