7 ms·

> 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,

by 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.
  - burntsushi 12y ago
    > 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. This seems like a weird thing to say given that the Rust compiler does fairly sophisticated analysis on the lifetime of data. (And yes, Rust has memory safety.) As a low level language, the programmer decides explicitly what is allocated on the stack and what is on the heap.
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.)

by fooyc 12y ago

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.
- burntsushi 12y ago
  > 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. This seems like a weird thing to say given that the Rust compiler does fairly sophisticated analysis on the lifetime of data. (And yes, Rust has memory safety.) As a low level language, the programmer decides explicitly what is allocated on the stack and what is on the heap.

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.)