Hacker News new | past | comments | ask | show | jobs | submit login

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.




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


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.


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


Points taken :)


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


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

There are several problems with this approach for systems programming.

1. Escape analysis is conservative. Whenever you have an indirect function call or a call in another module, you have to assume that it will cause a value to escape. By making the lifetime part of the type, Rust can keep values on the stack even when indirect or cross-module functions are involved.

2. When you put a value on the heap, how do you know when to destroy it? All industry languages with escape analysis require a garbage collector, which reduces application throughput in the mark phase. But in Rust, with unique ownership, you can make that information known at compile time in most cases.

3. Not all heaps are created equal. There are many kinds of allocators—thread-local allocators, bump allocators, global allocators, etc.

4. Garbage collectors don't work very well with external libraries that don't use the same memory management scheme. By not requiring a garbage collector or a standard heap, Rust can interoperate better with other languages. For example, you can write libraries in Rust that plug into Ruby with no extra runtime support.

> That's not what I said. Operator overloading is yet an other feature that's ruining everything else, though.

Operator overloading is really important for things like bignums and custom containers like vectors. I think the Rust way of using traits for this (meaning that the operators always have consistent types, and have to be defined in one place) makes it much less confusing than the ad-hoc approach of C++.


Thanks for this insightful answer.

About operator overloading, some languages have seemless bignums without allowing users to overload operators in their own classes. For containers, this could have been restricted to the index operator.


But it's not just about indexes or certain containers. Sure, C++ makes things unwieldy, but the solution is not to drop operator overloading in its entirety. Rust wants to take on C++ head to head. For graphics programming and certain applications, operator overloading makes life a lot easier, and is a very welcome addition.

Take a look at Scala for an arguably worse implementation of operator overloading. Though still, the IDE helps a lot there.


Surely "a + b" is nicer to the eye than "a.add(b)", but unless a and b are numbers, a method call with a meaningful name is more straightforward than any abuse of allowed operators.

> Take a look at Scala for an arguably worse implementation of operator overloading.

Indeed

> Though still, the IDE helps a lot there.

If I need an IDE to understand some code, and tend to stay away from that code/language.


What if a and b are numbers? What if they're matrices? What if they're quaternions -- or higher? What if they're finite fields? Additive groups? Points on an elliptic curve? Random variables?

Operators (+ - * / ^ & | ¬) come from mathematics. While I'm sure there are plenty of node jockeys who have little use for numbers outside of specifying ports, there are still plenty of us for whom operator overloading is a necessary good.


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


Is there many cases where it's safe to allocate an object on the stack, but you would want to allocate it on the heap instead ? (Appart from the the object being too big.)


As I said, it's about making costs explicit. Otherwise, you're relying on the compiler's escape analysis to choose whether to allocate something on the heap or the stack. A programmer might not realize that something escapes, and thus, there is a heap allocation that the programmer thought was a stack allocation.

It's worth something to be able to say, "put this on the stack dammit" and if it can't go on the stack safely, require that the compiler yell at you.


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


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: