1. 23
  1.  

  2. 6

    This thread and particularly this post from Gil Tene at Azul has some good background on where precise GC will lead:

    https://groups.google.com/forum/#!msg/golang-dev/GvA0DaCI2BU/SmEelQsFybkJ

    1. 1

      I love self-hosting/bootstrapped systems, that’s a step in the right direction. But please, wake me up when you have generics. :)

      1. 1

        I wonder if there’s a way to handle the stack-splitting thrashing problem without eliminating stack segmentation. Stack copying seems like it will inevitably lead to arbitrarily-large pauses when you have arbitrarily-deep stacks.

        For example, once you’re capable of relocating the stack, you could relocate the top few stack frames to the new stack segment; or you could just keep the new stack segment allocated so that you can use it again inexpensively.

        This must be a problem that Chez Scheme has had, and they’ve had 30 years to figure out how to handle it, right? I wonder what they do.

        1. 1

          The decision to go fully native for a compiler is always interesting. At least they’re thinking about the bootstrapping problem (which is often overlooked until somebody can’t do it), and the possibility of a C generating backend that they can commit is great. Some other compiler projects require several years worth of old releases to be downloaded and built sequentially if you’re starting from scratch.

          The decision to use a machine translator from C to Go is also good, if tedious. Somebody on the team has learned you don’t just throw the old one out and build a new one. :)

          1. 1

            I just want to see it on Plan 9.

            Also, as for me “translating” the internals of Go compiler from C to Go, especially using an automated translator, is not the best decision. This code will be just a pile of human-non-readable strings and can serve only as a very termporary solution.

            I like the way Go changes. It’s not the “revolutionary”-flavoured development of languages such as Rust, but the soft evolution.

            1. 1

              I like the way Go changes.

              I like it too. I especially like Go being focused on solving very concrete problems in software development, and making programming productive and pleasant, instead of trying to be a breakthrough research project in language theory.

              It’s not the “revolutionary”-flavoured development of languages such as Rust, but the soft evolution.

              Yes and no. I’d say that some aspects are quite “revolutionary” (like the use of interfaces and structural typing instead of classes and inheritance, the builtin goroutines, the rejection of exceptions, the almost mandatory use of gofmt to avoid bikeshedding, the approach to dependency management, the use of defer, the explicit rejection of keyword arguments, etc.) and some are very conventional (one unique heap shared by all goroutines, garbage collection, mutable variables, etc.).