4 ms·

Rust feels a lot like C++ with smart_ptr/unique_ptr by default, just with a different syntax. Bad things they imported from C++ : - Traits (a.k.a. I don't kno

by fooyc 12y ago

Rust feels a lot like C++ with smart_ptr/unique_ptr by default, just with a different syntax. Bad things they imported from C++ : - Traits (a.k.a. I don't known where this method is implemented). - Over-complicated and compile-time-specialized generics (feel a lot like templates). - Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do) ( https://rustbyexample.github.io/examples/clone/README.html https://rustbyexample.github.io/examples/clone/README.html ) - Explicit allocations (stack vs heap) and ownership management. Yet they added some bug-provoking things like "The final expression in the function will be used as return value". And crazy syntax rules like "ho, only if the expression is not followed by a ;".

adamnemecek 12y ago
If you actually believe that, you have not really looked. It adds e.g. algebraic data types, pattern matching, actor based concurrency, it's more functional, has pretty good macros, has the compiler do more heavy lifting etc. > Explicit allocations and ownership management. It has optional GC. And it's not like automatic memory management comes at no cost. The last thing makes sense if you think of a semi-colon as an operator turning an expression into a statement. And since it's typed, it won't let you do something dumb.
- fooyc 12y ago
  > If you actually believe that, you have not really looked. It adds e.g. algebraic data types, pattern matching, actor based concurrency, it's more functional, has pretty good macros, has the compiler do more heavy lifting etc. My point is that they have borrowed really bad features from C++. Pattern matching, Option, etc are cool; but the C++ features are ruining it, IMO.
  - steveklabnik 12y ago
    It sounds to me like you don't want a low-level programming language. That's totally fine! Rust isn't going to be amazing for everything.
    - fooyc 12y ago
      Depending on what I'm doing, I do want a low-level language. Still, Rust's memory management feels weird and painful. But above that I'm criticising features such as operator overloading, overridable copy semantics, and traits.
  - azth 12y ago
    It doesn't sound like you are a systems programmer. That, and several of the points you mention lack substance. > - Explicit allocations (stack vs heap) and ownership management. This is a great feature. If you're writing another web app, then sure, you don't care about stack vs heap. If you're writing performance oriented code, then you do. Both D and C# allow for a similar mechanism. > Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do) The assignment operator is not overridable. > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". Yet you provide no examples on how this is bug provoking. There have been exactly 0 bugs due to this feature. In short, it seems that you need to read about Rust in more details before making unbased claims.
    - dang 12y ago
      > It doesn't sound like you are a systems programmer > it seems that you need to read about Rust Please keep personal slights out of HN comments. This comment would be much better without the first and last sentences.
      - azth 12y ago
        Points taken :)
    - fooyc 12y ago
      > > - Explicit allocations (stack vs heap) and ownership management. > This is a great feature. If you're writing another web app, then sure, you don't care about stack vs heap. If you're writing performance oriented code, then you do. Both D and C# allow for a similar mechanism Some languages do that for you. Allocating on the stack by default and falling back to the heap when it wouldn't be safe to allocate on the stack. e.g. if the object can outlive the current function call, it shouldn't be allocated on the stack. If the Rust compiled doesn't known how to spot unsafe stack allocations, then you don't have memory safety. > > Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do) > The assignment operator is not overridable. That's not what I said. Operator overloading is yet an other feature that's ruining everything else, though. > > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". > Yet you provide no examples on how this is bug provoking. There have been exactly 0 bugs due to this feature. I may be wrong on this one, since type checking would spot most problem at compile time.
  - pcwalton 12y ago
    We needed those features--explicit memory management, for example--to write a browser engine, and we know others need those features too. (For example, game developers are really not OK with a language that hides the distinction between the stack and the heap.)
dbaupp 12y ago
Rust explicitly doesn't allow overriding `=`. Rust doesn't have templates, but rather parametric polymorphism and traits are part of that, they are used exactly like typeclasses in Haskell. Static typing means a dropped semicolon never introduces a bug (a meaningfully forgotten semicolon almost always results in a compile error, I've never met a problem).
- fooyc 12y ago
  > Rust explicitly doesn't allow overriding `=`. In part 25 Copy and clone: "copied by default instead of moved, because these types implement the Copy trait" So implementing the Copy trait allow to modify the semantics of assigning an object to a variable, or of passing the object around; am I right ? Feels a lot like C++'s copy constructor. > Rust doesn't have templates, but rather parametric polymorphism and traits are part of that This is just an other name for templates. > Static typing means a dropped semicolon never introduces a bug Using the last expression as return value feels weird in a language that makes everything so uber-explicit, like ownership, stack vs heap allocation, etc
  - dbaupp 12y ago
    Copy is a trait that is automatically implemented by the compiler (and cannot be manually overridden) that basically just says "semantically this type can be copied with memcpy", it doesn't actually control the runtime behaviour of =. Passing around a Copy type by-value leaves the source still usable ("a copy"), any other type leaves the source unusable at compile-time ("a move"); assignment is just a normal by-value use of the right-hand side. (The phrasing in that section isn't as clear as it could be.) They are templates with checking at the declaration, not the instantiations, so you don't get the errors nested deep inside libraries with ridiculous chains of messages. Don't knock the semicolon thing until you try it, it's actually pretty nice. :)
    - fooyc 12y ago
      > Copy is a trait that is automatically implemented by the compiler (and cannot be manually overridden) that basically just says "semantically this type can be copied with memcpy", it doesn't actually control the runtime behaviour of =. (The phrasing in that section isn't as clear as it could be.) That's a very good news. Indeed that section is not clear, it looks like user defined classes could implement the copy trait, which would be really bad. Thanks for your answers.
masklinn 12y ago
> - Traits (a.k.a. I don't known where this method is implemented). AFAIK, it's implemented either next to the struct definition or next to the trait definition, I don't think it's possible to implement a trait from one library for a struct from an other library. > - Over-complicated and compile-time-specialized generics (feel a lot like templates). No, Rust generics are reified (as are C#'s for instance) but they don't do arbitrary codegen, they're just generics, they're not a turing-complete compile-time metalanguage (that's macros) > - Explicit allocations (stack vs heap) and ownership management. Rust's very goal is to take on C and C++ with a better language, the inability to manage allocations would be a non-starter. As for ownership, the language formalises and help keep track of something which is only implied in C or C++, which is a good thing (as it moves ownership issues up, front and center, and thus reduces the likelihood of bugs due to muddled ownership). Note that Rust has Gc and Rc containers, so you don't have to bother if you want (turns out, people like unique/owned pointers and Gc was moved from "language core" to "library" because it wasn't used that much and ended up cluttering the language for little value) > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". And crazy syntax rules like "ho, only if the expression is not followed by a ;". Because it's statically typed, there's no possibility of a runtime bug here: `a` has type `A`, `a;` has type `()`. The compiler will tell you to get bent if you use the wrong one. All in all, your comments read like you want something at a more abstracted level, you should look at, say, OCaml or Go. Which is fine, just not what Rust aims to provide.
- dbaupp 12y ago
  I think promoting Rc and Gc in that way is a little disingenuous, since memory safety permeates the whole design, meaning that you can never just throw memory and mutability around without caring like you can in other languages. They help solve ownership "problems" but can't paper over the interesting part of Rust: lifetimes and memory safety. (i.e. they stop you having to structure everything as a strictly owned tree, allowing DAGs (with plain Rc) and arbitrary graphs (with Gc and Rc + weak pointers).) However, unique ownership will always be the thing that's easiest for humans, and more importantly, the compiler to reason about, and so shared data will always be slightly harder to work with than non-shared data.

by fooyc 12y ago

adamnemecek 12y ago

If you actually believe that, you have not really looked. It adds e.g. algebraic data types, pattern matching, actor based concurrency, it's more functional, has pretty good macros, has the compiler do more heavy lifting etc. > Explicit allocations and ownership management. It has optional GC. And it's not like automatic memory management comes at no cost. The last thing makes sense if you think of a semi-colon as an operator turning an expression into a statement. And since it's typed, it won't let you do something dumb.

fooyc 12y ago
> If you actually believe that, you have not really looked. It adds e.g. algebraic data types, pattern matching, actor based concurrency, it's more functional, has pretty good macros, has the compiler do more heavy lifting etc. My point is that they have borrowed really bad features from C++. Pattern matching, Option, etc are cool; but the C++ features are ruining it, IMO.
- steveklabnik 12y ago
  It sounds to me like you don't want a low-level programming language. That's totally fine! Rust isn't going to be amazing for everything.
  - fooyc 12y ago
    Depending on what I'm doing, I do want a low-level language. Still, Rust's memory management feels weird and painful. But above that I'm criticising features such as operator overloading, overridable copy semantics, and traits.
- azth 12y ago
  It doesn't sound like you are a systems programmer. That, and several of the points you mention lack substance. > - Explicit allocations (stack vs heap) and ownership management. This is a great feature. If you're writing another web app, then sure, you don't care about stack vs heap. If you're writing performance oriented code, then you do. Both D and C# allow for a similar mechanism. > Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do) The assignment operator is not overridable. > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". Yet you provide no examples on how this is bug provoking. There have been exactly 0 bugs due to this feature. In short, it seems that you need to read about Rust in more details before making unbased claims.
  - dang 12y ago
    > It doesn't sound like you are a systems programmer > it seems that you need to read about Rust Please keep personal slights out of HN comments. This comment would be much better without the first and last sentences.
    - azth 12y ago
      Points taken :)
  - fooyc 12y ago
    > > - Explicit allocations (stack vs heap) and ownership management. > This is a great feature. If you're writing another web app, then sure, you don't care about stack vs heap. If you're writing performance oriented code, then you do. Both D and C# allow for a similar mechanism Some languages do that for you. Allocating on the stack by default and falling back to the heap when it wouldn't be safe to allocate on the stack. e.g. if the object can outlive the current function call, it shouldn't be allocated on the stack. If the Rust compiled doesn't known how to spot unsafe stack allocations, then you don't have memory safety. > > Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do) > The assignment operator is not overridable. That's not what I said. Operator overloading is yet an other feature that's ruining everything else, though. > > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". > Yet you provide no examples on how this is bug provoking. There have been exactly 0 bugs due to this feature. I may be wrong on this one, since type checking would spot most problem at compile time.
- pcwalton 12y ago
  We needed those features--explicit memory management, for example--to write a browser engine, and we know others need those features too. (For example, game developers are really not OK with a language that hides the distinction between the stack and the heap.)

dbaupp 12y ago

Rust explicitly doesn't allow overriding `=`. Rust doesn't have templates, but rather parametric polymorphism and traits are part of that, they are used exactly like typeclasses in Haskell. Static typing means a dropped semicolon never introduces a bug (a meaningfully forgotten semicolon almost always results in a compile error, I've never met a problem).

fooyc 12y ago
> Rust explicitly doesn't allow overriding `=`. In part 25 Copy and clone: "copied by default instead of moved, because these types implement the Copy trait" So implementing the Copy trait allow to modify the semantics of assigning an object to a variable, or of passing the object around; am I right ? Feels a lot like C++'s copy constructor. > Rust doesn't have templates, but rather parametric polymorphism and traits are part of that This is just an other name for templates. > Static typing means a dropped semicolon never introduces a bug Using the last expression as return value feels weird in a language that makes everything so uber-explicit, like ownership, stack vs heap allocation, etc
- dbaupp 12y ago
  Copy is a trait that is automatically implemented by the compiler (and cannot be manually overridden) that basically just says "semantically this type can be copied with memcpy", it doesn't actually control the runtime behaviour of =. Passing around a Copy type by-value leaves the source still usable ("a copy"), any other type leaves the source unusable at compile-time ("a move"); assignment is just a normal by-value use of the right-hand side. (The phrasing in that section isn't as clear as it could be.) They are templates with checking at the declaration, not the instantiations, so you don't get the errors nested deep inside libraries with ridiculous chains of messages. Don't knock the semicolon thing until you try it, it's actually pretty nice. :)
  - fooyc 12y ago
    > Copy is a trait that is automatically implemented by the compiler (and cannot be manually overridden) that basically just says "semantically this type can be copied with memcpy", it doesn't actually control the runtime behaviour of =. (The phrasing in that section isn't as clear as it could be.) That's a very good news. Indeed that section is not clear, it looks like user defined classes could implement the copy trait, which would be really bad. Thanks for your answers.

masklinn 12y ago

> - Traits (a.k.a. I don't known where this method is implemented). AFAIK, it's implemented either next to the struct definition or next to the trait definition, I don't think it's possible to implement a trait from one library for a struct from an other library. > - Over-complicated and compile-time-specialized generics (feel a lot like templates). No, Rust generics are reified (as are C#'s for instance) but they don't do arbitrary codegen, they're just generics, they're not a turing-complete compile-time metalanguage (that's macros) > - Explicit allocations (stack vs heap) and ownership management. Rust's very goal is to take on C and C++ with a better language, the inability to manage allocations would be a non-starter. As for ownership, the language formalises and help keep track of something which is only implied in C or C++, which is a good thing (as it moves ownership issues up, front and center, and thus reduces the likelihood of bugs due to muddled ownership). Note that Rust has Gc and Rc containers, so you don't have to bother if you want (turns out, people like unique/owned pointers and Gc was moved from "language core" to "library" because it wasn't used that much and ended up cluttering the language for little value) > Yet they added some bug-provoking things like "The final expression in the function will be used as return value". And crazy syntax rules like "ho, only if the expression is not followed by a ;". Because it's statically typed, there's no possibility of a runtime bug here: `a` has type `A`, `a;` has type `()`. The compiler will tell you to get bent if you use the wrong one. All in all, your comments read like you want something at a more abstracted level, you should look at, say, OCaml or Go. Which is fine, just not what Rust aims to provide.

dbaupp 12y ago
I think promoting Rc and Gc in that way is a little disingenuous, since memory safety permeates the whole design, meaning that you can never just throw memory and mutability around without caring like you can in other languages. They help solve ownership "problems" but can't paper over the interesting part of Rust: lifetimes and memory safety. (i.e. they stop you having to structure everything as a strictly owned tree, allowing DAGs (with plain Rc) and arbitrary graphs (with Gc and Rc + weak pointers).) However, unique ownership will always be the thing that's easiest for humans, and more importantly, the compiler to reason about, and so shared data will always be slightly harder to work with than non-shared data.