Never patterns, exhaustive matching, and uninhabited types in Rust

Perhaps you’re making use of a parametric type provided by a library, and you don’t have control over the structure except by filling in type parameters.

When you implement a generic trait that is designed to handle errors but your specific case is infallible then it is helpful to indicate that the error case can never occur. Marking that as uninhabited makes it easier for downstream consumers to just eliminate all code related to error handling for that concrete type.

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.

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.

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.

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/

I mostly use them as return types for functions that are guaranteed to either loop forever or kill the process:

  noreturn mainloop(State* s)
    {
    for(; s->valid ;s->itick++) do_step(s);
    die(70,"invalid internal state");
    }

> Can someone explain why you'd want uninhabited types?

Uninhabited types are useful for expressing units.

I'm writing an app that makes heavy use of a Haskell library[1] that implements currency units and exchange rates using uninhabited types (type-level strings).

So, one dollar will have the type `Amount "USD"`, whereas one Euro will have the type `Amount "EUR"` (both will have a value of `1`).

An exchange rate from Euros to dollars will have the type `ExchangeRate "EUR" "USD"` (the first type parameter being 'source' and the second 'destination'), and its value will be `1.14` (the current exchange rate from EUR to USD).

A function for converting an amount in one currency into another currency unit will take two arguments: `Amount src` and `ExchangeRate src dst` and return an `Amount dst`.

Also, in general, it can be useful to:

1. Remove an argument from a function

2. Create an uninhabited type that, at the type level, represents the values of this argument

3. Tag the function's return type with this uninhabited "phantom" type

because now you no longer have to remember from which argument some return value was calculated/derived: it's right there in the value's type.

[1] https://www.stackage.org/haddock/lts-12.6/safe-money-0.6/Mon...

Type safety and zero cost abstractions are the two main draws.

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 lines and there are no lifetime parameters anywhere. the functional stuff is clean (closures, iterators, match). there are real enums (none of that iota nonsense) which as a "mature" developer have become integral to the design of any system for me. writing macros is easy (basically just like code gen in go). the borrow checker isn't that hard to satisfy - only one thing was a head scratcher and #rust-beginner helped me out there. cargo is great and so is RLS. there are a surprisingly large number of libraries given how young the language is (fewer than go for sure but enough that I didn't have to implement anything tedious myself). I mean it's just an all around pleasant experience and you're guaranteed to be writing performant (zero cost abstractions) safe code. how can you beat that? the only thing I miss from go are goroutines and the lightning fast compiler (but the rust compiler is plenty fast for how much it does). so I will probably use rust for everything other than what's fit for a python script from now on.

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.

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.

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?

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.

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.

We use Rust extensively for much higher-level (platform & apps) level stuff, and it works very well for that, too. There is a learning curve, of course, and language preferences may legitimately vary -- but I don't think Rust is just "for making super low level stuff". (Oh, and we're hiring more full-time Rust developers).

Rust is a lot more palatable once you realize this unlisted tenet:

From what I’ve seen, Rust prioritizes improvements in this order:

Refactoring code can be one of the hardest but most beneficial things a dev can do for a code base, so let’s make that simpler.

Reading code is done 10x more than writing code, so let’s make that intuitive.

Writing code can be tedious, how do we help make things ergonomic.

What this means is that the mentality of a weekend project, or any code you will write once and forget about is the worst way to try out Rust.

I’d recommend trying Rust twice. Once to create the first draft that might be shitty. Then again in a week or month to refactor that same code.

There are certainly different tasks for which different languages are suited, however for many tasks multiple languages are well-suited.

To paraphrase your question, you are essentially asking: "Why should I use language Y instead of X when X is fast enough for me, easier for me to read, and based on experience I like it better?" My immediate thought is that it sounds like language X is working quite well and aside from satisfying your personal curiosity there's no imperative to make that switch!

I think Rust makes a lot of very hard things possible, at the expense of making some easy things more annoying.

That's a tradeoff that bothers a lot of people who hear the Rust hype, only to find that it's more annoying to write the things they want to write. But if you use Rust and it makes a very hard thing possible, this is an incredibly empowering experience and you'll become a passionate believer. This is a dynamic that leads to arguments on the internet.

I've never done any substantial low-level systems programming, but there are high-level situations where I think Rust was better than anything else.

In one case, I simply couldn't get decent performance for something out of any garbage collected language I tried -- and GC time was the actual bottleneck. Rewriting in C++ seemed very intimidating and likely to be error-prone. Doing the same thing in Rust gave me the same benefits with the confidence that I hadn't made any dumb memory errors.

The second benefit of Rust is that concurrency and parallelism is easy, in the sense that 1) for basic parallelism, you can use Rayon without even thinking about it, and 2) in more complex cases, you can share stuff across threads and be confident that you haven't introduced any weird, hard-to-debug race conditions.

Typical that you'd be downvoted just for asking a question

I work in AI research (the symbolic, tree exploration kind, not machine learning) and go solves most of my problems in this domain, because it is productive enough to let me try new algorithms all the time, yet fast enough to let me actually test those algorithms.

But sometimes it is not fast enough, and rust hits that sweet spot I need, offering both extreme speed (you can hardly go any faster in execution speed or memory management) and good enough productivity (something I can't achieve in C or C++ for various reasons, although they would be my second choice if I couldn't use rust for some reason).

So, I tend to use rust for not-super-low-level stuff (quite the opposite, actually), but this is somehow a last-recourse choice for me (I'd rather use go if I can, for productivity reasons).