Implementing Standardized AES Algorithm -- Hopefully this question fits here --
Time and time again, there is always one person who asked about creating their own encryption standard/cipher, and we all agree to stop them early on because we all agree that it is very unwise to do so (such as preventing unknown or invisible weakness in their standard, etc.).
My curious question is: What about programming your own library of, let's say AES cipher, in your language of choice? It's not creating new cipher (still strictly adheres to AES cipher/algorithm), but just writing that algo in programming language of your choice (maybe do AES cipher again in C/C++ so we can use a new feature(s) built into new gen CPU and make it faster -&gt; JUST EXAMPLE) or someone built a new programming language that has no AES library yet (and you want to contribute one). Is it still wise to do so?
What about programming your own library of, let's say AES cipher, in your language of choice?

Implementing AES yourself in a correct way isn't too hard. The specification is well-written, contains illustrations and intermediate test vectors so that essentially anyone can do that.
What is tricky for AES and the reason why it's generally ill-advised to write a production-ready implementation yourself is to write an implementation that is reasonably fast and (/or) resistant to common software CPU side-channels.
If you still want your language to have an AES implementation the usual way to go would be to use the foreign function interface to call into a C-based AES library.
As for implementing AES yourself, if your language compiles to machine code there's usually a way to access intrinsics for AES and with those usually there is little that one could do wrong - apart from not properly allowing the CPU to pipeline the instructions.
If you don't have a machine-code-compiled language and / or your target CPU doesn't have hardware AES instructions things get more tricky. You need to ensure that whatever you write in your language doesn't do some weird things during interpretation / just-in-time compilation to accidentally introduce extra instructions. You need to ensure that the implementation always takes the same amount of time independent of the key and data used. You need to ensure that the previous step is not actually potentially messed up by the interpreter / JIT compiler / CPU. You also need to ensure that your memory access patterns do not depend on secret data. Most of these points can be fixed, e.g. using bitsliced AES implementations, but this is of course far from a trivial task - especially if you want the implementation to be reasonably fast.