nous

joined 2 years ago
[–] nous@programming.dev 8 points 5 months ago

Once had a missing semi colon at the end of a c header file. The compiler kept complaining about the c file and never mentioned the header. Not all errors lead you to the right place.

Though most of the time people just don't read them. The number of problems I have solve for people by just copy pasting the error they gave me back to them...

[–] nous@programming.dev 6 points 5 months ago (2 children)

Just because your bowser is not caching does not mean something else between you and the server is not caching as well.

[–] nous@programming.dev 16 points 5 months ago

Though the constant resistance from people like Hellwig were part of the reason for that burn out, though not the only reason.

[–] nous@programming.dev 2 points 6 months ago

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

[–] nous@programming.dev 4 points 6 months ago

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

[–] nous@programming.dev 18 points 6 months ago

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.

[–] nous@programming.dev 30 points 6 months ago (1 children)

You mean the bribes?

[–] nous@programming.dev 15 points 7 months ago

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.

[–] nous@programming.dev 4 points 7 months ago

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.

[–] nous@programming.dev 14 points 7 months ago

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.

[–] nous@programming.dev 1 points 7 months ago

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.

view more: ‹ prev next ›