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

41–50 of 83 posts

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

#41

Post by leshow »

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?

The type system is one of the main draws for me.

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

#42

Post by steveklabnik »

Baal wrote: post #35
bluejekyll wrote: post #24

Earlier quoted context omitted.

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

The talk had a diagram, most components on it were in Rust, and the plan is to use more and more moving forward. Even critical stuff.

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

#43

Post by steveklabnik »

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…

By next year, Google may be the largest single employer of Rust programmers in the world. They might even already be, but the Fuscia team is aggressively hiring.

Facebook is too.

Amazon had a booth, I didn’t get a chance to talk to them about their current deployment personally.

Don’t underestimate China either, PingCap has huge deployments of their database, and while we may not hear about them often in the West, the numbers don’t lie.

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

#44

Post by zlynx »

sasmithjr wrote: post #40
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…

This kind of thing has been plenty annoying in C++ code. Things like switch, default, abort that used to catch RAM or CPU errors and provide useful information now get optimized away and execution continues in the face of impossible values.

Removing checks for "cannot possibly happen" cases isn't usually worth the tiny time savings.

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

#45

Post by bluejekyll »

Baal wrote: post #35
bluejekyll wrote: post #24

Earlier quoted context omitted.

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

Here’s the company and product for the sat reference: https://www.kubos.com/kubos/

> For many, software is considered for production only if it has been 5 years in the wild.

Time is irrelevant, it’s about usage and stability. Every rust crate I rely on has published download numbers, which give you an idea of number of people using it. In that set, they are all open source and published on GitHub or Gitlab, so I can look at the codebases easily.

You can wait, that’s fine. But you do end up missing out on helping shape a new environment that is growing at crazy rates over the last few years.

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

#46

Post by Rusky »

zlynx wrote: post #44
sasmithjr wrote: post #40

Earlier quoted context omitted.

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…

This kind of thing has been plenty annoying in C++ code. Things like switch, default, abort that used to catch RAM or CPU errors and provide useful information now get optimized away and execution continues in the face of impossible values. Removing checks for "cannot possibly happen" cases isn't usually worth the tiny time savings.

I'm all for leaving asserts in release builds, but leaving in dead code based on uninhabited types isn't gonna help you catch RAM or CPU errors. You'll just continue into the error branch with an impossible value instead. It's the wrong layer for that.

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

#47

Post by Rusky »

Nokinside wrote: post #31
bluejekyll wrote: post #28

Earlier quoted context omitted.

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…

That sounds exactly like an error of degree- Rust does have "no memory errors" proof tools already, built into the language.

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

#48

Post by stmw »

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…

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

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

#49

Post by Baal »

bluejekyll wrote: post #45
Baal wrote: post #35

Earlier quoted context omitted.

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

Here’s the company and product for the sat reference: https://www.kubos.com/kubos/ > For many, software is considered for production only if it has been 5 years in the wild. Time is irrelevant, it’s about usage and stability. Every rust crate I rely on has published download numbers, which give you an idea of number of people using it. In that set, they are all open source and published on GitHub or Gitlab, so I can…

Sorry but that company/product looks like it is a Linux distro and framework tuned/supported for satellite hardware. That does not mean it controls the satellite nor that it is certified.

If you think “download numbers” (or open source, or being in GitHub) is a good metric for measuring reliability, it means you haven’t really worked in any such field.

It isn’t growing _at all_ in many fields, because it is simply way too new (no new software projects started on it), it isn’t certified (or even impossible to certify). That does not mean it is not better, so don’t take that as an attack. It is simply a suicide in risk-analysis to use a new language, new libraries and new compiler front-end in safety-critical projects; so it is a no-go. Similarly for C11, C++14, C++17 and many other languages, frameworks and libraries that you have to approve.

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

#50

Post by yazaddaruvala »

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…

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.

Post reply on HN