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

11–20 of 294 posts

Re: Why Rust?

#11

Post by eptcyka »

Fiahil wrote: post #4
hsn915 wrote: post #3

> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…

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

Atomic reference counting does incur a slowdown.

Re: Why Rust?

#12

Post by pdpi »

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

Re: Why Rust?

#13

Post by moonchild »

Fiahil wrote: post #4
hsn915 wrote: post #3

> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…

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

Re: Why Rust?

#14

Post by WesolyKubeczek »

paulgb wrote: post #6
WesolyKubeczek wrote: post #2

TL;DR — because the author loves it, followed by what can be described as multiple paragraphs of personal preferences.

They seem pretty universal to me. For example, the tedious error handling in Go that is mentioned is a turn-off to a lot of developers. Safety and speed are both things most languages strive for, and if Rust is not THE fastest or THE safest language, it’s on the efficient frontier of the two.

No post body was provided.

Re: Why Rust?

#15

Post by mamp »

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…

F#, Swift

Re: Why Rust?

#16

Post by pdpi »

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.

Re: Why Rust?

#17

Post by hsn915 »

thombles wrote: post #8
hsn915 wrote: post #3

> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…

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

Re: Why Rust?

#18

Post by anonymous_sorry »

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

Reference for "much" slower? Surely depends on usage?

The cost is also more predictable/amortised than classic garbage collection.

Re: Why Rust?

#19

Post by jmfldn »

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.

As a Scala dev I agree.

Re: Why Rust?

#20

Post by rad_gruchalski »

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 also has exhaustive pattern matching. To the extent of having to declare catch all arity for functions.
Post reply on HN