Broken links in `BINDINGS.md` about raylib

[Peter0x44]

Shouldn't the link just be deleted if it's a 404? it's not actually useful to anyone.

[Peter0x44]

should there be a new list added to the top with "certified bindings"

I don't think this is a good idea. This implies reviewing the list every few months or so to see if the binding is still relevant, and encourages code churn. You can already look if the binding supports 5.0 to see if it's "maintained" enough to your liking.

My vote is for just removing the redundant options.

[raysan5]

@LiamM32 Thanks for notice it, feel free to send a PR with the required removals/updated links.

[LiamM32]

Shouldn't the link just be deleted if it's a 404? it's not actually useful to anyone.
Honestly, I think so. I only put it in the latter list thinking that this is what's considered standard procedure here, but I actually think it would be worth simply not listing anything that is not available. It's still listed in the DUB database (the package manager for D), but trying to retrieve the DUB package fails, probably because it was linked to the GitHub repository.

In fact, perhaps the primary list should exclude any binding when there's one for the same language considered clearly superior. I think making it easier to determine which binding one should use would better fit within the philosophy of Raylib.

But the question for that idea is, should there be a new list added to the top with "certified bindings", in which there is a maximum of one per language, and they must meet some standards, or should redundant options simply be removed from the main list?

[raysan5]

Just reviewed the links and removed the broken ones.

As a side note, this is a work than can be done by the person reporting it, instead of expecting someone else to do it.

[LiamM32]

As a side note, this is a work than can be done by the person reporting it, instead of expecting someone else to do it.

Yes. It was included in the PR that I sent. I thought the PR would be accepted, so I thought it wasn't so bad to combine them.

[raysan5]

@LiamM32 For the future, PRs addressing separate issues shouldn't be combined.

Also, the PR you mentioned only addressed one of the broken links, not all of them.