Don't get me wrong, I'm not against disruption at all. It's just there're cases where doing this doesn't make sense. Write a new text editor, invent a new programming language, sure. But writing a new cryptography library? You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small.
Making things even worse is that you can't really write a crypto library without using C/assembly. So why write a new crypto library?
"You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small."
If that were true, then it would be a good counterpoint worthy of long thought. The reality of crypto libraries is that popular ones often had preventable errors due to bad coding and/or unsafe language that also took entirely too long to notice.
"you can't really write a crypto library without using C/assembly"
I'd argue you can't write a crypto library using C by default unless you're a really good coder. C is just an accident of two team's bad hardware:
Languages like Modula-3, Free Pascal, and even Fortran were easier to analyze to ascertain the program's properties. It's why Modula-3 had first, standard library verified free of specific types of errors. Also took years to make a certified compiler for C which had been done in other, simpler languages. Finally, the top performer in secure, systems code is SPARK as illustrated when re-implementing C crypto in it caught a problem.
Making things even worse is that you can't really write a crypto library without using C/assembly. So why write a new crypto library?