7 ms·

What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation t

by ainar-g 10y ago

What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their struggle with it This might shed some light on why people (like me) have so much trouble getting into Rust.

steveklabnik 10y ago
> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.
- kibwen 10y ago
  > I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)
  - iopq 10y ago
    And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application
    - kibwen 10y ago
      > parens are optional for function application I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.
      - iopq 10y ago
        Stop, I can only get so hard before an unsafe drop in blood pressure
  - cpeterso 10y ago
    Why not rename Vec to Buf everywhere with a Vec = Buf type alias for backwards compatibility?
- ainar-g 10y ago
  I see. I hope to see more better docs soon. Thank you for answering and for generally being open.
  - steveklabnik 10y ago
    You're welcome, on both counts. I hope we can help you not get stuck if you give it a fourth try :)
- pjungwir 10y ago
  So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered: - No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594 https://github.com/rust-lang/rfcs/issues/1594 - Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/ https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... If the next push is going to be for ease-of-use, those would be two nice things to fix.
  - comex 10y ago
    A feature designed as a fix for the second problem is already in nightly: https://github.com/rust-lang/rust/issues/34511 https://github.com/rust-lang/rust/issues/34511 Who knows when it'll be stabilized, though.
    - steveklabnik 10y ago
      "sooner rather than later"
  - rat87 10y ago
    I think if you don't mind the overhead you can box the iterator
- cpeterso 10y ago
  Why not rename String to StrBuf everywhere with a String = StrBuf type alias for backwards compatibility, if this would clarify new users' understanding of String/str?
  - steveklabnik 10y ago
    It's not clear that there's a ton of benefit, and not everyone agrees with me that StrBuf is a good name.
gcp 10y ago
Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.
- ainar-g 10y ago
  This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc<Mutex<>> was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an explicit lifetime parameter as shown: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) But when I do that I get error: `user_index_handler` does not live long enough And there I'm stuck. The user_index_handler is declared and initialised literally one line above. I don't understand why Rust thinks it can just delete it immediately after I've created it.
  - steveklabnik 10y ago
    This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http https://github.com/rust-lang-nursery/thanks/tree/master/http is the implementation, https://github.com/rust-lang-nursery/thanks/blob/master/src/main.rs#L39-L63 https://github.com/rust-lang-nursery/thanks/blob/master/src/... is the core of using it. I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
    - 10y ago
carussell 10y ago
When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no. 1. https://news.ycombinator.com/item?id=11156266 https://news.ycombinator.com/item?id=11156266
- deleted 10y ago
  [deleted]

by ainar-g 10y ago

steveklabnik 10y ago

> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.

kibwen 10y ago
> I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)
- iopq 10y ago
  And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application
  - kibwen 10y ago
    > parens are optional for function application I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.
    - iopq 10y ago
      Stop, I can only get so hard before an unsafe drop in blood pressure
- cpeterso 10y ago
  Why not rename Vec to Buf everywhere with a Vec = Buf type alias for backwards compatibility?
ainar-g 10y ago
I see. I hope to see more better docs soon. Thank you for answering and for generally being open.
- steveklabnik 10y ago
  You're welcome, on both counts. I hope we can help you not get stuck if you give it a fourth try :)
pjungwir 10y ago
So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered: - No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594 https://github.com/rust-lang/rfcs/issues/1594 - Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/ https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... If the next push is going to be for ease-of-use, those would be two nice things to fix.
- comex 10y ago
  A feature designed as a fix for the second problem is already in nightly: https://github.com/rust-lang/rust/issues/34511 https://github.com/rust-lang/rust/issues/34511 Who knows when it'll be stabilized, though.
  - steveklabnik 10y ago
    "sooner rather than later"
- rat87 10y ago
  I think if you don't mind the overhead you can box the iterator
cpeterso 10y ago
Why not rename String to StrBuf everywhere with a String = StrBuf type alias for backwards compatibility, if this would clarify new users' understanding of String/str?
- steveklabnik 10y ago
  It's not clear that there's a ton of benefit, and not everyone agrees with me that StrBuf is a good name.

gcp 10y ago

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

ainar-g 10y ago
This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc<Mutex<>> was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an explicit lifetime parameter as shown: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) But when I do that I get error: `user_index_handler` does not live long enough And there I'm stuck. The user_index_handler is declared and initialised literally one line above. I don't understand why Rust thinks it can just delete it immediately after I've created it.
- steveklabnik 10y ago
  This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http https://github.com/rust-lang-nursery/thanks/tree/master/http is the implementation, https://github.com/rust-lang-nursery/thanks/blob/master/src/main.rs#L39-L63 https://github.com/rust-lang-nursery/thanks/blob/master/src/... is the core of using it. I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
  - 10y ago

carussell 10y ago

When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no. 1. https://news.ycombinator.com/item?id=11156266 https://news.ycombinator.com/item?id=11156266

deleted 10y ago
[deleted]