71–80 of 83 posts
Earlier quoted context omitted.
Please don't flame me if this is an ignorant question, but how is uninhabited different from Javascript's undefined? That's what I would use undefined for in JS (very loosely speaking).
You can actually set a variable to `undefined` in Javascript. You can't set a value to an uninhabited type─there is no value that represents the type.
Thanks.
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?
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.
That's fine if you're using it via the Reader interface, but if you're working with StringReader directly it's a pain in the butt to deal with the non-existent exceptions. It sounds like never-patterns would help with that.
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.
>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.
There is power and freedom in the act of letting go of former actions and moving forward, from time to time. If someone judges you for making a small mistake, maybe they are the one with the issue.
This is a lesson I'm still practicing as well, so this comment is just as much a reminder to myself.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
It seems you don’t understand (or more likely you don’t want to understand). In some industries, companies _must_ be conservative by regulation or by contract: it is _not_ a choice. Trying to sell Rust by saying it is used “in satellites” is simply a PR stunt, and one that discredits your other work. Prove Rust is controlling critical systems _today_ (the kind that requires paperwork to be signed or insurances to be…
Personal attacks will get you banned here. Programming language flamewars are also definitely not welcome. Please don't post like this to HN. https://news.ycombinator.com/newsguidelines.html
As for flamewars, what are you even talking about? I have not said a single thing in favour of any language. Have you read the thread?
Earlier quoted context omitted.
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.
Please don't flame me if this is an ignorant question, but how is uninhabited different from Javascript's undefined? That's what I would use undefined for in JS (very loosely speaking).
Earlier quoted context omitted.
Personal attacks will get you banned here. Programming language flamewars are also definitely not welcome. Please don't post like this to HN. https://news.ycombinator.com/newsguidelines.html
I don’t see any personal attack. Can you quote? I don’t even know nor care about the identity of people here. As for flamewars, what are you even talking about? I have not said a single thing in favour of any language. Have you read the thread?
This is bullying: "Prove Rust is controlling critical systems _today_ ".
And this breaks the site guideline against calling names in arguments, as well as returning to personal attack: "Otherwise, please stop spreading bullshit".
Please review https://news.ycombinator.com/newsguidelines.html. Your comments need to be considerably more respectful if you want to keep posting here. There are plenty of ways to express your views about programming languages thoughtfully, including if you disagree with someone. It's not hard, if you take the spirit of this site to heart. We'd appreciate it if you'd do that.
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…
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).