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

111–120 of 294 posts

Re: Why Rust?

#111

Post by zanellato19 »

the__alchemist wrote: post #91
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.

I'll bite - I just googled this, and am having a struggle understanding. Is an Algebraic Data Type (ADT) in rust an enum or tuple? I make heavy use of enums (along with structs) as my program foundations. Am I using ADTs? The third type the query shows are unions, which I'm not familiar with.

Enums are Sum Types, which are a type of ADT[1]. Tuples are a Product Types, which are another type of ADT[2]; Sum Types are so called because when you add one to that, you add just one more possibility (It could be A,B now it can be A,B,C). Product Types, on the other hand, give out possibilities based on their Product, so if you add a new property, you multiply it (A,B can both be two things, so you have 4 possibilities, if you add C that can also be two things, then you now have 8 possibilities).

This is a good explanation: https://jrsinclair.com/articles/2019/algebraic-data-types-wh...

[1]https://en.wikipedia.org/wiki/Tagged_union

[2]https://en.wikipedia.org/wiki/Product_type

Re: Why Rust?

#112

Post by [deleted] »

qaq wrote: post #30
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 :)

[deleted]

Re: Why Rust?

#113

Post by belmont_sup »

the__alchemist wrote: post #91
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.

I'll bite - I just googled this, and am having a struggle understanding. Is an Algebraic Data Type (ADT) in rust an enum or tuple? I make heavy use of enums (along with structs) as my program foundations. Am I using ADTs? The third type the query shows are unions, which I'm not familiar with.

They’re enums that can hold additional data types.

But they’re additionally great because the compiler does exhaustive pattern matching.

Re: Why Rust?

#114

Post by masklinn »

zaphar wrote: post #73
masklinn wrote: post #25

Earlier quoted context omitted.

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

You can use partial patterns in Rust too. I think perhaps you meant partial matches?

Yeah.

Also faillible patterns outside of conditional contexts. It acts as an assertion which is nice, but the assertion is implicit which is less nice.

Re: Why Rust?

#115

Post by tasn »

cageface wrote: post #29

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 l…

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

We are hiring for Rust engineers. Not crypto. :)

https://www.svix.com/careers/

Re: Why Rust?

#116

Post by HarHarVeryFunny »

cageface wrote: post #29

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 l…

> Rust code, on the other hand, often doesn't look much more elaborate than code I write in much higher level languages

I'm curious to see an example. Could you show something written in Rust, or another "much higher level language" that you think would be messier or more difficult to write in C++ ?

Re: Why Rust?

#117

Post by dgan »

I don't understand why everyone seems to ignore Ada? Granted I am completely new to it, but from what I see it is years ahead of Rust in terms of safety (it can prove correctness!! Rust is only heading into that direction).

Yes syntax is verbose, but I dare to believe there must be another blocker than just syntax?

Re: Why Rust?

#119

Post by coldpie »

cillian64 wrote: post #101
kajaktum wrote: post #82

Earlier quoted context omitted.

What is the alternative to not having a crate ecosystem? Everyone roll their own smallvec implementations? How is that any better?

From my experience in C there are two ways libraries deal with not being able to easily pull in their own dependencies. Some of them include their own reimplementations of lots of things (data structures, logging, error handling, date-times). Others decide to keep it simple and only implement a minimal set of functionality which limits their need for dependencies or reinventing the wheel. Cargo letting libraries easi…

I don't know that I have a better suggestion, but the lack of friction on adding new dependencies makes for really hairy dependency graphs. For example, I really loathed having to write this[1] when all I did was write a gstreamer plugin in Rust. I'm not even confident that I got it all the licensing right, and I surely didn't vet every single library in the graph nor will I vet every library during a future cargo-update.

In languages where adding dependencies is more difficult, I think things tend to be simpler and thus, more verifiable. But it's also simply harder. I don't know which solution I like better.

[1] ~75 lines of library authorship copyrights https://github.com/ValveSoftware/Proton/blob/proton_7.0/dist...

Re: Why Rust?

#120

Post by cyber_kinetist »

nicoburns wrote: post #38
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…

I think you've covered all the major options: - Use Rc (or Arc if you need to be thread-safe) - Use a Vec, slotmap, or a similar data-structure and store handles (indexes). This doesn't entirely prevent use-after-free bugs. But it does tend to make them panics rather than silent errors. - Use unsafe (and ideally create your own higher-level safe abstraction) In theory, there should also be 4: - Use a GC library But I…

But most of the bugs I often face and seem to struggle with are with dynamic lifetimes (in graphics / simulation / gamedev). So even as a relatively low-level systems dev I don’t really find Rust’s borrow checker that useful.
Post reply on HN