I have a similar experience with Go in my spare time projects (very refreshing coming from a FORTRAN/C++ day job) which is a boon, but falls short of what the article describes. The way I interpreted it, even having to do the search in the first place is a problem to be solved. Being able to start typing "email" and have a context menu with functions available from a list of third-party libraries relating to email would be the goal. That way when you select "SendEmail()" in your code, it automatically pulls the library, installs the binary where it needs to be located (or pulls source and builds) without interrupting your workflow.
With package management systems standardized within a language (such as Go) the problem domain is reduced, but extending the solution across multiple languages sounds like another third-party tool than a language feature.
I actually don't see much of a problem with doing a web search for the available libraries. Maybe it would save me a few keystrokes to type "email" and be presented with some function signatures from different libraries, but I (and I'm sure most others) have a few heuristics for choosing a library that go beyond the SendEmail function signature.
For example, if I see that a repo hasn't been touched in 3 years, I'm probably not going to pull it into my project. If the setup required to use a library looks clunky, I'm likely to avoid it. If the documentation is dense and difficult to parse, I'd much prefer an alternative.
These are the problems that I don't see an automatic package-fetching IDE solving anytime soon. Not that it's beyond our capacity as developers to solve such problems, but because I doubt that the number (hundreds, easily) of hours it would take to develop such a solution would be justified the 10 minutes it might save a developer looking for a library. Also, it will be quite a while before the general faith in an IDE's ability to pick a good library for us is high enough that we'd trust it with such a responsibility. A mistake would easily cost more than the 10 minutes it saved, and given that computers can't even pick the right music for me with 100% accuracy, I don't see something like this being a reality anytime soon; and I'm fine with that. I'd rather we focus on solving real problems.
> With package management systems standardized within a language (such as Go) the problem domain is reduced
I postulate the problem domain changes. I don't have experience with Go's package management system or NuGet, but I do with PHP's Packagist (Composer packages).
Finding packages is easy; evaluating their quality, if they do what they claim, and how buggy they are.. not so much. The problem's shifted to become one of too many libraries for any task, most of which are a liability in any project.
With package management systems standardized within a language (such as Go) the problem domain is reduced, but extending the solution across multiple languages sounds like another third-party tool than a language feature.