News for hackers. Stuff that matters.
Re:Rust 1.17 by rurban on Friday April 28, 2017 @03:04AM (#14217430)
I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything.

For fairness you need to compare Rust to D or Pony or SBCL, which are also close to C++ (even faster), plus added concurrency safety or memory safety, which can be circumvented in Rust.

Re:Rust 1.17 by adwn on Friday April 28, 2017 @03:34AM (#14217570)
> I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything.

In idiomatic Rust code, you typically have very few reference increments/decrements, making it faster and more efficient than both, GC and traditional RC-based approaches.

The reasons for this are that objects are often allocated on the stack, passed by reference (a safe pointer), and directly integrated into a larger structure, requiring fewer heap allocations and very few – if any – refcounted objects. In Rust, unlike C or C++, you can do this safely and ergonomically because Rust enforces clear and well-defined ownership semantics.

[dead]
Re:Rust 1.17 by steveklabnik on Friday April 28, 2017 @07:28AM (#14218523)
You haven't actually demonstrated any problems, just repeated that they exist.

Unsubstantiated criticism usually gets downvoted on HN, Rust or not.

Re:Rust 1.17 by adwn on Friday April 28, 2017 @07:55AM (#14218670)
> I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems.

Please elaborate. In particular, what RC and concurrency problems?

Re:Rust 1.17 by the_why_of_y on Friday April 28, 2017 @07:00PM (#14223863)