6 ms·

This is what really struck me: "The API is still a bit awkward by Go standards. Too many methods, not enough direct access to variables" Does he really mean tha

This is what really struck me: "The API is still a bit awkward by Go standards. Too many methods, not enough direct access to variables" Does he really mean that proper go code has direct access to fields rather than encapsulating them???

Scaevolus 9y ago
Yes. If you have a struct, getters/setters are somewhat pointless, since member visibility control is only package level (protected/public depending on variable name capitalization). For interfaces, you can only invoke methods, so getters/setters are required.
- vvanders 9y ago
  Yup, getters/setters in POJOs drive me up the wall. So much simpler in languages that have proper const/mutability qualifiers.
  - fleshweasel 9y ago
    so..not Go :P
    - vvanders 9y ago
      Oh yeah, definitely not :)
  - krylon 9y ago
    > proper const/mutability qualifiers I really like Go, but on the const/mutability front, it does no better than C, unfortunately.
kjksf 9y ago
I would phrase it like that: most languages (C++/Java/.NET) have unhealthy obsession with creating unnecessary setters/getters, paying for it with increased compile time, code bloat, slower code. In Java/C# land refactoring tools even give one-click access to "create me some setters/getters". This is not to say that abstracting access with functions has no place, but if all they do is get/set the value, they are unnecessary.
- surye 9y ago
  C# and Python (for examples) don't use getters and setters, they use properties which provide the same interface as direct access variables when the need arises for more complexity, client code doesn't need to know about it. Languages without this feature needs to make everything getter/setter if they don't want to break the API when something needs additional logic.
  - fancy_pantser 9y ago
    Python does have properties, which work via decorators @property (which decorates a getter) and @foo.setter.
    - typon 9y ago
      He literally just said that
  - TazeTSchnitzel 9y ago
    And indeed Go code has its fair share of (otherwise) unnecessary getters because of this.
- taspeotis 9y ago
  > paying for it with increased compile time, code bloat, slower code. Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off. (Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.) As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...
  - zaroth 9y ago
coldtea 9y ago
>Does he really mean that proper go code has direct access to fields rather than encapsulating them??? Yeah, so?
valarauca1 9y ago
Encapsulation isn't _that_ useful. In Go it has real runtime cost as unlike C/C++ (you have an optimizing compiler) [1] , and in Java/C# you have the JIT which will optimize out your method calls over enough time. A lot of FP languages are perfectly fine building Abstractions without getters/setters. But in OOP land people believe this is a requirement. 2/4 OOP _principles_ encapsulation and inheritance have aged like dirty sweat socks in a hot gym locker. [1] https://klaig.blogspot.be/2012/09/the-go-language-is-faster-than-computer.html https://klaig.blogspot.be/2012/09/the-go-language-is-faster-...
- burntsushi 9y ago
  Take a look at the `time.Time` struct. It has a couple fields. What are the trade offs of making those fields public? (I contend that encapsulation is supremely useful, and the time package is a good exemplar.) Note that Go's compiler does do function inlining, so it might be possible to encapsulate your data without runtime costs. With that said, you certainly don't have the flexibility that you have in C/C++/Rust. Of course I agree that blindly adding getters/setters everywhere is bad juju. But to say encapsulation isn't useful is a step too far. Instead of thinking in terms of getters/setters, I'd rather think in terms of invariants on your data. If you have invariants you want to protect, then encapsulation is one possible tool you can use to protect them.
  - kartickv 9y ago
    He didn't say encapsulation is not useful. He said it's not that useful. In other words, blindly encapsulating everything because that's supposed to be the right way is overkill. Unless you're building an API.
    - burntsushi 9y ago
      > He didn't say encapsulation is not useful. He said it's not that useful. So look at my comment as a refinement on that idea?
- nine_k 9y ago

Scaevolus 9y ago

Yes. If you have a struct, getters/setters are somewhat pointless, since member visibility control is only package level (protected/public depending on variable name capitalization). For interfaces, you can only invoke methods, so getters/setters are required.

vvanders 9y ago
Yup, getters/setters in POJOs drive me up the wall. So much simpler in languages that have proper const/mutability qualifiers.
- fleshweasel 9y ago
  so..not Go :P
  - vvanders 9y ago
    Oh yeah, definitely not :)
- krylon 9y ago
  > proper const/mutability qualifiers I really like Go, but on the const/mutability front, it does no better than C, unfortunately.

kjksf 9y ago

I would phrase it like that: most languages (C++/Java/.NET) have unhealthy obsession with creating unnecessary setters/getters, paying for it with increased compile time, code bloat, slower code. In Java/C# land refactoring tools even give one-click access to "create me some setters/getters". This is not to say that abstracting access with functions has no place, but if all they do is get/set the value, they are unnecessary.

surye 9y ago
C# and Python (for examples) don't use getters and setters, they use properties which provide the same interface as direct access variables when the need arises for more complexity, client code doesn't need to know about it. Languages without this feature needs to make everything getter/setter if they don't want to break the API when something needs additional logic.
- fancy_pantser 9y ago
  Python does have properties, which work via decorators @property (which decorates a getter) and @foo.setter.
  - typon 9y ago
    He literally just said that
- TazeTSchnitzel 9y ago
  And indeed Go code has its fair share of (otherwise) unnecessary getters because of this.
taspeotis 9y ago
> paying for it with increased compile time, code bloat, slower code. Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off. (Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.) As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...
- zaroth 9y ago

coldtea 9y ago

>Does he really mean that proper go code has direct access to fields rather than encapsulating them??? Yeah, so?

valarauca1 9y ago

Encapsulation isn't _that_ useful. In Go it has real runtime cost as unlike C/C++ (you have an optimizing compiler) [1] , and in Java/C# you have the JIT which will optimize out your method calls over enough time. A lot of FP languages are perfectly fine building Abstractions without getters/setters. But in OOP land people believe this is a requirement. 2/4 OOP _principles_ encapsulation and inheritance have aged like dirty sweat socks in a hot gym locker. [1] https://klaig.blogspot.be/2012/09/the-go-language-is-faster-than-computer.html https://klaig.blogspot.be/2012/09/the-go-language-is-faster-...

burntsushi 9y ago
Take a look at the `time.Time` struct. It has a couple fields. What are the trade offs of making those fields public? (I contend that encapsulation is supremely useful, and the time package is a good exemplar.) Note that Go's compiler does do function inlining, so it might be possible to encapsulate your data without runtime costs. With that said, you certainly don't have the flexibility that you have in C/C++/Rust. Of course I agree that blindly adding getters/setters everywhere is bad juju. But to say encapsulation isn't useful is a step too far. Instead of thinking in terms of getters/setters, I'd rather think in terms of invariants on your data. If you have invariants you want to protect, then encapsulation is one possible tool you can use to protect them.
- kartickv 9y ago
  He didn't say encapsulation is not useful. He said it's not that useful. In other words, blindly encapsulating everything because that's supposed to be the right way is overkill. Unless you're building an API.
  - burntsushi 9y ago
    > He didn't say encapsulation is not useful. He said it's not that useful. So look at my comment as a refinement on that idea?
nine_k 9y ago