nous

Cannot deal with days that are too wet either, roads flood and cars get stuck trying to push through them.

Don't ignore the responses. If you abuse it too much there is a chance that the api will just block you permanently and is generally seen as not very nice, it does take resources on both ends to process even that response.

The ratelimit crate is an OK solution for this and simple enough to implement/include in your code but can create a miss-match between your code and the API. If they ever change the limits you will need to adjust your program.

A proxy solution seems overly complex in terms of infra to setup and maintain so I would avoid that.

A better solution can depend on the API. Quite often they send back the request quotas you have left either on every request or when you exceed the rate limit. You can build into your client for the API (or create a wrapper if you have not done so already) that understands these values and backs off when the limits are reached or nearly reached.

Otherwise there are various things you can do depending on the complexity rate limit rules they have. The ratelimit crate is probably good for more complex things but you can just delay all requests for a while if the rate-limiting on the API is quite simple.

You can also do an exponential backoff algorithm if you are not sure at all what the rules are (basically quickly retry with an exponentially increasing delay until you get a successful response with an upper limit on the delay). This is also a great all round solution for other types of failures to stop your systems from hammering them if they ever encounter a different problem or go down for some reason. Though not the best if you have more info about the time you should be waiting.

I disagree. It is more than just a nitpick. Saying black holes suck things in implies that they are doing something different than any other mass. Which they are not. Would you say a star sucks in stuff around it? Or a planet? Or moon? No. That sounds absurd. It makes it sound like blackholes are doing something different to everything else - which is miss-leading at best. They way things are described matter as it paints a very different picture to the layman.

You mean the bribes?

By clear receiver it means there is only one function a name can point to. For instance you cannot have:

struct Foo;
impl Foo {
    pub fn foo(self) {}
    pub fn foo(&self) {}
}

error[E0592]: duplicate definitions with name `foo`
 --> src/lib.rs:5:5
  |
4 |     pub fn foo(self) {}
  |     ---------------- other definition for `foo`
5 |     pub fn foo(&self) {}
  |     ^^^^^^^^^^^^^^^^^ duplicate definitions for `foo`

Which means it is easy to see what the function requires when you call it. It will either have self or &self and when it is &self it can auto reference the value for you. This is unlike C and C++ where you can overload a function definition with multiple different signatures and bodies and thus the signature is important to know to know which function to actually call.

Yes rust has a operator for dereferencing as well (the *). This can be used to copy a value out of a reference for simple types the implement Copy at least.

That is a bit more expensive and complex. Looks like this is configured with a couple of resistors for 5v from USB which is simple to get and a voltage reg to drop down to 3v3 optionally. Full PD requires a chip and active negotiation for higher voltage levels. Though there are chips that do that it does increase the complexity and cost and soldering skills a bit. Might not be worth it if all you work on is 5v or 3v3.

but I do think a sizeable portion of existing C++ devs who don’t want to use rust exist

That may be true. But out of that pool of people it seemed that very very few wanted to work on the fish project. So it was not helping them much at all. The is a vastly larger pool of people that don't want to learn C++ and some of those may be willing to pick up rust. It would not take much for that to out number the number of C++ devs that want to work on fish that also don't want to learn rust. Given there are not a huge amount of contributors that regularly contribute to it according to their announcement blog post.

Protip: Don't write 600 lines of code without ever testing it at all. And by testing I mean anything, manual testing included or even just compiling it or running a linter over it. Do things incrementally and verify things at each step to make sure you are not drifting off course by some faulty assumption you made near the start.

That is not the issue at all. This lawsuit has nothing to do with user of honey, only on behalf of creators and affiliate marketers. Langley in part because users of honey signed a class action waver and makes it a sticky issue to also include them in the lawsuit.

One of the lawyers taking part in it explicitly points this out: https://youtu.be/ItiXffyTgQg?t=182

Syntax is in a large part what people are used to. Which is trivial to change by just using the thing for a while and getting used to the different syntax. But syntax is only part of a language. The tooling, documentation, error messages, and general feed back are all IMO much nicer in rust than C++. It is also easier to people new to programming or used to other languages to get into than C++ is, even including the syntax into that.

C++ was one of the first languages I learnt - and now after not using it for years I cannot stand its syntax.

From their blog post:

Finally, subjectively, C++ isn’t drawing in the crowds. We have never had a lot of C++ contributors. Over the 11 years fish used C++, only 17 people have at least 10 commits to the C++ code. We also don’t know a lot of people who would love to work on a C++ codebase in their free time.

Hard to tank when you don't have many to begin with. Rust is far nicer to new users to contribute to then old C++ code. Which can be seen in their github - in the last 24 months 16 people have contributed more then 10 commits. Which is during the conversion period - I dont expect that many of those to be C++ contributions. So rust does not seem to have hurt their contributions at all and in fact looks to have helped.

First thing I typically do when that happens is update my system and reboot. This is useful for ensuring everything is in a known consistent state and there is no weird runtime issues that happened since you last booted. And it is always good to upgrade before you reboot to ensure you are booting the latest kernel and drivers.

If that does not help then I would start by closing down steam completely (ensure it is not running in the systray at all). Then launch steam though a terminal and start the game as you normally would. You will hopefully see some logs for the game in the terminal. Though it is very game dependent as to if that will be useful at all. If not I would look online to see if the game logs anything to any other file as some games tend to do their own logging or have a flag you can enable.

If the game gives you some logs and hopefully an error message you can then see if it is useful to you and if not try googling for that error and the game name. I find this tends to dig up more specific help for games then general searches for terms like wont start or crashes though sometimes those general terms can find a solution as well.

Note: if you try to launch steam in the terminal and it is already running you wont get any logs at all from it - it basically just forwards things to the main instance or quits as it does not need to do anything. Only the first instance you start will give you and useful logs.