Golang seems to follow the 80/20 rule from the outset (or perhaps an even smaller proportion), which is perfectly fine. Some other languages' standardlibs try to offer a complete treatment of a particular problemspace from the start which is tricky to get right on first attempt. Those are the instances where developers complain about complex APIs, uneven abstractions, or the like.
However, one of the artifacts of a popular language having a lean-and-mean standard library is that custom code proliferates, and the Go community's distaste for frameworks (as opposed to libraries) means that the it's not just the business-specific edges of the code that's unique in each implementation (as you'd expect), but also a good amount of the plumbing and domain-specific control code and their immediate callers. In some other languages, where there's more of a culture for using a dependency to intentionally simplify your problem space in exchange for ceding control, this style would be derided as NIH.
The vendor's response here is a function of not only the vendor's own rationale and priorities, but also of the above developer philosophy. This is surprising to me, given that Go is an opinionated language, and yet opinionated third-party code driving your logic is frequently discouraged by its community.
On the other hand, the language maintainers' response was measured, proper, and commendable. They made a breaking change to an experimental API, and improved their product in the process.
Telnet does not support port forwarding, file transfer, host key authentication (trusted network ≠ trusted clients), etc., and is not installed by default on most systems. rsh only supports file transfer out of those, and is dead enough that it's not even in Homebrew.
Nor is there any reason not to use SSH just because you trust your network, except possibly performance of huge file transfers.
Well, I'd rather run something I know has limited security (eg rsh+/etc/hosts-allow over a closed vpn) than ssh without key verification - because then you throw out trust, and encryption without trust buys you very little. Or kerberized rsh/telnet.
As for port forwarding, if you trust the network, presumably you don't need forwarding? And for file transfer just use zmodem, or run rsync/ftp? (remember: you trust the network..).
I will admit that there's a minor convenience to be able to use one client/api/interface - but I'm not sure it's worth the tradeoff of suddenly not knowing if you should be trusting ssh to be actually secure, rather than just convenient.
Clearly the maintainers of the go package feel the same way (after some gentle prodding).
However, one of the artifacts of a popular language having a lean-and-mean standard library is that custom code proliferates, and the Go community's distaste for frameworks (as opposed to libraries) means that the it's not just the business-specific edges of the code that's unique in each implementation (as you'd expect), but also a good amount of the plumbing and domain-specific control code and their immediate callers. In some other languages, where there's more of a culture for using a dependency to intentionally simplify your problem space in exchange for ceding control, this style would be derided as NIH.
The vendor's response here is a function of not only the vendor's own rationale and priorities, but also of the above developer philosophy. This is surprising to me, given that Go is an opinionated language, and yet opinionated third-party code driving your logic is frequently discouraged by its community.
On the other hand, the language maintainers' response was measured, proper, and commendable. They made a breaking change to an experimental API, and improved their product in the process.