10 ms·

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

by ben_pr 9y ago

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 of magic and his comparison to C# sounds like a really good mix.

kasey_junk 9y ago
> 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.
- johnfn 9y ago
  When people say "magic", what they often mean is "code over here can effect the execution of code over there in an implicit way". Like in Ruby, I could conditionally monkey-patch a function into an object someone way over there was using, causing code to break. Other languages, like those with stronger type systems, will not allow this to happen.
  - brightball 9y ago
    Yea, monkey patching is helpful when dealing with a 3rd party library that needs to be tweaked 10 layers up the inheritance chain without having to change the object type all over the whole system. If it gets overused it causes problems but there are times when it is close to a miracle. That said, there is a reason ruby devs are so test conscious.
    - johnfn 9y ago
      Yeah - of course monkey patching has good uses :) The problem is that when you're trying to debug an issue, it's another thing that you'll have to remember - "is anyone monkey patching something in here?"
      - brightball 9y ago
        Yea, I can't work on Ruby codebases without something like Rubymine where I can jump straight to the declaration for that exact reason.
- voidlogic 9y ago
  Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn't obvious by its on-screen representation.
  - infogulch 9y ago
    I don't think that's quite right. E.g. if you do call a method, it's complexity is unknowable with only local context, so it can't be obvious. I would rewrite that to: > Magic is when the run or space time complexity of code is misleading by its on-screen representation. An apparent field access that is actually a method is misleading. Calling a method explicitly just directs you to check that method to know for sure.
    - voidlogic 9y ago
      I think we are on the same page.
      - infogulch 9y ago
        Yes, I'm just being pedantic about how you say it. :)
  - adamnemecek 9y ago
    So these will be made into functions with uncertain O complexity. How's this situation preferable?
    - grey-area 9y ago
      Most of the time in Go people use fields directly, so there is a clear difference between struct.Field and struct.Method(), struct.Field is preferred and you only have to worry about uncertain complexity if you see struct.Method(). The parent is saying in C# struct.Field might be a simple access or it might be a complex method.
- deleted 9y ago
  [deleted]
- systems 9y ago
  One way to look at it is, some languages, I would suggest, C, C++, Clojure When you start learning those languages, and then compare the code you write, to the code of popular major or standard libraries, they look completely different They say, that Go is different and special this way, in that advanced Go code, doesn't look all that different from average Go code Anyway, I can't really judge, I never looked or tried to learn Go, hence (They say)
- gatestone 9y ago
  Magic is when you access struct pointer members w/o the asterisk. ;-)
- NateDad 9y ago
  one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the + could in theory do anything. And what's bad about that is that it is deceptive. It's easy to miss the fact that this line might actually be doing something complex. It also means that if someone is looking at your code, they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code. This is one of the pieces of magic that I'm glad go doesn't have.
  - pjmlp 9y ago
    a := Sum (b, c) How can you be sure that Sum actually does a sum without looking at its implementation?
    - jy3 9y ago
      I think you are missing the point. Of course you can't assume what a function will do with certainty.
      - pjmlp 9y ago
        From CS point of view + is just a function name just like any other. A concept used in lambda calculus, introduced in computing since Lisp exists. Also part of abstract mathematics field, where operator symbols get defined for the proofs.
        sagichmal 9y ago
        > From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.
        9y ago
- lloeki 9y ago
  Rails is the epitome of the magic philosophy. Stuff "happens" through inference because you touched some part of the code (check out routes, foo_{url,path} methods, url_for, and passing some models as argument to those), or the database schema (defining accessors from DB fields or adding features when magic-imbued names are used, such as type, version or foo_id/foo_type). This makes one feel fast and powerful at first, but as the application grows one has to memorise all sorts of conventions and DSLs of Rails's as well as one's own, and this is more and more stuff the developers have to remember instead of being explicitly stated in the code. As the application grows in scope, it is bound to veer ever so slightly away from the Holy Conventional Way and trip onto something lurking in a dark corner, and that's where things start to break for seemingly no reason at all unless you want to dive deeper into the cave where dragons born out of someone's eagerness at being smart lie asleep. IOW "Magic" is wanting to achieve extreme generalisation through combined use of conventions and dynamic features of languages, which inevitably leads to gotchas†, corner cases, and pitfalls[0] as well as significant cognitive dead weight due to the very nature of its implicitness. † ever tried to mix STI, polymorphism and url_for? [0]: http://urbanautomaton.com/blog/2013/08/27/rails-autoloading-hell/ http://urbanautomaton.com/blog/2013/08/27/rails-autoloading-...
  - jd20 9y ago
    I've been pondering this topic lately, as I come back to Rails (seems every few years I'll write a Rails app on the side, and my brain has totally forgotten everything since last time): one other way to look at this "magic", is it makes programming feel "intuitive". Not sure how to do something, I often find I can just "guess" the right and most natural way, and the code will just work. For that reason, I always feel like I'm most productive when writing Ruby (I really love Go too, just for different reasons). I can totally see how the situation you describe would be frustrating too, I felt the same about Java annotations when they came out, and on massive code bases it could become a nightmare when used to the extreme. My own experience has been that Go scales very well to large code bases, I've never wanted to try the same with Rails.
    - dmix 9y ago
      I've had this same experience bouncing back to Rails for contract gigs. You always feel this temptation like you're missing out on 'real' programming, performance with low level code or super clever languages like Haskell or Clojure. But ultimately Rails is just a great programming experience for getting the job done. Despite it's faults and the problems with using 'magic' frameworks like Rails it's a really great language/framework for what it's meant to do. And it still is in 2017 despite what some people say (although Elixir/Phoenix is getting there if it can reach the scale of adoption as Rails). That's the end of the road lesson, that there's the right tools for different jobs. There is no 'perfect' solution. Not rabbit to keep chasing. Either way though it's still good to get exposure to as many different languages as possible (low level ala C, easily parallel-based languages ala Erlang, some lisps, typed languages like Haskell, dynamic FP ala clojure, etc).
- sreque 9y ago
  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 of how ridiculous things can be. Golang is making a huge mistake for not adding Generics. 99.9% of the complexity in a typical Java codebase has zero to do with generics and everything to do with the insane abuses of the JVM classloading system that the java community has subjected itself to, as well abuses of overly complex libraries like Spring and Hibernate. If the Java community allowed itself to write simple golang-like code the majority of the time, there'd be much less defection to golang in my opinion.
  - kasey_junk 9y ago
    There is nothing language specific or magic about those things. You could (and you will see people) write those things in go as the language starts getting more adoption. Go goes further and encourages code gen, so that will probably be the way you start seeing terrible frameworks being built. In any case, "configuration as code" doesn't seem like a good definition of "magic" to me.
    - sreque 9y ago
      My point exactly. The issue isn't java the language. The issue is the flexibility of the JVM runtime and how people are abusing it. Also, if load-time aspect-weaving and classpath-scanning-based autodiscovery don't count as magic to you, then not much will. Code generation at least has the huge, huge, humongous advantage that you have code on disk that you can read and debug. I also admire Racket's macro system for coming with IDE support for introspecting and debugging the code generated by macros. Macros are a much better design because they generally run at compile time and they generally only make local code transformations that are much easier to reason about, as opposed to the sweeping global changes a weaver will make.
- tptacek 9y ago
  I don't know about this axis of "magic vs. muggle" we're talking about, but for me the phenomenon we're talking about seems like it can best be described by the ease with which you can find the code that implements specific behavior. Go (and Java) are pretty good at this. Python is OK. Ruby is awful.
  - kasey_junk 9y ago
    This is true except in the case of structural satisfaction for interfaces. You can't trust a rename function in a IDE in go for instance due to this. And in the case of channel select behavior...and ranges over a channel...and the context object, etc. My point being "magic" seems to be code for "familiarity with the language and it's idioms". Which I'll grant might be easier in go because of how limiting it is.
tonyedgecombe 9y ago
> It appears to offer a lot with minimal complexity. Actually I think it offers little with minimal complexity.
- psiclops 9y ago
  Here's a blog post from Rob Pike about the design philosophies inherent in Go, and how that affected adoption from C/C++ developers vs. Python, Ruby, etc. https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

by ben_pr 9y ago

kasey_junk 9y ago

> 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.

johnfn 9y ago
When people say "magic", what they often mean is "code over here can effect the execution of code over there in an implicit way". Like in Ruby, I could conditionally monkey-patch a function into an object someone way over there was using, causing code to break. Other languages, like those with stronger type systems, will not allow this to happen.
- brightball 9y ago
  Yea, monkey patching is helpful when dealing with a 3rd party library that needs to be tweaked 10 layers up the inheritance chain without having to change the object type all over the whole system. If it gets overused it causes problems but there are times when it is close to a miracle. That said, there is a reason ruby devs are so test conscious.
  - johnfn 9y ago
    Yeah - of course monkey patching has good uses :) The problem is that when you're trying to debug an issue, it's another thing that you'll have to remember - "is anyone monkey patching something in here?"
    - brightball 9y ago
      Yea, I can't work on Ruby codebases without something like Rubymine where I can jump straight to the declaration for that exact reason.
voidlogic 9y ago
Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn't obvious by its on-screen representation.
- infogulch 9y ago
  I don't think that's quite right. E.g. if you do call a method, it's complexity is unknowable with only local context, so it can't be obvious. I would rewrite that to: > Magic is when the run or space time complexity of code is misleading by its on-screen representation. An apparent field access that is actually a method is misleading. Calling a method explicitly just directs you to check that method to know for sure.
  - voidlogic 9y ago
    I think we are on the same page.
    - infogulch 9y ago
      Yes, I'm just being pedantic about how you say it. :)
- adamnemecek 9y ago
  So these will be made into functions with uncertain O complexity. How's this situation preferable?
  - grey-area 9y ago
    Most of the time in Go people use fields directly, so there is a clear difference between struct.Field and struct.Method(), struct.Field is preferred and you only have to worry about uncertain complexity if you see struct.Method(). The parent is saying in C# struct.Field might be a simple access or it might be a complex method.
deleted 9y ago
[deleted]
systems 9y ago
One way to look at it is, some languages, I would suggest, C, C++, Clojure When you start learning those languages, and then compare the code you write, to the code of popular major or standard libraries, they look completely different They say, that Go is different and special this way, in that advanced Go code, doesn't look all that different from average Go code Anyway, I can't really judge, I never looked or tried to learn Go, hence (They say)
gatestone 9y ago
Magic is when you access struct pointer members w/o the asterisk. ;-)
NateDad 9y ago
one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the + could in theory do anything. And what's bad about that is that it is deceptive. It's easy to miss the fact that this line might actually be doing something complex. It also means that if someone is looking at your code, they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code. This is one of the pieces of magic that I'm glad go doesn't have.
- pjmlp 9y ago
  a := Sum (b, c) How can you be sure that Sum actually does a sum without looking at its implementation?
  - jy3 9y ago
    I think you are missing the point. Of course you can't assume what a function will do with certainty.
    - pjmlp 9y ago
      From CS point of view + is just a function name just like any other. A concept used in lambda calculus, introduced in computing since Lisp exists. Also part of abstract mathematics field, where operator symbols get defined for the proofs.
      - sagichmal 9y ago
        > From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.
        9y ago
lloeki 9y ago
Rails is the epitome of the magic philosophy. Stuff "happens" through inference because you touched some part of the code (check out routes, foo_{url,path} methods, url_for, and passing some models as argument to those), or the database schema (defining accessors from DB fields or adding features when magic-imbued names are used, such as type, version or foo_id/foo_type). This makes one feel fast and powerful at first, but as the application grows one has to memorise all sorts of conventions and DSLs of Rails's as well as one's own, and this is more and more stuff the developers have to remember instead of being explicitly stated in the code. As the application grows in scope, it is bound to veer ever so slightly away from the Holy Conventional Way and trip onto something lurking in a dark corner, and that's where things start to break for seemingly no reason at all unless you want to dive deeper into the cave where dragons born out of someone's eagerness at being smart lie asleep. IOW "Magic" is wanting to achieve extreme generalisation through combined use of conventions and dynamic features of languages, which inevitably leads to gotchas†, corner cases, and pitfalls[0] as well as significant cognitive dead weight due to the very nature of its implicitness. † ever tried to mix STI, polymorphism and url_for? [0]: http://urbanautomaton.com/blog/2013/08/27/rails-autoloading-hell/ http://urbanautomaton.com/blog/2013/08/27/rails-autoloading-...
- jd20 9y ago
  I've been pondering this topic lately, as I come back to Rails (seems every few years I'll write a Rails app on the side, and my brain has totally forgotten everything since last time): one other way to look at this "magic", is it makes programming feel "intuitive". Not sure how to do something, I often find I can just "guess" the right and most natural way, and the code will just work. For that reason, I always feel like I'm most productive when writing Ruby (I really love Go too, just for different reasons). I can totally see how the situation you describe would be frustrating too, I felt the same about Java annotations when they came out, and on massive code bases it could become a nightmare when used to the extreme. My own experience has been that Go scales very well to large code bases, I've never wanted to try the same with Rails.
  - dmix 9y ago
    I've had this same experience bouncing back to Rails for contract gigs. You always feel this temptation like you're missing out on 'real' programming, performance with low level code or super clever languages like Haskell or Clojure. But ultimately Rails is just a great programming experience for getting the job done. Despite it's faults and the problems with using 'magic' frameworks like Rails it's a really great language/framework for what it's meant to do. And it still is in 2017 despite what some people say (although Elixir/Phoenix is getting there if it can reach the scale of adoption as Rails). That's the end of the road lesson, that there's the right tools for different jobs. There is no 'perfect' solution. Not rabbit to keep chasing. Either way though it's still good to get exposure to as many different languages as possible (low level ala C, easily parallel-based languages ala Erlang, some lisps, typed languages like Haskell, dynamic FP ala clojure, etc).
sreque 9y ago
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 of how ridiculous things can be. Golang is making a huge mistake for not adding Generics. 99.9% of the complexity in a typical Java codebase has zero to do with generics and everything to do with the insane abuses of the JVM classloading system that the java community has subjected itself to, as well abuses of overly complex libraries like Spring and Hibernate. If the Java community allowed itself to write simple golang-like code the majority of the time, there'd be much less defection to golang in my opinion.
- kasey_junk 9y ago
  There is nothing language specific or magic about those things. You could (and you will see people) write those things in go as the language starts getting more adoption. Go goes further and encourages code gen, so that will probably be the way you start seeing terrible frameworks being built. In any case, "configuration as code" doesn't seem like a good definition of "magic" to me.
  - sreque 9y ago
    My point exactly. The issue isn't java the language. The issue is the flexibility of the JVM runtime and how people are abusing it. Also, if load-time aspect-weaving and classpath-scanning-based autodiscovery don't count as magic to you, then not much will. Code generation at least has the huge, huge, humongous advantage that you have code on disk that you can read and debug. I also admire Racket's macro system for coming with IDE support for introspecting and debugging the code generated by macros. Macros are a much better design because they generally run at compile time and they generally only make local code transformations that are much easier to reason about, as opposed to the sweeping global changes a weaver will make.
tptacek 9y ago
I don't know about this axis of "magic vs. muggle" we're talking about, but for me the phenomenon we're talking about seems like it can best be described by the ease with which you can find the code that implements specific behavior. Go (and Java) are pretty good at this. Python is OK. Ruby is awful.
- kasey_junk 9y ago
  This is true except in the case of structural satisfaction for interfaces. You can't trust a rename function in a IDE in go for instance due to this. And in the case of channel select behavior...and ranges over a channel...and the context object, etc. My point being "magic" seems to be code for "familiarity with the language and it's idioms". Which I'll grant might be easier in go because of how limiting it is.

tonyedgecombe 9y ago

> It appears to offer a lot with minimal complexity. Actually I think it offers little with minimal complexity.

psiclops 9y ago
Here's a blog post from Rob Pike about the design philosophies inherent in Go, and how that affected adoption from C/C++ developers vs. Python, Ruby, etc. https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...