3 ms·

Please don’t make Rust harder to read and code. I am almost done with the long tutorial/documentation and it’s already a lot. The genetics syntax with the owner

by nazka 8y ago

Please don’t make Rust harder to read and code. I am almost done with the long tutorial/documentation and it’s already a lot. The genetics syntax with the ownership and the strut/impl/trait is already a lot to eat. For me if you have to break the past version of the language for the better it’s great. Just build an as simple and readable language as you can.

pimeys 8y ago
When you've written Rust a bit longer (over two years for me now), these changes address issues we face every day, making it now much easier to reason about your code. Before the introduction of `impl Trait`, splitting a large function using Futures to smaller ones either required you to have a ridiculously long type signature or take a performance hit with dynamic approach using a `Box`. The introduction of NLL will make beginner's life easier, so will the changes to the lifetime variables and if writing async code, you should be counting days to get the async/await and pinning to the stable rust. I'd like to know what changes here you think will make it harder to read and code Rust?
- pjmlp 8y ago
  I for one dislike the new dyn addition. Then again, I have other horses to worry about.
  - nixpulvis 8y ago
    I for two.
- nazka 8y ago
  From where I am now and so not far in the world of Rust, I am struggling to learn all the new paradigms and ways of doing things with a special syntax. Maybe the syntax is easier for others or it will get better for me after a while but when I see the new dyn it’s hard for me to place it in an already crowded things to know. The other thing is how past and future features/syntax are supported, like for the new modules systems. I will prefer to break things when it makes sense with new features well thought out rather than support different ways of doing something and have as many ways of writing it. At the end of the day with a full team it’s as many way we have to read and so to understand. And even thought your team has the same guideline it’s the same problem when we start to read open source projects all with different ways of doing things. I won’t want to have a language that don’t break things and features stack themselves across the years but rather a language that refine itself over time with only one way of doing things. We can see how it turned for C++ where the language is so big that you have different ways of writing it and like how Google has its own guidelines and others too. On the other end look how Swift look now. Right now my feelings are not to add new features but to refine the language and the syntax. But I can be all wrong. I mean I have just starting to learn Rust. A syntax with some ideas from ReasonML for instance will maybe make it better. On a side note I hope this comment comes not too raw I see many down votes. I am just expressing my point of view as a beginner. Right now I know many of my coworkers will be turn down with what I said in my first comment. And they will turn to Go instead. Which I am sure can be fine technically but I really want to see Rust succeeds and have even more Rustaceans!
  - burntsushi 8y ago
    FWIW, I would consider a good chunk of Rust 2018 to be refinements on the language and the syntax. The amount of thought that has gone into those changes is enormous. I mean, if you just look at the new things in Rust 2018[1], then basically every single one of those is a refinement or clarification on an existing idea. The major exceptions are async/await, SIMD and maybe impl Trait. SIMD isn't a language change though; just an incredibly large std::arch library module. :-) impl Trait has fairly limited scope in my view. I think its primary advantage at this point is to make it easier to write compositional code when dealing with futures. It is hard to say "no" to some new language features because many of them are very very strongly motivated by incredibly compelling use cases. async/await is the big one. Rust's direction is nothing if not pragmatic, and async/await is kind of the obvious direction to head in if we want people to be able to write asynchronous code happily. [1] - https://rust-lang-nursery.github.io/edition-guide/2018/status.html https://rust-lang-nursery.github.io/edition-guide/2018/statu...
    - chrismorgan 8y ago
      `impl Trait` syntax has been used casually in conversation on irc://irc.mozilla.org/#rust since long before Rust 1.0, and some at least of us had hoped to have it before Rust 1.0. It took a while, but we finally got it, so now we’re fairly happy. (I think the turbofish issue hadn’t occurred to those of us that casually wrote it before, but once it was being implemented it became obvious.)
      - burntsushi 8y ago
        I know. I was there. ;-) What I meant was that `impl Trait` hasn't existed yet on Rust stable, and it gives folks legitimately new powers, so it seems like it was on the line between it being a refinement and it being a legitimately new language feature. But this is splitting hairs; the classification doesn't matter much.

by nazka 8y ago

pimeys 8y ago

When you've written Rust a bit longer (over two years for me now), these changes address issues we face every day, making it now much easier to reason about your code. Before the introduction of `impl Trait`, splitting a large function using Futures to smaller ones either required you to have a ridiculously long type signature or take a performance hit with dynamic approach using a `Box`. The introduction of NLL will make beginner's life easier, so will the changes to the lifetime variables and if writing async code, you should be counting days to get the async/await and pinning to the stable rust. I'd like to know what changes here you think will make it harder to read and code Rust?

pjmlp 8y ago
I for one dislike the new dyn addition. Then again, I have other horses to worry about.
- nixpulvis 8y ago
  I for two.
nazka 8y ago
From where I am now and so not far in the world of Rust, I am struggling to learn all the new paradigms and ways of doing things with a special syntax. Maybe the syntax is easier for others or it will get better for me after a while but when I see the new dyn it’s hard for me to place it in an already crowded things to know. The other thing is how past and future features/syntax are supported, like for the new modules systems. I will prefer to break things when it makes sense with new features well thought out rather than support different ways of doing something and have as many ways of writing it. At the end of the day with a full team it’s as many way we have to read and so to understand. And even thought your team has the same guideline it’s the same problem when we start to read open source projects all with different ways of doing things. I won’t want to have a language that don’t break things and features stack themselves across the years but rather a language that refine itself over time with only one way of doing things. We can see how it turned for C++ where the language is so big that you have different ways of writing it and like how Google has its own guidelines and others too. On the other end look how Swift look now. Right now my feelings are not to add new features but to refine the language and the syntax. But I can be all wrong. I mean I have just starting to learn Rust. A syntax with some ideas from ReasonML for instance will maybe make it better. On a side note I hope this comment comes not too raw I see many down votes. I am just expressing my point of view as a beginner. Right now I know many of my coworkers will be turn down with what I said in my first comment. And they will turn to Go instead. Which I am sure can be fine technically but I really want to see Rust succeeds and have even more Rustaceans!
- burntsushi 8y ago
  FWIW, I would consider a good chunk of Rust 2018 to be refinements on the language and the syntax. The amount of thought that has gone into those changes is enormous. I mean, if you just look at the new things in Rust 2018[1], then basically every single one of those is a refinement or clarification on an existing idea. The major exceptions are async/await, SIMD and maybe impl Trait. SIMD isn't a language change though; just an incredibly large std::arch library module. :-) impl Trait has fairly limited scope in my view. I think its primary advantage at this point is to make it easier to write compositional code when dealing with futures. It is hard to say "no" to some new language features because many of them are very very strongly motivated by incredibly compelling use cases. async/await is the big one. Rust's direction is nothing if not pragmatic, and async/await is kind of the obvious direction to head in if we want people to be able to write asynchronous code happily. [1] - https://rust-lang-nursery.github.io/edition-guide/2018/status.html https://rust-lang-nursery.github.io/edition-guide/2018/statu...
  - chrismorgan 8y ago
    `impl Trait` syntax has been used casually in conversation on irc://irc.mozilla.org/#rust since long before Rust 1.0, and some at least of us had hoped to have it before Rust 1.0. It took a while, but we finally got it, so now we’re fairly happy. (I think the turbofish issue hadn’t occurred to those of us that casually wrote it before, but once it was being implemented it became obvious.)
    - burntsushi 8y ago
      I know. I was there. ;-) What I meant was that `impl Trait` hasn't existed yet on Rust stable, and it gives folks legitimately new powers, so it seems like it was on the line between it being a refinement and it being a legitimately new language feature. But this is splitting hairs; the classification doesn't matter much.