Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust?

rerun.io

Post reply on HN
Print view View original

21–30 of 294 posts

Re: Why Rust?

#21

Post by masklinn »

hsn915 wrote: post #17
thombles wrote: post #8

Earlier quoted context omitted.

> AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive The idea of reference-counted object is that by the time it's deallocated there _are_ no references left to update. Now you might reasonably be asking about the memory left behind by those old references which contain now-invalid pointers. The use-after-free…

Well, there's a concept of a _weak_ reference. I don't know whether it exists in Rust but I can't imaigne a modern reference counting system without support for it. A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified. This is what makes deallocating objects in a refcounting system potentially ar…

> Well, there's a concept of a _weak_ reference. I don't know whether it exists in Rust

It does:

- https://doc.rust-lang.org/std/rc/struct.Weak.html

- https://doc.rust-lang.org/std/sync/struct.Weak.html

> A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.

> This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.

Depends how you implement weakrefs. In Rust, when you upgrade a weakref it checks if there are outstanding strong references, and if there are not the control block is considered invalid and the upgrade fails.

There is no need to touch any of the weakrefs at any point.

And unlike languages like Python, Rust does not have weakref finalizers either.

Deallocation is still arbitrarily expensive in general, as the entire subtree will get deallocated recursively, but that has nothing to do with refcounting.

Re: Why Rust?

#23

Post by masklinn »

moonchild wrote: post #13
Fiahil wrote: post #4

Earlier quoted context omitted.

> dynamic lifetimes What do you mean ? If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.

Reference counting is much slower than 'garbage collection'.

That's an issue when every object is managed. Which is not the case in an unmanaged language, you'd only refcount what you need to refcount.

Furthermore Rust can also safely borrow from a refcounted pointer without the need for refcount traffic, which can be quite the performance gain for atomic refcounts (it's nigh irrelevant for non-thread-safe refcounts as those just do a local increment/decrement).

Re: Why Rust?

#24

Post by d3nj4l »

losvedir wrote: post #10

> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long. I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with…

If you're considering OCaml, you can also take a look at F# and Scala, both of which are languages that are influenced by the ML family but run on more popular host runtimes (the CLR and JVM respectively) that gives them access to a bigger ecosystem.

Re: Why Rust?

#25

Post by masklinn »

pdpi wrote: post #16
losvedir wrote: post #10

> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long. I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with…

Scala, Kotlin, Haxe, Swift, and several others. The search term you want is "Algebraic Data Types" Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly.

> Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly.

Erlang has a super-powered version of the pattern matching bit, but not of what GP actually likes about it:

> you have to handle every case whenever you're matching on it

because Erlang is dynamically typed. So partial patterns are acceptable, and not entirely uncommon.

Re: Why Rust?

#26

Post by frisia »

hsn915 wrote: post #17
thombles wrote: post #8

Earlier quoted context omitted.

> AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive The idea of reference-counted object is that by the time it's deallocated there _are_ no references left to update. Now you might reasonably be asking about the memory left behind by those old references which contain now-invalid pointers. The use-after-free…

Well, there's a concept of a _weak_ reference. I don't know whether it exists in Rust but I can't imaigne a modern reference counting system without support for it. A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified. This is what makes deallocating objects in a refcounting system potentially ar…

There are weak references in Rust. https://doc.rust-lang.org/std/rc/struct.Weak.html

The way it works is, in order to use it you try to upgrade it to a normal Refcounted pointer. Since it is a weak reference, this upgrade may of course fail and in that case return None (in place of a null pointer). When this upgraded pointer dies (either goes out of scope or is manually downgraded) the refcount will again be updated.

Re: Why Rust?

#28

Post by andrewflnr »

pdpi wrote: post #16
losvedir wrote: post #10

> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long. I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with…

Scala, Kotlin, Haxe, Swift, and several others. The search term you want is "Algebraic Data Types" Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly.

Binary pattern matching is very cool, but I wouldn't call it a version of ADT matching.

Re: Why Rust?

#29

Post by cageface »

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years.

C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through.

Rust code, on the other hand, often doesn't look much more elaborate than code I write in much higher level languages but it's far, far faster and I feel more confident in its correctness.

Too bad most of the Rust jobs right now seem to be in crypto.

Re: Why Rust?

#30

Post by qaq »

pdpi wrote: post #12

> Rust's enums and exhaustive match statement are just amazing ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.

ADTs is last missing piece that would make me fully content with Go :)
Post reply on HN