Same thing with git.

There is no shortage of git beginners that refuse to use a GUI.

They ask for help for something, I haven’t used git CLI in years, so I tell them “go to this place and click those button”, then they open the vscode terminal and ask “but can I do it from CLI?” Okay then I go to search the command. Meanwhile I tell them to checkout a branch or something as basic as that and watch them struggle for way longer than it took me to find the command I was looking for.

I get that thousands of elitists have convinced you that using git from a GUI is a sin. But it’s fine, I won’t tell no one. I use a GUI myself.

Where? Because IIRC, they didn’t.

Who said it’s okay to invade Greenland? And of course it’s not ok to invade ukraine

This is important to me. More than “time until login” I’d prefer “time until queue”. I want to login before walking away because I want to open certain programs. So if an OS allows me to tell it “after you boot up, open these 3 programs” but hasn’t completely booted up, I would prefer it to one that only lets you open programs once it has booted.

And no, configuring so it opens the same programs at startup doesn’t count. I wanna choose every time I turn on the computer.

The C example is the wonderful happy path scenario that only manifests in dreams.

Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.

Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.

And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.

All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.

Is this an actual benchmark or did you just try it once?

I ask because “time to open” can be very misleading.

Even if I make the most lightweight GUI app there is (basically just draw a white background), it can take seconds until it opens for the first time. But if you close it and open it again, it is almost instantaneous. This is because of the various caches of windows. If you just log into windows, the first program you open will always need a few seconds to display the window.

Ah yes. Telling Ukraine that they should “stop fighting so people stop dieing” is being left of AOC and not Russian propaganda. We at ml are just peace absolutists, it’s just a coincidence that our peace absolutism somehow involves just giving everything to Russia.

Lemmy ml even has a rule of “don’t call us Russian bots or we’ll ban you”

Not the users though. I have .ml blocked, which means communities hosted there (therefore moderated by them) don’t show up. However I still have to read their tankie comments.

Someone on Microsoft probably needed an excuse for their pay increase.

“I rebuilt/had the idea to rebuilt the taskbar” sounds a lot better to managers than “I maintained the taskbar”.

In my case, I don’t usually encounter cases where I can’t just ?. But when I do, just make an error enum (kinda like thiserror) that encapsulates the possible errors + possibly adds more.

On the call site, just convert to string if I don’t care about specifics (anyhow-style).

I don’t find this much painful.

Concise: not much on the declaration side, since you have to create an entire enum for each function in worst-case scenario. But on code side, it’s just .map_err(MyError)?.

Type-safe: can’t beat errors as enum values wrapped in Result.

Composable: i don’t think you can beat rust enums in composability.

I don’t use anyhow/thiserror, so I’m not sure. But I believe thiserror fixes the conciseness issue for this.

“not having mandatory parenthesis in if statements is hazardous, so I prefer to write C instead of rust, because I really care about safety” < that’s how you sound.

Rust allows you to choose whatever method you want.

• Early return propagating the error
• Early return ignoring the error (maybe by returning a default value)
• Explicit handling by if-else (or match) to distinguish between error and not error cases.
• Early return and turn the error into another type that is easier to handle by the caller.
• Assume there is no error, and just panic if there is. (.unwrap)

There are only 2 error handling methods that you cannot do:

• Exceptions
• Ignore the error and continue execution

And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.

If your concept of “not ugly” is “I just want to see the happy path” then you either write bad code that is “not ugly” or write good code that is “ugly”. Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.

Most of the times you can just let ... else (which is basically a custom ? if you need if let ... else it’s because you actually need 2 branching code paths. In any other language you also do if ... else when you have 2 different code branches. I don’t see why this is a rust-specific issue.

I’d say it’s much more influential the names of the identifiers of the standard library.

A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.

We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.

You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.

This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.

The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.

And the loop doesn’t contain any codeblock. Just an opening bracket.

Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.

Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.

Not to be confused with glibc. Where the g does actually stand for gnu.

To be fair, the rust organization goes out of their way to take political stances. No other meaningful programming language is managed by an organization as politically active as rust’s. These fonts have absolutely 0 connection to politics though.

One of the techniques I’ve seen it’s like a “password”. So for example if you write a lot the phrase “aunt bridge sold the orangutan potatoes” and then a bunch of nonsense after that, then you’re likely the only source of that phrase. So it learns that after that phrase, it has to write nonsense.

I don’t see how this would be very useful, since then it wouldn’t say the phrase in the first place, so the poison wouldn’t be triggered.

EDIT: maybe it could be like a building process. You have to also put “aunt bridge” together many times, then “bridge sold” and so on, so every time it writes “aunt”, it has a chance to fall into the next trap, untill it reaches absolute nonsense.

the shape of the gap is almost the same as the peak in “other”. So that peak is probably “windows but we messed up with data collection” or “some browser in windows changed its user agent”.