Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

291–300 of 323 posts

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

#291

Post by Dowwie »

dom96 wrote: post #254
Dowwie wrote: post #87

I have been working with Rust, full time, for a little less than 100 days. Like the author, I also came from Python (I authored Yosai). Unlike the author, I haven't been hitting brick walls. I also have observed all of the warning signs that the futures bridge on the tokio highway is unfinished so I didn't cross the barrier and still try to use it anyway. Instead, I have been working on myriad other synchronous parts…

I'm interested to know what attracts Python programmers to Rust. It's a very different language so I'm surprised to see so many python programmers take it up. What are your reasons for working with it?

I didn't quit Python. That would be shooting myself in the foot. I just won't be using Python everywhere for everything. Programming in Python is such a pleasant experience because I can do so much with it with so little effort. Rust enables the same but in other ways. Further, I can bridge the two!

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

#292

Post by arghwhat »

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.

I will look into those crates next time!

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

#293

Post by arghwhat »

microtonal wrote: post #268
arghwhat wrote: post #185

Earlier quoted context omitted.

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 .

I don't remember the details, but I just recall that I ended up with a converting nightmare.

Your suggestions make sense, but I can't help but think that there is something fundamentally weird about basically having to use generic programming just to take a string arg. The most sensible thing would be "everything uses &str".

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

#294

Post by SCdF »

steveklabnik wrote: post #97
jnordwick wrote: post #81

Earlier quoted context omitted.

http://www.cplusplus.com/reference/ Far far far better documentation. The Rust documentation is a mess and difficult to read for many people, but many involved in Rust seem to deny that it is a problem.

Docs team lead here. Specific feedback on improving the output of the docs is absolutely, 100% welcome. Without knowing what "it" is, I can't say if we're "denying that it is a problem." We are constantly tweaking the layout of stuff, and have some larger plans on the way as well.

FWIW I find the book very easy to follow and understand, but the auto-generated docs to be kind of confusing.

I think because:

a) the general layout feels a bit weird to me. I can't work out which bits are important and which bits aren't. There is no table of contents or similar structure b) as I'm still learning Rust the function signatures are often black magic to me, which adds to the confusion

https://doc.rust-lang.org/std/boxed/struct.Box.html is a good example.

This is a huge page, and it's overwhelming with no table of contents, or without things I probably don't care about collapsed. It is not clear to me how to use Box from this page.

Specifically for Box there is a code example on how to create a Box (great) but no indication of how to use one. Turns out you just use it and it works transparently like T would. Unlike a monad like Option or whatever. I don't know if this is obvious is you're an expert looking at the Struct signature at the top, but it's not obvious to me. It's also not obvious from the module documentation: https://doc.rust-lang.org/std/boxed/.

Then sections are broken down into different implementations against Box. Is that helpful? As a noob I don't know why that matters, I primary want a list of functions that I can interact with.

I see a lot of the function signature contains links, specifically to any other struct / trait / whatever. This is really helpful. It would also be great if there was some way of getting up to speed with parts of the structure I don't understand as well, as Rust has that Scala / Haskell trait of crazy complicated function signatures. I realise putting links on all bits is infeasible, so perhaps that is a documentation page itself, similar to how SQL structures are documented: https://www.sqlite.org/lang_select.html

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

#295

Post by jokoon »

pjmlp wrote: post #280
jokoon wrote: post #275

The more I read about those new-wave languages, the more I end up thinking that the simple languages like python and C are the clear winners. I started to learn about rust, but honestly it feels like it has the same design and features of ADA, in term of code correctness. It's a great thing, but I still wonder if it's really useful for everyone. Usually ADA was used in aerospace. And I still believe C++ has a good fu…

If software companies got recalls and were sued for lack of quality like in other industries, by now everyone would care about how their code gets written.

Sure, but that's a different debate.

If that would be the case, you would have much less competent programmers who would be able to do their job properly.

I believe the software industry is still too young and immature.

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

#296

Post by steveklabnik »

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.

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

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

#297

Post by steveklabnik »

SCdF wrote: post #294
steveklabnik wrote: post #97

Earlier quoted context omitted.

Docs team lead here. Specific feedback on improving the output of the docs is absolutely, 100% welcome. Without knowing what "it" is, I can't say if we're "denying that it is a problem." We are constantly tweaking the layout of stuff, and have some larger plans on the way as well.

FWIW I find the book very easy to follow and understand, but the auto-generated docs to be kind of confusing. I think because: a) the general layout feels a bit weird to me. I can't work out which bits are important and which bits aren't. There is no table of contents or similar structure b) as I'm still learning Rust the function signatures are often black magic to me, which adds to the confusion https://doc.rust-la…

Thanks! This is helpful. It’s true that the API docs are mostly written from an “I know Rust” perspective; but some of these kinds of things wouldn’t harm that.

> Is that helpful? As a noob I don't know why that matters, I primary want a list of functions

Yes, as it lays out the requirements for each one. Not every method is always available; it depends on what’s in the box!

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

#298

Post by oblio »

jokoon wrote: post #295
pjmlp wrote: post #280

Earlier quoted context omitted.

If software companies got recalls and were sued for lack of quality like in other industries, by now everyone would care about how their code gets written.

Sure, but that's a different debate. If that would be the case, you would have much less competent programmers who would be able to do their job properly. I believe the software industry is still too young and immature.

You’re assuming that professions that have been around for hundreds of years like lawyers or physicians or engineers don’t have incompetent practitioners :)

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

#299

Post by microtonal »

arghwhat wrote: post #293
microtonal wrote: post #268

Earlier quoted context omitted.

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 .

I don't remember the details, but I just recall that I ended up with a converting nightmare. Your suggestions make sense, but I can't help but think that there is something fundamentally weird about basically having to use generic programming just to take a string arg. The most sensible thing would be " everything uses &str".

Your suggestions make sense, but I can't help but think that there is something fundamentally weird about basically having to use generic programming just to take a string arg.

Indeed, it's the hard trade-off to make every time need a string reference, do you want a function that is slightly more general or one that has an easy-to-read signature?

It becomes even more interesting when defining trait methods. E.g.:

    trait Hello {
      fn hello(who: S) where S: AsRef;
    }
Has the benefit of being more general, but cannot be used as a trait object (dynamic dispatch), since it wouldn't be possible to generate a vtable for &Hello.

I generally prefer the generic approach for functions/methods that want to own a String, since using some_str.to_owned() to pass something to a method is not very ergonomic (relative compared to &owned_string for a function that takes &str). But you have to be certain that you don't want to use the trait as a trait object.

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

#300

Post by jgilchrist »

Analemma_ wrote: post #22
jgilchrist wrote: post #14

Earlier quoted context omitted.

"2014-11-28T21:00:09+09:00".parse:: >() With chrono, I think that's all you need. If you want to name the timezone you can use chrono-tz: let tz: Tz = "Europe/London".parse().unwrap() let date = "2014-11-28T21:00:09Z".parse:: >().with_timezone(&UTC)

That is indeed what I found :) But trying to find stuff like this with Rust's documentation-- when you're using a search engine instead of relying on having a human to interpret the question for you-- is usually tremendously frustrating. My experience has been that Rust developers lean heavily on autogenerated documentation, where each method of a struct/enum is heavily documented but there are few to no examples or…

Did you look at the READMEs of those libraries? Most of the common use cases are documented fairly comprehensively there - I pulled those examples almost directly out of those documents
Post reply on HN