3.5 Years, 500k Lines of Go

Post by sreque » Fri, Mar 24, 2017, 7:13 PM UTC

kasey_junk wrote: post #29

ben_pr wrote: post #9

I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity. > Because Go has so little magic, I think this was easier than it would have been in other languages. You don’t have the magic that other languages have that can make seemingly simple lines of code have unexpected functionality. You never have to ask “how does this work?”, because it’s just plain old Go code. That lack…

> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

  * Complex DI frameworks (Spring Bean*Processors, event listeners, XML config)
  * classpath scanning-based autowiring (See Spring @Component)
  * aspect weaving-based autowiring (See Spring @Configurable)
  * Code littered with annotations that invite aspect-based pointcuts
  * Complex ORMs like hibernate that are incredibly difficult to use properly

Post by kasey_junk » Fri, Mar 24, 2017, 7:24 PM UTC

sreque wrote: post #181

kasey_junk wrote: post #29

Earlier quoted context omitted.

> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

Take a look at a java codebase that uses: * Complex DI frameworks (Spring Bean*Processors, event listeners, XML config) * classpath scanning-based autowiring (See Spring @Component) * aspect weaving-based autowiring (See Spring @Configurable) * Code littered with annotations that invite aspect-based pointcuts * Complex ORMs like hibernate that are incredibly difficult to use properly And you'll start to get an idea o…

Post by nemo1618 » Fri, Mar 24, 2017, 7:29 PM UTC

woah wrote: post #173

k__ wrote: post #79

Are generics really that big of a thing if you got structural typing? I mean, you don't have to implement all the interfaces explicitly, you just have to get your structure right and be done with it. Am I missing something?

I think generics would mostly be useful for container types, like putting methods on slices (like .map) without caring what's inside.

    // square a slice of ints in Go
    for x := range xs {
        x *= x
    }

    // square a slice of ints in Ply (morph == map)
    xs.morph(func(x int) int {
        return x*x
    })

    xs.map(x => x*x)

Post by kornish » Fri, Mar 24, 2017, 7:48 PM UTC

rbehrends wrote: post #159

schmichael wrote: post #151

I'm 3.5 years into using Go exclusively as well, and this rings very true to me with regard to generics: > Interfaces are good enough 99% of the time. Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that. Generics could allow for some nicer (and safer!) nil handling and error checking, but I think the benefits-vs-complexity are less clear than with generics…

> Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve. This is a common misunderstanding that occurs (I think) because most people only know C++-, Java-, and C#-style generics, which can be conceptually complicated, because of the often tricky interactions with the type system (or, in the case of C++, the use for metaprogr…

Post by AdieuToLogic » Fri, Mar 24, 2017, 8:02 PM UTC

rpeden wrote: post #157

johnfn wrote: post #38

Earlier quoted context omitted.

I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".

Over time, I've come to notice that once any online forum reaches a certain critical mass of programmers, nearly any mention of a specific programming language will devolve into a flamewar about that language. I find it frustrating, but I also suspect that it's been that case since approximately forever ago. One day I plan to don a flame retardant suit and wade into Usenet archives to see if programmers were as prone…

  ... if programmers were as prone to language
  flamewars 30+ years ago as they are now.

  I'm guessing the answer is probably yes. :)