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

Never patterns, exhaustive matching, and uninhabited types in Rust

smallcultfollowing.com

Post reply on HN
Print view View original

21–30 of 83 posts

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

#21

Post by danidiaz »

vultour wrote: 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?

Types that represent producers of data often return a special result value at the end, of a type different from the values that are yielded. Say, a stream of integers that return a Boolean when it's exhausted.

By choosing an unhabited return type, you can express that the stream never stops producing values by itself.

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

#22

Post by mlevental »

Nokinside wrote: post #18
mlevental wrote: post #10

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…

> and you're guaranteed to be writing performant safe code That's very far from truth.

There's a term that's thrown around on Reddit that I think is appropriate here (since you're the second person to make basically this same comment): shitposting. If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. Otherwise don't say anything.

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

#23

Post by wrong_variable »

patientplatypus wrote: post #19
wrong_variable wrote: post #17

Earlier quoted context omitted.

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

( I use Firefox )

Mozilla is comparatively not a financial heavy weight like google, Microsoft.

Google has a history of doing a million things that fail, but that is exactly what i mean. They can spam the programming community with millions of things and something will eventually stick. Moz doesn't have that type of financial firepower so for them it's Rust or bust.

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

#24

Post by bluejekyll »

wrong_variable wrote: post #17
patientplatypus wrote: post #7

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…

> - untested in the wild.

This is a 100% false statement. Here’s a list: https://www.rust-lang.org/en-US/friends.html

I’ve been really impressed with how much success people have had with cross platform deployments as well. At RustConf we just saw a talk about one company putting Rust on satellites, doesn’t get more “wild” than that.

> - lack of libraries.

There are some gaps. But new libraries are showing up every day. For middle of the road, non-exotic stuff, I would be surprised if a developer doesn’t have everything they need.

> - API stability.

In the library ecosystem this is a small problem. In the past 3 years I rarely am broken from library upgrades. For the language though, I have never in the same 3 years been broken by a language upgrade. Not to say there haven’t been bugs that the language needed to fix, but stable has never failed to compile my oldest Rust 1.0 code.

Please don’t spread information ignorant of facts.

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

#25

Post by mlevental »

wrong_variable wrote: post #17
patientplatypus wrote: post #7

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…

there are people right now writing production code in Nim, Crystal, Julia, and Joy (well maybe not Joy except for Jonathan blow himself). someone taking the plunge/risk on a new language is exactly how all three of those issues you allude to get resolved (as a dialogue between language users and language developers). I don't the Google go point? which big company is behind python? ruby? php? are those all also risky languages to build in?

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

#26

Post by Nokinside »

mlevental wrote: post #22
Nokinside wrote: post #18

Earlier quoted context omitted.

> and you're guaranteed to be writing performant safe code That's very far from truth.

There's a term that's thrown around on Reddit that I think is appropriate here (since you're the second person to make basically this same comment): shitposting. If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. Otherwise don't say anything.

>If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it.

This should be applied to your original unsubstantiated claim.

Rust has some features that improve safety. Writing code in Rust does not generate safe code.

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

#27

Post by [deleted] »

the_mitsuhiko wrote: post #9
vultour wrote: 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?

A string is the worst thing to return because it’s huge. Most people return () instead which is zero sized. However when returning ! the compiler can optimize the entire error handling away.

[deleted]

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

#28

Post by bluejekyll »

Nokinside wrote: post #26
mlevental wrote: post #22

Earlier quoted context omitted.

There's a term that's thrown around on Reddit that I think is appropriate here (since you're the second person to make basically this same comment): shitposting. If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. Otherwise don't say anything.

>If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. This should be applied to your original unsubstantiated claim. Rust has some features that improve safety. Writing code in Rust does not generate safe code.

I’m not sure what you mean by this: “Writing code in Rust does not generate safe code.”

I mean philosophically you could say there is no safe code, but then what’s the point of any language improvement.

Perhaps you mean that Rust has unsafe, which allows you to write unsafe code in Rust. But technically that term is reserved for the developer to make a claim that though the compiler can’t determine the safety of this code, the developer is claiming it is safe.

Then there is safe Rust, if you write safe Rust, the guarantees that the program output is safe are pretty high. Given that no software is devoid of bugs, it’s obviously not 100%.

So do you have a specific argument your making about why Rust is not safe? Or is it a general comment about software?

Edit: I suppose you could be pedantic in that rustc doesn’t generate code, but technically it does, mir and then llvmir. That code then gets compiled to platform specific binaries.

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

#29

Post by mlevental »

Nokinside wrote: post #26
mlevental wrote: post #22

Earlier quoted context omitted.

There's a term that's thrown around on Reddit that I think is appropriate here (since you're the second person to make basically this same comment): shitposting. If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. Otherwise don't say anything.

>If you have a meaningful contribution to conversation (e.g. you can enlighten us to instances where rust compiles down to inefficient or unsafe code) then make it. This should be applied to your original unsubstantiated claim. Rust has some features that improve safety. Writing code in Rust does not generate safe code.

>This should be applied to your original unsubstantiated claim.

my meaningful contribution is a first hand account of my experience with a variety of the aspects of using rust. one potentially imprecise sentence doesn't negate that contribution. you on the other hand with completely contentless sentence fragments are contributing absolutely nothing to the conversation.

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

#30

Post by dom96 »

patientplatypus wrote: post #7

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 actually often wonder why so many web developers are drawn to Rust. Satisfying a borrow checker just doesn't seem like a worthwhile task when writing web apps. Are there things about Go that you feel are bad enough to warrant a switch to Rust?
Post reply on HN