I disagree about golang's crypto being good. It includes insecure functions like md5 and sha1 that have no place in a crypto library. They should be in some other part of the library (maybe add a "legacy" section) or just not included at all. The go stdlib crypto is also makes the (common) mistake of exposing unsafe primitives (like raw AES without a mode of operation needed to use it for encryption) at the top level of their various sections instead of a well-documented "unsafe" or "hazardous" section. And it's missing useful well-vetted high-performance options like AES-OCB (which recently went out of patent).

Well sha1 and md5 are used all over the place so supporting them makes a lot of sense.

Most of your points are related to documentation, and a bit patronizing.

For all I care most of the functionality is there, fast and reasonably well designed.

> crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..)

Indeed. I would almost put my neck above the parapet and say that in the 21st century any programming language worthy of its name should come with decent crypto out of the box.

Crypto is no longer an option these days.