5 ms·

agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually an

by spotman 12y ago

agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang without all these abstractions and "elegant" ways to do things. (than some languages like java) yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity. at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.

danieldk 12y ago
agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang You think this that functions returning interface{} are easier to debug than functions that return a specific type? Because that's exactly what you are throwing away with generics. Allowing specification of the element type of a container data structure is not unnecessary abstraction, it's type safety!
- howeyc 12y ago
  It's more than likely the function will return an object of type blah type interface blah { behavior() }
  - danieldk 12y ago
    Not in a container, where generics are typically used. Of course, blah could be an interface requiring a comparison or hash method, but the effective result is the same: you have to do reflection to find out what is in the container, there are no compile-time guarantees.
- spotman 12y ago
  while that's an example that I do see in the wild, not every function returns interface. but it doesn't really hurt my argument. if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code. with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
  - danieldk 12y ago
    with java I find its so once you get through the factories, abstractions, and more Most of the typical design patterns do not hinge on generics or even inheritance and can be implemented easily in Go too.
threeseed 12y ago
Amusing that you talk about production support considering Go is by comparison a bit of a joke compared to the JVM. I can get detailed remote metrics through JMX and introspect running code with Java Agent tools like New Relic or AppDynamics. I completely get what you mean about Go being simplistic and easier to reason than your typical J2EE app. But remember you don't have to write your Java apps that way. Unfortunately "design patterns" took off a decade ago and ended up dragging Java and many other languages into the complexity quicksand. I hope Go learns from these lessons as it matures.
- spotman 12y ago
  "you don't have to write you apps this way" , but that's the point in making , is that the culture and parts surrounding Java, which I end up having to support and debug as part of the job, I don't get to use my time machine to go back and fix it. I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling. but, without that tooling I would be really paddling upstream. call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.

by spotman 12y ago

danieldk 12y ago

agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang You think this that functions returning interface{} are easier to debug than functions that return a specific type? Because that's exactly what you are throwing away with generics. Allowing specification of the element type of a container data structure is not unnecessary abstraction, it's type safety!

howeyc 12y ago
It's more than likely the function will return an object of type blah type interface blah { behavior() }
- danieldk 12y ago
  Not in a container, where generics are typically used. Of course, blah could be an interface requiring a comparison or hash method, but the effective result is the same: you have to do reflection to find out what is in the container, there are no compile-time guarantees.
spotman 12y ago
while that's an example that I do see in the wild, not every function returns interface. but it doesn't really hurt my argument. if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code. with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
- danieldk 12y ago
  with java I find its so once you get through the factories, abstractions, and more Most of the typical design patterns do not hinge on generics or even inheritance and can be implemented easily in Go too.

threeseed 12y ago

Amusing that you talk about production support considering Go is by comparison a bit of a joke compared to the JVM. I can get detailed remote metrics through JMX and introspect running code with Java Agent tools like New Relic or AppDynamics. I completely get what you mean about Go being simplistic and easier to reason than your typical J2EE app. But remember you don't have to write your Java apps that way. Unfortunately "design patterns" took off a decade ago and ended up dragging Java and many other languages into the complexity quicksand. I hope Go learns from these lessons as it matures.

spotman 12y ago
"you don't have to write you apps this way" , but that's the point in making , is that the culture and parts surrounding Java, which I end up having to support and debug as part of the job, I don't get to use my time machine to go back and fix it. I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling. but, without that tooling I would be really paddling upstream. call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.