5 ms·

I've been using Go a lot recently as well, and it's rapidly become my go-to language (no pun intended) for a lot of problems, even when concurrency is not invol

I've been using Go a lot recently as well, and it's rapidly become my go-to language (no pun intended) for a lot of problems, even when concurrency is not involved. The biggest thing Go gives me is that it's really easy to manage code bases that grow organically - refactoring a project that grows from 50 LOC to 5000 LOC is almost painless in Go - no other language that I've seen has dealt with this aspect of code development so well.

alec 14y ago
What about Go makes it easy to manage and refactor large codebases? I don't do much Java, but whenever I've watched someone use Eclipse for refactoring, I question why I'm still using vim, because it is just magic and does everything for you.
- chimeracoder 14y ago
  I should probably write a blog post about this, because it's a combination of a number of things. Primarily, the compiler is incredibly strict and opinionated, so it's impossible to make certain small errors like assigning to lvalues that are never used, importing packages that are never used, etc. Secondarily, gofmt makes code very standardized and easy to skim. It takes Python's 'only one (obvious) way to do it' one or two steps further, by forcing everyone to to write their code the same way. This makes refactoring a lot easier because you don't need to read as much code each time in order to understand what's going on (or at least, you can mentally parse it much faster). Finally, the context-free grammar combined with a strong, static type system means that migrating code from an old (incompatible) version of Go to the most recent one can be done painlessly with the 'go fix' tool. This isn't your py2to3 tool - this accepts valid (old) Go code as input and reliably produces valid (up-to-date) Go code as the output. That last bit isn't actually used in refactoring manually, but I make note of it because very few languages give you anything close to this level of reliability with code modification, which speaks volumes about the design of the language's grammar.
  - crypto5 14y ago
    But go ecosystem still doesn't have anything even close to refactoring abilities of Java/C# IDEs. Say, move Java class which is in use in 100s places from one package to another is just few mouse clicks in Eclipse and a lot of pain in case of Go.
    - 4ad 14y ago
      Not really. Go comes with code rewriting tools, unsurprisingly since they were used to update the standard library and 3rd party code when the language changed before Go 1. I don't want to use a language that doesn't come with a parser in the standard library anymore.
      - crypto5 14y ago
        So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?
        zemo 14y ago
        the gofmt tool has a replacement feature: `gofmt -r 'InitialName -> FinalName'`
        crypto5 14y ago
        Documentation looks quite incomplete(http://golang.org/cmd/gofmt/ http://golang.org/cmd/gofmt/). Will it change all imports and usages of class/method/field? Will it resolve all signature polymorphic calls?
        deleted 14y ago
        [deleted]
zacharypinter 14y ago
"The biggest thing Go gives me is that it's really easy to manage code bases that grow organically" Very interesting to hear. Any chance you could expand on this a bit more?
- chimeracoder 14y ago
  Unlike C++, Go enforces that its dependency graph be a DAG. This drastically reduces compilation time, but it also reduces the headache that comes with decoupling highly coupled code, because it restricts the extent to which your code can be messy to begin with. The package system also enforces (at compile-time) that every imported package be used (and also that every named identifier be defined, which most dynamic/interpreted languages can't do). This applies not just to imported packages, mind you, but to any lvalue - if you declare/assign to an lvalue that's never used as an rvalue later, you can't compile the program. That's really helpful when refactoring, because it makes it easy just to move a bunch of code between files, then follow the breadcrumb trail of compiler errors (not warnings!) to figure out what still needs to be fixed. The compiler won't tell you everything you need to do, but it's sort of like having a Roomba helping pick up after you while you clean your house manually. Yes, for those genius programmers who never makes any mistakes, this may not be much of an improvement. But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through, it takes a huge load off the mind.
  - danieldk 14y ago
    Unlike C++, Go enforces that its dependency graph be a DAG. In C++ header dependencies are also a DAG, since include guards prevent cycles (and multiple includes). What makes Go faster are a few things: (1) C++ headers contain templates, which are slot to compile; (2) Go only looks at direct imports and uses the compiled form of those imports, rather than recursing over their imports (again); (3) Go is simpler to parse; and (4) there is no overloading, so symbol/method resolving is simpler. I also think that the advantage is often overstated. C++ is a nightmare in this respect, C programs and libraries often compile very fast (on my current machines, running configure often takes much more time than the actual compilation), the same applies to e.g. Java code. That's really helpful when refactoring, And annoying for testing, the printf example has been beaten to death. (Yes, I know that you can add a line such as var use = fmt.Println). But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through It's always surprising how Go fans can sell a feature that any strong statically typed language always had (easy refactoring by letting the type system work) can sell as something unique and new ;).

alec 14y ago

What about Go makes it easy to manage and refactor large codebases? I don't do much Java, but whenever I've watched someone use Eclipse for refactoring, I question why I'm still using vim, because it is just magic and does everything for you.

chimeracoder 14y ago
I should probably write a blog post about this, because it's a combination of a number of things. Primarily, the compiler is incredibly strict and opinionated, so it's impossible to make certain small errors like assigning to lvalues that are never used, importing packages that are never used, etc. Secondarily, gofmt makes code very standardized and easy to skim. It takes Python's 'only one (obvious) way to do it' one or two steps further, by forcing everyone to to write their code the same way. This makes refactoring a lot easier because you don't need to read as much code each time in order to understand what's going on (or at least, you can mentally parse it much faster). Finally, the context-free grammar combined with a strong, static type system means that migrating code from an old (incompatible) version of Go to the most recent one can be done painlessly with the 'go fix' tool. This isn't your py2to3 tool - this accepts valid (old) Go code as input and reliably produces valid (up-to-date) Go code as the output. That last bit isn't actually used in refactoring manually, but I make note of it because very few languages give you anything close to this level of reliability with code modification, which speaks volumes about the design of the language's grammar.
- crypto5 14y ago
  But go ecosystem still doesn't have anything even close to refactoring abilities of Java/C# IDEs. Say, move Java class which is in use in 100s places from one package to another is just few mouse clicks in Eclipse and a lot of pain in case of Go.
  - 4ad 14y ago
    Not really. Go comes with code rewriting tools, unsurprisingly since they were used to update the standard library and 3rd party code when the language changed before Go 1. I don't want to use a language that doesn't come with a parser in the standard library anymore.
    - crypto5 14y ago
      So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?
      - zemo 14y ago
        the gofmt tool has a replacement feature: `gofmt -r 'InitialName -> FinalName'`
        crypto5 14y ago
        Documentation looks quite incomplete(http://golang.org/cmd/gofmt/ http://golang.org/cmd/gofmt/). Will it change all imports and usages of class/method/field? Will it resolve all signature polymorphic calls?
        deleted 14y ago
        [deleted]

zacharypinter 14y ago

"The biggest thing Go gives me is that it's really easy to manage code bases that grow organically" Very interesting to hear. Any chance you could expand on this a bit more?

chimeracoder 14y ago
Unlike C++, Go enforces that its dependency graph be a DAG. This drastically reduces compilation time, but it also reduces the headache that comes with decoupling highly coupled code, because it restricts the extent to which your code can be messy to begin with. The package system also enforces (at compile-time) that every imported package be used (and also that every named identifier be defined, which most dynamic/interpreted languages can't do). This applies not just to imported packages, mind you, but to any lvalue - if you declare/assign to an lvalue that's never used as an rvalue later, you can't compile the program. That's really helpful when refactoring, because it makes it easy just to move a bunch of code between files, then follow the breadcrumb trail of compiler errors (not warnings!) to figure out what still needs to be fixed. The compiler won't tell you everything you need to do, but it's sort of like having a Roomba helping pick up after you while you clean your house manually. Yes, for those genius programmers who never makes any mistakes, this may not be much of an improvement. But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through, it takes a huge load off the mind.
- danieldk 14y ago
  Unlike C++, Go enforces that its dependency graph be a DAG. In C++ header dependencies are also a DAG, since include guards prevent cycles (and multiple includes). What makes Go faster are a few things: (1) C++ headers contain templates, which are slot to compile; (2) Go only looks at direct imports and uses the compiled form of those imports, rather than recursing over their imports (again); (3) Go is simpler to parse; and (4) there is no overloading, so symbol/method resolving is simpler. I also think that the advantage is often overstated. C++ is a nightmare in this respect, C programs and libraries often compile very fast (on my current machines, running configure often takes much more time than the actual compilation), the same applies to e.g. Java code. That's really helpful when refactoring, And annoying for testing, the printf example has been beaten to death. (Yes, I know that you can add a line such as var use = fmt.Println). But for those of us who don't trust our human brains as much and want to be absolutely sure that these silly errors don't slip through It's always surprising how Go fans can sell a feature that any strong statically typed language always had (easy refactoring by letting the type system work) can sell as something unique and new ;).