1. 8
  1.  

  2. 1

    When the process of making a change in your code base globally that is computable and able to be checked by your compiler is harder than creating a new concept for your language, you may have problems.

    Golang has an “import as” feature where you do import shortname "mylibraryhasasuperlongunusablename". This is how most other languages solve this so frankly I’m surprised if the alias proposal is taken seriously.

    1. [Comment removed by author]

      1. 0

        The problem is that the standard library is not vendored as all the other packages are?

        I’m insanely disappointed by this ginormous hack which will make callsites yet again a difficult thing to deduce.

        1. 1

          My comment was downvoted - fine - that’s what that comment deserved, and I can do better.

          One said it was incorrect though, and I’m curious what makes my comment incorrect? My understanding is now you need to load, parse, and find aliases in all dependent libraries to find out what anything.Anything actually calls in other packages.

      2. 2

        The main problem is the x/context package is being moved into the std library. This means all third party code bases must be globally updated to point to the new one at the same time. Alias allows the upstream to do this for everyone behind the scenes. It is not so trivial to “globally update a codebase”, when the codebase they are talking about is basically all the distributed go code that is out there.

        This problem would probably have been mitigated with a dependency management system from the beginning owever.