7 ms·

> but if it cannot be done for 1.0 then I would expect to see those changes shortly thereafter Why is Rust in such a rush to hit 1.0? Recent improvements have

by hoelle 12y ago

> but if it cannot be done for 1.0 then I would expect to see those changes shortly thereafter Why is Rust in such a rush to hit 1.0? Recent improvements have massively improved it, but I'm afraid it will lock too soon and suffer for it. Rust holds some promise for me, but things like simple buffer manipulation, strings, and slices are ugly and torturous in Rust, compared to Go where they are a pleasure to work with.

zurn 12y ago
I don't know about "rush" but they should move quickly because Rust is in a fleeting sweet spot of the developer attention cycle where lots of people are eager to jump onboard and it's really good enough for that now. You are barking up the wrong tree if you are waiting for Go-level simplicity, like the Rust folks have often said.
- Tuna-Fish 12y ago
  I honestly think that common string handling would be much improved if String could point to either &'static str or an owned buffer, with allocation on modification if necessary, and literals coerced to either &'static str or a String that points to the static buffer depending on type inference. String would never allocate more than it does currently, but it would do it in less predictable situations which some people probably wouldn't like. However, it would basically allow people who don't care that much about short strings to completely eschew all the .as_slice()s and .to_string()s that are currently ubiquitous in any rust string handling.
  - lawn 12y ago
    Using the experimental slicing syntax x.as_slice() can now be x[] which is a lot better. I'm not sure what will happen to .to_string() but it's a recognized problem.
    - FreeFull 12y ago
      Alternatively, since String implements Deref<str>, you can do &*x, and that works without enabling the slicing syntax (although the syntax is likely to be in 1.0).
  - masklinn 12y ago
    > if String could point to either &'static str or an owned buffer, That used to be the purpose of MaybeOwned, which was just replaced by CowString (a typedef of Cow to String and str). On Cow, a deref returns an immutable slice (with no copy) so slice methods can be called directly on the CowString, `to_mut` copies the source data if necessary and returns a mutable ref, and `into_owned` copies the source data if necessary and returns it. So if you don't really care what you get and whether it's going to be copied or whatever, ask for a CowString and go to town.
  - kibwen 12y ago
    > if String could point to either &'static str or an owned buffer There exists a copy-on-write smart pointer in the standard library that can be used for exactly this purpose: http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html
lmm 12y ago
Rust is sacrificing a lot for the sake of memory safety without garbage collection. The whole language is in some ways an experiment as to whether modern language design can ameliorate the costs of doing that. But for the kind of problem where Go would even be in the running, you don't need to pay those costs - maybe OCaml (or even Haskell) would deliver the benefits you want, without the complexity costs?
- TheHydroImpulse 12y ago
  After a while, the mental cost associated with Rust isn't that huge. Rust becomes a fairly productive language (even if it has some rough edges). I will say, however, that how you think of programming and structuring your application is very different from other languages. Especially when it comes to multi-threaded applications and how you deal with ownership and safety. But in the end, I think it pays off pretty well.
  - lmm 12y ago
    Have you compared with OCaml or something like it (maybe even Haskell)? My feeling is that the overhead in Rust is lower than you might think, but it didn't seem like it would ever go away completely. But I didn't get ever so far into it.
    - bjz_ 12y ago
      I feel like I'm actually offloading lots of my cognitive overhead to the compiler compared to all the things I need to juggle mentally when working in C or C++. It's a relief rather than a burden. I still sometimes curse the borrow checker in the moment, but I know that the quality of the resulting code is worth it. Figuring out the puzzle up front is much more enjoyable than tracking down intermittent segfaults down the road.
      - lmm 12y ago
        > I feel like I'm actually offloading lots of my cognitive overhead to the compiler compared to all the things I need to juggle mentally when working in C or C++. It's a relief rather than a burden. Sure, but I feel like Haskell is the same thing only more so. And the invariants you keep track of - does this function access the database? could this function error? which audit events might happen in this codepath? - are IMO more useful than in Rust, where you spend the same effort tracking memory ownership. Which, sure, if you need it better to have a compiler that can help you with it, but getting good performance without it is easier than many people seem to think.
Matthias247 12y ago
Regarding 1.0 I have thought about the same some time ago. Rust changed in so many areas in quite a short time so that I would think of a fast move to 1.0 as rushed. Ususally you want things stable for some time to proof themselves. If you switch to 1.0 soon after a big change you might regret it when you discover a short time later that your recent change also had some shortcomings but you can't change it anymore due to backwards compatibility guarantees.
- kibwen 12y ago
  I have always thought of Rust development as akin to simulated annealing. They could spend years still searching for the proper combination of language features that will give them a global optimum, but in that time their window of relevance in will likely close. I'd rather see them have an impact on the industry with whatever local optimum they have now rather than quietly toil away searching for perfection as they spiral off into irrelevance. The time for 1.0 is not now, IMO, but it is soon. At some point you just have to cross your fingers and launch, and learn to live with whatever mistakes you may have made. Experience has shown that the language is good enough in most respects, so even if they flub the last-minute things it won't be any worse than what any other brand-new language has had to live with.
keeperofdakeys 12y ago
1.0 isn't a total freeze, just a promise not to remove base syntax or features. If you write code for 1.0 now, it'll compile on a future 1.0 release. They are still planning on adding many more things, both in terms of libraries, and language features. http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html The things you've mentioned as torturous are mostly sugar on-top of the already implemented primitives, and are even being worked on ([n..m] slice notation, to name one).
- pron 12y ago
  > If you write code for 1.0 now, it'll compile on a future 1.0 release. Almost: it will compile on all future Rust releases to the end of time (unless Rust wants to commit suicide). Languages cannot ever make breaking changes once they reach a stable version (unless they have relatively little adoption). This is even more crucial for "low level" languages like Rust, as they are often used for projects that are meant to last for decades, and are often chosen by programmers who want don't have the patience for this kind of thing.
  - TheHydroImpulse 12y ago
    With proper tooling, one could automatically upgrade a 1.x Rust compatible codebase to be 2.0 compatible (if such a version ever exists in the future).
    - pron 12y ago
      AFAIK (and it would be interesting to hear of counter examples) that's never been done for a mainstream language before (of course, Rust is far from mainstream -- yet -- but if it never becomes mainstream than it can do whatever it wants, including break backwards compatibility).
  - masklinn 12y ago
    > Almost: it will compile on all future Rust releases to the end of time (unless Rust wants to commit suicide). Languages cannot ever make breaking changes once they reach a stable version (unless they have relatively little adoption). Or nobody expects anything from them (see: PHP)

by hoelle 12y ago

zurn 12y ago

I don't know about "rush" but they should move quickly because Rust is in a fleeting sweet spot of the developer attention cycle where lots of people are eager to jump onboard and it's really good enough for that now. You are barking up the wrong tree if you are waiting for Go-level simplicity, like the Rust folks have often said.

Tuna-Fish 12y ago
I honestly think that common string handling would be much improved if String could point to either &'static str or an owned buffer, with allocation on modification if necessary, and literals coerced to either &'static str or a String that points to the static buffer depending on type inference. String would never allocate more than it does currently, but it would do it in less predictable situations which some people probably wouldn't like. However, it would basically allow people who don't care that much about short strings to completely eschew all the .as_slice()s and .to_string()s that are currently ubiquitous in any rust string handling.
- lawn 12y ago
  Using the experimental slicing syntax x.as_slice() can now be x[] which is a lot better. I'm not sure what will happen to .to_string() but it's a recognized problem.
  - FreeFull 12y ago
    Alternatively, since String implements Deref<str>, you can do &*x, and that works without enabling the slicing syntax (although the syntax is likely to be in 1.0).
- masklinn 12y ago
  > if String could point to either &'static str or an owned buffer, That used to be the purpose of MaybeOwned, which was just replaced by CowString (a typedef of Cow to String and str). On Cow, a deref returns an immutable slice (with no copy) so slice methods can be called directly on the CowString, `to_mut` copies the source data if necessary and returns a mutable ref, and `into_owned` copies the source data if necessary and returns it. So if you don't really care what you get and whether it's going to be copied or whatever, ask for a CowString and go to town.
- kibwen 12y ago
  > if String could point to either &'static str or an owned buffer There exists a copy-on-write smart pointer in the standard library that can be used for exactly this purpose: http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html

lmm 12y ago

Rust is sacrificing a lot for the sake of memory safety without garbage collection. The whole language is in some ways an experiment as to whether modern language design can ameliorate the costs of doing that. But for the kind of problem where Go would even be in the running, you don't need to pay those costs - maybe OCaml (or even Haskell) would deliver the benefits you want, without the complexity costs?

TheHydroImpulse 12y ago
After a while, the mental cost associated with Rust isn't that huge. Rust becomes a fairly productive language (even if it has some rough edges). I will say, however, that how you think of programming and structuring your application is very different from other languages. Especially when it comes to multi-threaded applications and how you deal with ownership and safety. But in the end, I think it pays off pretty well.
- lmm 12y ago
  Have you compared with OCaml or something like it (maybe even Haskell)? My feeling is that the overhead in Rust is lower than you might think, but it didn't seem like it would ever go away completely. But I didn't get ever so far into it.
  - bjz_ 12y ago
    I feel like I'm actually offloading lots of my cognitive overhead to the compiler compared to all the things I need to juggle mentally when working in C or C++. It's a relief rather than a burden. I still sometimes curse the borrow checker in the moment, but I know that the quality of the resulting code is worth it. Figuring out the puzzle up front is much more enjoyable than tracking down intermittent segfaults down the road.
    - lmm 12y ago
      > I feel like I'm actually offloading lots of my cognitive overhead to the compiler compared to all the things I need to juggle mentally when working in C or C++. It's a relief rather than a burden. Sure, but I feel like Haskell is the same thing only more so. And the invariants you keep track of - does this function access the database? could this function error? which audit events might happen in this codepath? - are IMO more useful than in Rust, where you spend the same effort tracking memory ownership. Which, sure, if you need it better to have a compiler that can help you with it, but getting good performance without it is easier than many people seem to think.

Matthias247 12y ago

Regarding 1.0 I have thought about the same some time ago. Rust changed in so many areas in quite a short time so that I would think of a fast move to 1.0 as rushed. Ususally you want things stable for some time to proof themselves. If you switch to 1.0 soon after a big change you might regret it when you discover a short time later that your recent change also had some shortcomings but you can't change it anymore due to backwards compatibility guarantees.

kibwen 12y ago
I have always thought of Rust development as akin to simulated annealing. They could spend years still searching for the proper combination of language features that will give them a global optimum, but in that time their window of relevance in will likely close. I'd rather see them have an impact on the industry with whatever local optimum they have now rather than quietly toil away searching for perfection as they spiral off into irrelevance. The time for 1.0 is not now, IMO, but it is soon. At some point you just have to cross your fingers and launch, and learn to live with whatever mistakes you may have made. Experience has shown that the language is good enough in most respects, so even if they flub the last-minute things it won't be any worse than what any other brand-new language has had to live with.

keeperofdakeys 12y ago

1.0 isn't a total freeze, just a promise not to remove base syntax or features. If you write code for 1.0 now, it'll compile on a future 1.0 release. They are still planning on adding many more things, both in terms of libraries, and language features. http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html The things you've mentioned as torturous are mostly sugar on-top of the already implemented primitives, and are even being worked on ([n..m] slice notation, to name one).

pron 12y ago
> If you write code for 1.0 now, it'll compile on a future 1.0 release. Almost: it will compile on all future Rust releases to the end of time (unless Rust wants to commit suicide). Languages cannot ever make breaking changes once they reach a stable version (unless they have relatively little adoption). This is even more crucial for "low level" languages like Rust, as they are often used for projects that are meant to last for decades, and are often chosen by programmers who want don't have the patience for this kind of thing.
- TheHydroImpulse 12y ago
  With proper tooling, one could automatically upgrade a 1.x Rust compatible codebase to be 2.0 compatible (if such a version ever exists in the future).
  - pron 12y ago
    AFAIK (and it would be interesting to hear of counter examples) that's never been done for a mainstream language before (of course, Rust is far from mainstream -- yet -- but if it never becomes mainstream than it can do whatever it wants, including break backwards compatibility).
- masklinn 12y ago
  > Almost: it will compile on all future Rust releases to the end of time (unless Rust wants to commit suicide). Languages cannot ever make breaking changes once they reach a stable version (unless they have relatively little adoption). Or nobody expects anything from them (see: PHP)