Currently the term "unsafe" is overloaded, as both the keyword used to mark definitions of things that require manual verification, and as the keyword used to mark a block to acknowledge that such verification has been done.
The correct approach is obviously to separate these two terms, and use "sus" to mark items that require verification, and "yolo" to mark that such verification has been done. Or:
sus fn dangerous() { ... }
yolo { dangerous() } // can only call dangerous inside a yolo block
I do not think we can trust a computer to decide whether something is true or false. These kinds of august deliberations are best left to the new Disinformation Governance Board!
All programs contain bugs and cosmic rays can flip bits at any time so it's nonsensical to trust boolean expressions. Therefore we should rename true/false to likely/unlikely.
"yeet" is being used as a placeholder for a keyword which will rethrow errors to a caller. It probably won't actually be called "yeet"; they're just using a deliberately silly keyword to keep discussion focused on the functionality.
Bikeshedding from the outside is fine. As long as actual decision makers and productive project members aren't participating, bikeshedding can even be fun.
Be careful with that - some Rust team members are active around HN [1], some are even participating in the comment section for this post. So I guess we need to exclude them from the outsider-exclusive bikeshedding event.
I agree, bikeshedding can be fun, as long as it's not during a meeting.
[1] Steve Klabnik, I know you're going to see this - just wanted to say hi, I hope you're having a nice day :)
It's not really my place to warn you since it's not my problem, but I take exception to your assertion that the poster is in error. I think we should raise the bar, and check ourselves when being too critical. Try not to panic when other folk throw out ideas, even when you find fault in them. I didn't expect this to be a political topic, unlike abortion the last few days. Yeetsh!
I've been recently working on a new system that involves a custom IDL. We ended up adding a "[<=]" syntax, but we were worried it would be confusing to new developers. We realized it would make people happy to have an excuse to type smiley faces, though.
Your comment demonstrates why they chose "yeet". People start discussing the name before the feature, and choosing a name that is obviously not the final one lets them say "look, you don't have to discuss this yet".
Well, if they wanted people not to discuss the name, picking a polarizing, very distinctive, extremely annoying name is about the worst thing they could have done, even as a temporary placeholder.
It's not necessarily a "re-"throw. It could just be a throw of a newly detected error, like:
try {
if bad_thing {
do yeet Error::new(...);
}
carry_on()
}
Just plain "throw" would probably be fine, but I understand not wanting to bikeshed it at this stage.
Weirdly, "yeet" really does convey the sense of "just give up and chuck this thing back instead" that makes it a reasonable nice converse of "try", i.e. "try { yeet }".
Bikeshedding is a major pain for developing in large projects.
Naming bikeshedding is one of the worst kind of bikeshedding.
By now I'm sure of two things:
- People will not agree on a name.
- People will diverge any technical discussion again and again and again because they need to discuss naming.
So in the end most likely there will be some formal or informal survey and then the language teem will do a top-down decisions for one of the more well liked candidates, it's as far as I can tell pretty much the best way to go. (Theoretically you could have a vote, but then you need a proper not easily manipulated voting system people need to take serious, or it will be named not yeet in the end because people are trolls).
EDIT: Also this is not a developer discussion so I guess it's fine here ;)
I’m puzzled as to why this PR used “do yeet” and not just “yeet”. Are they bikeshed-avoiding the bikeshed-avoidance because just “yeet” would actually be ergonomic and fun and therefore become a candidate if not deliberately sabotaged? Was “yeet” too credible? Is this admission paving the way for actually using “yeet” as the final syntax later? This drama and more, nightly at 7pm.
That's exactly what happened to Linux Mint's Warpinator the name was purposely chosen to be stupid as a temporary placeholder, and then they ended up sticking with it.
I wonder what's going to happen with dark matter and dark energy once physicists have it figured out. They'll give the discoveries proper names followed by media and pop culture using "Dark X" for the next few decades?
Exactly. We have general agreement that we want this feature, and several different opinions on what it should or shouldn't be called, and we wanted to enable experimentation without blocking on the naming discussion. (We'll have to have that discussion at some point.)
1. It's only in nightly and needs a feature gate to be enabled, as such accidental usage is impossible and it's not usable at all for most projects (which require stable compatibility).
2. It will be removed in the future there is absolutely no stability guarantees for nightly unstable features, they might literally be gone in the next hour. If you abuse it no one care that you project brakes, the ecosystem knows that and as such stays away from nightly features outside of experimenting (and some unusual target support, like recompiling std with different options for using threads in WASM).
Or in other words it's a very very different situation then unstable JS features which always where a mess you easily could accidentally use and in practice (CSS prefix) had to use all the time. Any feature gated nightly unstable things is better seen as an experimental fork of the compiler which is slightly easier to use then an actual fork.
I think some of the complaints about the permanence of temporary solutions are unwarranted in this case. This is only for the nightly branch of the compiler. Most Rust users run the stable compiler[1] (a different build) which is wholly incapable of using this feature.
There are definitely niche features that languish in nightly for years, but this initiative to improve the Try trait and ? operator will have broad appeal and I imagine a good number of people willing to push forward to get it stabilized, at which point they will finally decide on the proper name.
Sure, some people won't know the meaning of the word, but I'd argue that "raise" or "throw" meaning "propagate the previously caught error" is not obvious either, we're simply used to it. And it would take no time at all to infer from context/look up and it would be easy to remember.
The biggest potential downside I can think of is opening the floodgates for adding more memey words to the language which could indeed be harmful.
But I do think that having a quirky keyword like this could be a great benefit and not just in the "relating to them kids" sense. In my experience, the biggest obstacle to entering technical fields (a more relevant subtype of this is learning complex programming languages, such as Rust) is, for most people, not the lack of intelligence or resources, but rather the feeling that the insiders of those fields are in a different "category" of people.
This is especially evident in interactions with PhDs. Even smart people, who have themselves successfully studied the fields in question at some point in their lives, upon finding out that someone has a PhD cease all attempts of analyzing what the PhD is saying and just nod along, as if the degree is an impenetrable intellectual barrier.
In spite of being a decent programmer, it took me a long time to start reading computer science papers. Not because they were too complicated or I lacked context, but because the intentionally the language used made the work appear alien.
And including even just a bit of spontaneous humanity can completely break this perception. I find this especially effective in textbooks. All of the textbooks I found most useful added many humorous tidbits. The purpose of those was not to have the amusement counteract boredom, the topics were fascinating by themselves, but rather to demonstrate to the reader that the author is in fact an individual of the same species. This is important, because such connection cannot be established if the book restricts itself solely to its main topic. The author is infinitely more knowledgeable than the reader in the relevant field (otherwise the reader would have no use for the textbook), so this demonstration of equality must come from elsewhere.
fn foo() -> Bar throws Baz {
...
return bar;
...
throw baz; //or yeet, in this proposal
}
and it works exactly identically as the first example. ? still works inside the function just as it normally would. I find the proposal sort of pointless, but also totally harmless, so why not.
That's not all it does. It "breaks" to the nearest "try" barrier. It's basically the desugaring of the Err branch in the ? operator, that you can't currently express yourself. It's mostly relevant for try blocks. I guess you'd most commonly see this in "control flow like" macros that are similar to the ? operator, like various assertion macros that want to "yeet" an error in case the assertion fails (instead of panicking like those in std).
So in a sense it actually is very similar to `throw` in traditional languages, as it can be caught inside the same function and isn't forced to `return` the error outside the function.
63 comments
[ 4.8 ms ] story [ 130 ms ] threadI HAZ A var ITZ A BUKKIT OF YARN
The correct approach is obviously to separate these two terms, and use "sus" to mark items that require verification, and "yolo" to mark that such verification has been done. Or:
https://areweyeetyet.rs/
I agree, bikeshedding can be fun, as long as it's not during a meeting.
[1] Steve Klabnik, I know you're going to see this - just wanted to say hi, I hope you're having a nice day :)
There are some other folks around so your point isn't incorrect, only about me.
I've been recently working on a new system that involves a custom IDL. We ended up adding a "[<=]" syntax, but we were worried it would be confusing to new developers. We realized it would make people happy to have an excuse to type smiley faces, though.
Weirdly, "yeet" really does convey the sense of "just give up and chuck this thing back instead" that makes it a reasonable nice converse of "try", i.e. "try { yeet }".
Naming bikeshedding is one of the worst kind of bikeshedding.
By now I'm sure of two things:
- People will not agree on a name.
- People will diverge any technical discussion again and again and again because they need to discuss naming.
So in the end most likely there will be some formal or informal survey and then the language teem will do a top-down decisions for one of the more well liked candidates, it's as far as I can tell pretty much the best way to go. (Theoretically you could have a vote, but then you need a proper not easily manipulated voting system people need to take serious, or it will be named not yeet in the end because people are trolls).
EDIT: Also this is not a developer discussion so I guess it's fine here ;)
Pretty much guaranteed, as "do yeet" is also rather long. Likely some new edition introduced keyword/syntax or similar will be used.
Also while yeet is "fun" very few want to see it in the language for real ;)
Even if the Rust devs pick throw as a keyword, I'm 100% sure someone will write a macro that will allow you to write yeet! instead.
I'm 66% sure that this macro will end up being included in the dependency chain of a common framework as well…
One of the most obnoxious things is people forcing other people to partake in their own sense of humor.
…and JavaScript will never be used for more than animating basic hypertext documents.
You can be sure this is not the final keyword.
1. It's only in nightly and needs a feature gate to be enabled, as such accidental usage is impossible and it's not usable at all for most projects (which require stable compatibility).
2. It will be removed in the future there is absolutely no stability guarantees for nightly unstable features, they might literally be gone in the next hour. If you abuse it no one care that you project brakes, the ecosystem knows that and as such stays away from nightly features outside of experimenting (and some unusual target support, like recompiling std with different options for using threads in WASM).
Or in other words it's a very very different situation then unstable JS features which always where a mess you easily could accidentally use and in practice (CSS prefix) had to use all the time. Any feature gated nightly unstable things is better seen as an experimental fork of the compiler which is slightly easier to use then an actual fork.
There are definitely niche features that languish in nightly for years, but this initiative to improve the Try trait and ? operator will have broad appeal and I imagine a good number of people willing to push forward to get it stabilized, at which point they will finally decide on the proper name.
[1]: https://blog.rust-lang.org/2020/12/16/rust-survey-2020.html
Sure, some people won't know the meaning of the word, but I'd argue that "raise" or "throw" meaning "propagate the previously caught error" is not obvious either, we're simply used to it. And it would take no time at all to infer from context/look up and it would be easy to remember.
The biggest potential downside I can think of is opening the floodgates for adding more memey words to the language which could indeed be harmful.
But I do think that having a quirky keyword like this could be a great benefit and not just in the "relating to them kids" sense. In my experience, the biggest obstacle to entering technical fields (a more relevant subtype of this is learning complex programming languages, such as Rust) is, for most people, not the lack of intelligence or resources, but rather the feeling that the insiders of those fields are in a different "category" of people.
This is especially evident in interactions with PhDs. Even smart people, who have themselves successfully studied the fields in question at some point in their lives, upon finding out that someone has a PhD cease all attempts of analyzing what the PhD is saying and just nod along, as if the degree is an impenetrable intellectual barrier.
In spite of being a decent programmer, it took me a long time to start reading computer science papers. Not because they were too complicated or I lacked context, but because the intentionally the language used made the work appear alien.
And including even just a bit of spontaneous humanity can completely break this perception. I find this especially effective in textbooks. All of the textbooks I found most useful added many humorous tidbits. The purpose of those was not to have the amusement counteract boredom, the topics were fascinating by themselves, but rather to demonstrate to the reader that the author is in fact an individual of the same species. This is important, because such connection cannot be established if the book restricts itself solely to its main topic. The author is infinitely more knowledgeable than the reader in the relevant field (otherwise the reader would have no use for the textbook), so this demonstration of equality must come from elsewhere.
How does this improve on (?)?
So in a sense it actually is very similar to `throw` in traditional languages, as it can be caught inside the same function and isn't forced to `return` the error outside the function.