Never patterns, exhaustive matching, and uninhabited types in Rust • Hacker News Board

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

#31

Post by Nokinside » Sat, Aug 18, 2018, 3:32 PM UTC

bluejekyll wrote: post #28

Nokinside wrote: post #26

Earlier quoted context omitted.

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

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

I have been writing safety critical code for living, so I think that saying that code "is safe" because it is written in some language is categorical error (not just error of degree) unless it is a language enables formally proofing correctness.

You can take fundamentally unsafe language like C. Restrict to subset of it MISRA C and use external static code analysis like Astree that that uses abstract interpretation to prove that there are no run time errors: no memory errors, no division of zero erros, no out-of-bounds array indexing, floating-point or integer overflows, loops always terminate, floating point rounding errors stay within specified limits etc. Something that Rust does not have.

Rust has some potential and there are some companies that attempt to provide tooling to make it possible to write safe Rust code, but it's not there yet.

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

#32

Post by smolder » Sat, Aug 18, 2018, 3:41 PM UTC

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.

The problem here is the ambiguity of "safe", I think. Saying rust generates "guaranteed safe code" seems to imply that compiled rust can never do anything wrong, which isn't true.

Rust does make guarantees about certain kinds of safety, when not using unsafe {} blocks. You get memory safety and freedom from data-race issues. I don't know if any other languages offer that without incurring runtime costs.

Slow rust code is also possible, but your code can't really be slow because it is written in rust, in the same way that c doesn't get in the way of performance.

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

#33

Post by smolder » Sat, Aug 18, 2018, 3:49 PM UTC

dom96 wrote: post #30

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?

For me, I have a fairly complex application sitting behind a http api. Rust allows me to keep the system requirements for an instance of the app low for better economy. (Memory use especially)

I actually like the ergonomics of it a lot and have learned to satisfy the borrow checker. I would use it over Java for almost anything.

The biggest downside to me is the long iteration times when making a change, compiling, and testing repeatedly.

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

#34

Post by mpartel » Sat, Aug 18, 2018, 3:55 PM UTC

dom96 wrote: post #30

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?

Performance is not the only benefit. You also get freedom from data races, and (arguably) the borrow checker imposes structure that makes the program easier to read and reason about, because it's clearer who "owns" (and can mutate) what, and what is shared.

I've missed this property when writing Java and JS even before Rust was a thing, and Go has felt the same.

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

#35

Post by Baal » Sat, Aug 18, 2018, 4:02 PM UTC

bluejekyll wrote: post #24

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…

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

Putting things on satellites might mean very different things. There is close to zero chance of anything critical being in Rust. One company I worked on has not even move from (a subset of) C90 for critical components. No C99, no C11, no C++03 and no Rust. It is likely that a company may have software in Rust, even running in a satellite module (though unlikely), but that is different than actual satellite systems being certified on Rust.

As for the rest of your argument: in many companies people is still moving to C11 or C++11. For many, software is considered for production only if it has been 5 years in the wild. A library appearing on cargo does not mean it is “available”.

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

#36

Post by masklinn » Sat, Aug 18, 2018, 4:13 PM UTC

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.

> A string is the worst thing to return because it’s huge. Most people return () instead which is zero sized.

I think what they're asking is "if you're returning a Result" but you're making the Err an unhinabitated type (so can't ever have an error) why not just return a String in the first place?

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

#37

Post by [deleted] » Sat, Aug 18, 2018, 4:29 PM UTC

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?

[deleted]

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

#38

Post by leshow » Sat, Aug 18, 2018, 4:35 PM UTC

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…

The answers here will be subjective, but IMO Rust is useful for a much wider range of things than just 'super low level stuff'. I use it for anything from small command line tools to web backends if I have the option.

I appreciate it's approach to type safety and pattern matching, in fact, I find it pretty annoying to write code in a language that doesn't at least have sum types, pattern matching, and some kind of parametric/ad hoc polymorphism (Rust's traits feature).

Another nice thing about Rust is you can be pretty confident when writing multithreaded code. One of the slogans is 'fearless concurrency', and I think it lives up to that. I can write some little tool that does a bunch of things in parallel and know at compile time that I won't have any data races.

The tradeoff is that if you haven't written a lot of code in a lang with a similar type system, it can seem daunting.

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

#39

Post by andrewflnr » Sat, Aug 18, 2018, 4:37 PM UTC

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 feel that when it comes to web services, the choice between Rust and Go is one of style. I like Rust's style (type system etc), you like Go's. Either one is fine.

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

#40

Post by sasmithjr » Sat, Aug 18, 2018, 4:40 PM UTC

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?

Consider the Ruby Gem, Fog[0]. It is designed to abstract different services away so that developers can just program against Fog and pick/choose different service providers as necessary. It's possible that for specific implementations of the fog-service boundary, an error cannot occur that definitely can occur in other implementations.

Uninhabitable types allow the implementer to tell the compiler "I cannot provide an error here", giving the compiler more information to work with when optimizing. For example, the compiler now knowing that the function call cannot return an error may make it so that the function does only return the string after optimization, and the compiler can also drop the error checking code in the caller because it's unreachable.

[0]: http://fog.io/