nous

Realtime is important on fully fledged workstations where timing is very important. Which is the case for a lot of professional audio workloads. Linux is now another option for people in that space.

Not sure Linux can run on microcontrollers. Those tend to not be so powerful and run simple OSs if they have any OS at all. Though this might help the embedded world a bit increasing the number of things you can do with things that have full system on chips (like the Raspberry pi).

sed 's/dark/light/g and I have the same complaint. Oh my eyes clicking on that link at night in bed...

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

TBH I am not a fan of defer. It requires you to remember to use it and to know what things need cleanup code to be called. I have done quite a few code reviews for go code at places I have worked in the past and people were always forgetting to close open file or sockets or other things that needed it resulting in quite a few memory leaks in production code. I got good at spotting these in reviews and even became a bit too proactive in pointing them out by highlighting things that looked like they needed to be closed but did not actually have a close method on them... You just cannot tell from the code alone and need to look up the documentation for everything that has a Open method on it.

So I much perfer rusts drop semantics or C++s RAII. Once something goes out of scope or otherwise freed it should automatically be cleaned up and not have to make the programmer remember to do so beforehand.

Now in a language like C which does not and likely wont have drop semantics or RAII then it might make sense as it is better then nothing at all. But I don't understand that arguments for putting it in C++ at all.

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.