4 ms·

Maybe I'm in the minority but I would rather have resources devoted to improving compile times in 1.5+ versions vs. having golang work on arm. Isn't the best c

• vessenes 11y ago
  I, too, would like compile and lint times faster, ideally a lot faster. That said, the counterpoint is that cross-compilation is not something you can easily bolt on later -- if you aren't doing, and testing it along the way, you will never be able to add it back in. It needs to be there from the beginning and stay a first-class support goal, otherwise mistakes, good intentions and laziness will all yield a product that just can't easily make the leap back to solid cross compilation with no hassle.
• api 11y ago
  ARM is really important. It's probably the fastest growing architecture other than x86 where people use things like this. I'd also like to see Go on MIPS64, though probably less important than ARM.
  • 4ad 11y ago
    Both MIPS64, MIPS, and SPARC64 are in the works (some MIPS bits already merged in).
• tptacek 11y ago
  Really? I know 1.5 is slower than previous versions, but it's still by far the fastest compiler I've ever worked with.
  • bigdubs 11y ago
    In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.
    • nickysielicki 11y ago
      Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?
      • vox_mollis 11y ago
        Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling. It seems they accepted this sacrifice for some other unimportant feature* *edit: Looks as though the feature they sacrificed performance for was writing Go in Go.
        • tptacek 11y ago
          Compilation in Go remains lightning fast, again, faster than any other compiler I use; fast enough that it's sane to run the compiler every time I save a file so my editor can highlight the errors.
          • Locke1689 11y ago
            I think there are two schools of thought: 1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time. 2) Perf improvements should be "locked in" and not regressed, unless strenuously justified. I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against other compilers" but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification. I think both groups have valid points. I think (2) is especially good at preventing "perf creep" wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone's just slow, but they have no impetus to improve because they're still better than the competition.
            • vox_mollis 11y ago
• binarycrusader 11y ago
  Many of the contributions for the ports aren't from the Go team themselves, but from external contributors. Also, work is in progress to improve build times, although I don't know if that's an active focus, rather than just something that's being fixed as time permits. A few improvements have already gone back to the current development gate for a variety of cases. I think it's important to remember that development can be done in parallel, just because you see work being done on an area that isn't important to you doesn't mean that there isn't work being done on the area that's important to you as well. Some of these changes take a long time.
• diggan 11y ago
  > Isn't the best course usually to build a solid foundation, then branch out? Yes, and I think that is what they are doing. First build something stable. Then target a lot of platforms. Then optimize the language itself and also the build times.