I do a lot of embedded development. We're concerned about the worst case. It doesn't matter how fast the sorting algorithm is on average, it only matters how fast it is in the worst case.
Any language which does garbage collection (like Rust) is highly suspect. If it does garbage collection at random times (like Smalltalk), it's completely useless (to us).
Rust may be fine for some use cases, but it's not, nor will it ever be, a suitable replacement for C - and that's Okay. The real question Rust-heads should be
That is not garbage collection, that's deallocation which is a TOTALLY different thing altogether. The compiler makes deallocation (which you have to do in C/C++) easier because variables are deallocated (what appears to be automatically) when leaving scope. Garbage collection goes around like your neighborhood refuse collection agency and picks up what it finds, occasionally stopping traffic in the process.
Not sure if I'm missing an intended joke here, but automatic deallocation when going out of scope is only GC with an extremely stretched definition of the term.
Rust's behaviour is synchronous and deterministic, similar to for example C freeing up local variables from the stack when a function returns. No-one describes C as a garbage-collected language.
The term "garbage collection" usually refers to an asynchronous, non-deterministic mechanism for determining when memory or other resources are no longer being used and releasing them.
Rust Garbage (Score:1)
I do a lot of embedded development.
We're concerned about the worst case.
It doesn't matter how fast the sorting algorithm is on average, it only matters how fast it is in the worst case.
Any language which does garbage collection (like Rust) is highly suspect.
If it does garbage collection at random times (like Smalltalk), it's completely useless (to us).
Rust may be fine for some use cases, but it's not, nor will it ever be, a suitable replacement for C - and that's Okay.
The real question Rust-heads should be
Re: (Score:3, Insightful)
Any language which does garbage collection (like Rust) is highly suspect.
You must be thinking of something else. Rust does not do garbage collection.
Re: (Score:2)
Yes it does, put in by compiler
calls Drop::drop which deallocate
Re: (Score:2)
Yes it does, put in by compiler
calls Drop::drop which deallocate
That is not garbage collection, that's deallocation which is a TOTALLY different thing altogether. The compiler makes deallocation (which you have to do in C/C++) easier because variables are deallocated (what appears to be automatically) when leaving scope. Garbage collection goes around like your neighborhood refuse collection agency and picks up what it finds, occasionally stopping traffic in the process.
Re: (Score:3)
it is a kind of garbage collection, don't make up your own definitions. it's just not run-time garbage collection.
Re:Rust Garbage (Score:2)
it is a kind of garbage collection
Not sure if I'm missing an intended joke here, but automatic deallocation when going out of scope is only GC with an extremely stretched definition of the term.
Rust's behaviour is synchronous and deterministic, similar to for example C freeing up local variables from the stack when a function returns. No-one describes C as a garbage-collected language.
The term "garbage collection" usually refers to an asynchronous, non-deterministic mechanism for determining when memory or other resources are no longer being used and releasing them.