BatmanAoD

joined 1 year ago
[–] BatmanAoD 6 points 8 hours ago

The second button is actually a pretty major change!

[–] BatmanAoD 3 points 8 hours ago

It means both.

[–] BatmanAoD 17 points 8 hours ago (5 children)

It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.

[–] BatmanAoD 34 points 8 hours ago (2 children)

In reality, that was added four and a half years after this issue was opened.

[–] BatmanAoD 9 points 9 hours ago

Yes, the dialog was changed, as part of this linked issue (and maybe again after that; this whole incident is very old). After reading some of the comments on that issue, I agree with the reasoning with some of the commenters that it would be less surprising for that menu option to behave like git reset --hard and not delete tracked files.

[–] BatmanAoD 2 points 12 hours ago

I think it does make sense to make sure there's something substantive in the very first message, even if it's not a complete description of the problem or a concrete request for help.

And the message with my problem tends to be longer and take me more time to type, so there is a delay between "Hi" and the actual issue.

That makes perfect sense, and I see why the habit became so commonplace; but that's exactly why this is annoying to anyone who is highly responsive on a messaging app, especially if responding to requests for help is part of their professional work. They pay attention to their notifications, so the notifications are probably configured to be noisy. Checking a notification before it's actionable is a waste of their time, albeit a small one.

Plus, if you force yourself to start typing out the problem before hitting "send", you'll often understand the problem better by the time you finish typing. This doesn't generally mean that you will have solved the problem yourself (though of course that sometimes happens), but it does mean you'll have more context you can provide as part of the request. And sometimes, you'll think of something you want to check or investigate before sending the request for help, in which case you'll be glad you haven't sent a ping yet.

Finally, you can still split up your messages after typing them all out. Just "cut" all but what you want to send in the first message, send, paste, and repeat.

[–] BatmanAoD 15 points 12 hours ago (2 children)

The user clicked an option to "discard" all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there's a screenshot in the thread).

[–] BatmanAoD 1 points 15 hours ago

Doesn't prolog already "not work half the time"? (Disclaimer: I haven't used it.)

[–] BatmanAoD 4 points 15 hours ago

The author actually agrees with this take, and even links to this post making it explicit: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html

[–] BatmanAoD 8 points 17 hours ago

The article is more about the behavior of members of the C++ committee than about the language. (It also has quite a few tangents.)

[–] BatmanAoD 3 points 2 days ago (1 children)

I understand what you're saying, but I want to do whatever I can to promote the shift in attitudes that's already happening across the industry.

And being late or never delivering out of fear of shipping buggy code is even worse.

From a business perspective, yes, usually true. But shipping buggy software can also harm your company's reputation. I doubt that this has been researched enough yet to be quantifiable, but it's easy to think of companies who were well known for shipping bugs (Microsoft, CD Projekt Red) and eventually suffered in one way or another for it. In both of those cases, you're probably right; Windows was good enough in the 90s to dominate the desktop market, and Cyberpunk 2077 was enough of a technical marvel (for those who had the hardware to experience it) that it probably bolstered the studio's reputation more than harmed it. But could Microsoft have weathered the transition to mobile OSes better if it hadn't left so many consumers yearning for more reliable software? And is Microsoft not partly to blame for the general public just expecting computers to be generally flaky and unreliable?

Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn't that be a better state of things overall?

34
submitted 10 months ago* (last edited 10 months ago) by BatmanAoD to c/rust
 

Almost five years ago, Saoirse "boats" wrote "Notes on a smaller Rust", and a year after that, revisited the idea.

The basic idea is a language that is highly inspired by Rust but doesn't have the strict constraint of being a "systems" language in the vein of C and C++; in particular, it can have a nontrivial (or "thick") runtime and doesn't need to limit itself to "zero-cost" abstractions.

What languages are being designed that fit this description? I've seen a few scripting languages written in Rust on GitHub, but none of them have been very active. I also recently learned about Hylo, which does have some ideas that I think are promising, but it seems too syntactically alien to really be a "smaller Rust."

Edit to add: I think Graydon Hoare's post about language design choices he would have preferred for Rust also sheds some light on the kind of things a hypothetical "Rust-like but not Rust" language could do differently: https://graydon2.dreamwidth.org/307291.html

view more: next ›