Live data from Hacker News

Never patterns, exhaustive matching, and uninhabited types in Rust

smallcultfollowing.com

11–20 of 83 posts

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#11

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

I wrote a fair bit of go at my old job and I just finished a small internal rust utility at my current job. i liked go at first but then got completely fed up with the error handling, the module/folder nonsense, having to define the same function over and over for different primitive types when it came up, and nil. so I picked up rust. it's miles better. the syntax is not as bad you imagine - my utility is about 1000…

>you're guaranteed to be writing performant safe code

Let's not get overboard here

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#12
post #6
post #3

Can someone explain why you'd want uninhabited types? > if you have to define an error type for some computation, but this particular computation can never fail, you might use an uninhabited type. I don't see the reason behind returning a Result if there is no error to return. Why not just return a String?

I've used `enum Void { }` as a placeholder for opaque FFI managed types that I pass between APIs but never inspect myself. Like Windows handles (`*const Void`) or data structures that are queried using an API rather than directly.

enum Void shouldn't be used for opaque types.

See these: https://internals.rust-lang.org/t/recent-change-to-make-exha... https://github.com/rust-lang-nursery/nomicon/issues/29 https://github.com/briansmith/ring/issues/416

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#13
post #12
post #6

Earlier quoted context omitted.

I've used `enum Void { }` as a placeholder for opaque FFI managed types that I pass between APIs but never inspect myself. Like Windows handles (`*const Void`) or data structures that are queried using an API rather than directly.

enum Void shouldn't be used for opaque types. See these: https://internals.rust-lang.org/t/recent-change-to-make-exha... https://github.com/rust-lang-nursery/nomicon/issues/29 https://github.com/briansmith/ring/issues/416

Oh wow, I didn't know this. At one time at least it was recommended, which was why I did it.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#14

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

Rust is comparable to C++ and exists in a similar space. Go is more comparable with Java (on a webserver), PHP, node, etc. Rust and Go exist in very different places although undoubtedly their Venn diagram overlaps at some weird point.

Horses for courses.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#15
post #11

Earlier quoted context omitted.

I wrote a fair bit of go at my old job and I just finished a small internal rust utility at my current job. i liked go at first but then got completely fed up with the error handling, the module/folder nonsense, having to define the same function over and over for different primitive types when it came up, and nil. so I picked up rust. it's miles better. the syntax is not as bad you imagine - my utility is about 1000…

>you're guaranteed to be writing performant safe code Let's not get overboard here

edited to clarify with zero cost abstraction

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#16
post #14

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

Rust is comparable to C++ and exists in a similar space. Go is more comparable with Java (on a webserver), PHP, node, etc. Rust and Go exist in very different places although undoubtedly their Venn diagram overlaps at some weird point. Horses for courses.

Comparable to Java 1.0 that is.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#17

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

Firstly stop comparing things in vacuum - you need to set expectations accordingly.

Go has google behind it, so regardless of anyone's opinion they can very well jam it down everybody's throat through sheer throwing money at the problem.

Go was build for fast web servers, not for what Rust is aiming for at all.

Rust also has this this obnoxious issue around it that has become a meme :

https://transitiontech.ca/random/RIIR

Rust CAN be a good choice for building a bluetooth driver or writing the logic for pacemaker (oh god no !).

But it has the steepest 90 degree hill to climb mainly because :

- untested in the wild.

- lack of libraries.

- API stability.

You should keep on using Go due to it being better tested, unless some large company throws a few billion dollars behind it, its going to take a lot of time for Rust to catch up on its own.

I bet even by 2025 rust wont get much traction unless some bigCo heavily invests in it, do not take my word for it - just look at purely open source projects like FreeBSD, Linux took nearly 20+ years to get any traction.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#18

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

I wrote a fair bit of go at my old job and I just finished a small internal rust utility at my current job. i liked go at first but then got completely fed up with the error handling, the module/folder nonsense, having to define the same function over and over for different primitive types when it came up, and nil. so I picked up rust. it's miles better. the syntax is not as bad you imagine - my utility is about 1000…

> and you're guaranteed to be writing performant safe code

That's very far from truth.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#19

Alright this is going to be a dumb question but... Every time I start a new personal project I say 'oh neat I can use Rust!' N hours later (where N is a large number) I realize Go is about as fast, much easier and more readable syntax, and so I use Go if I want something that isn't Node. I'm a web developer so maybe Rust just isn't useful for that, but is Rust purely a systems level language for making super low leve…

Firstly stop comparing things in vacuum - you need to set expectations accordingly. Go has google behind it, so regardless of anyone's opinion they can very well jam it down everybody's throat through sheer throwing money at the problem. Go was build for fast web servers, not for what Rust is aiming for at all. Rust also has this this obnoxious issue around it that has become a meme : https://transitiontech.ca/random…

I mean - I agree with a great deal with what you say...but Rust is backed by Mozilla which has written arguably the first or second most popular browser in current use. So, the bigCo argument seems misplaced. Also Google has a history of releasing languages that are often hugely unpopular (cough Dart cough) so I'm not sure that the money argument even holds even if it were true. Cool link though - Rust seems to be very popular among people who know of it, but don't use it.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#20
post #13
post #12

Earlier quoted context omitted.

enum Void shouldn't be used for opaque types. See these: https://internals.rust-lang.org/t/recent-change-to-make-exha... https://github.com/rust-lang-nursery/nomicon/issues/29 https://github.com/briansmith/ring/issues/416

Oh wow, I didn't know this. At one time at least it was recommended, which was why I did it.

Yeah, IIRC many years ago I added it in a document as a pattern for C APIs (I can't remember where though). Either other people were doing the same thing, or were influenced by that. Anyway, you should use `*const libc::void` these days! Sorry for the confusion.
Post reply on HN