Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

Especially given I just commented on another thread that I was surprised at a suggestion Go might “become the next PHP”, these are much more compelling complaints than what I usually encounter.

I’m not a Go dev so I only have a fuzzy view into the actual dev experience. But I would never have imagined that you’re expected to make struct types public in order to return instances. That’s a baseline expectation of hiding implementation details right? Along with logging levels, I’m shocked that this is more painful than in typical JS/TS setups.

View on HN

> I would never have imagined that you’re expected to make struct types public in order to return instances

You can return unexported ("private") instances; for example this is perfectly valid:

  type unexport struct {
      Str string
  }
  
  func (unexport) Method() string { return "export" }
  
  func NewUnexport() unexport {
      return unexport{Str: "asd"}
  }

And you can get/set the exported Str field from another package without problems, as well as call the exported Method.

You don't even need to make an unexport package type and can use an anonymous struct or type declared in the function too, although you can't add any methods like this and is often cumbersome because you need to declare the anonymous struct more than one.

And, of course, you can make parts of a struct private by just not exporting them. It's really not all that different to how OOP languages work with public/private, except that visibility is dictated in the name itself.

You can make the type itself public without making the fields public. This means someone could hypothetically create one of your structs without using the "New" function you provide, but it's not an issue in practice. And if you really want to avoid exporting your struct at all, you can always just return an interface.

> And if you really want to avoid exporting your struct at all, you can always just return an interface.

This is what I think most TypeScript libraries should be doing, but every bit of inertia makes it unlikely. In all honesty I think type systems should be designed around contracts/protocols and make concrete types private by default. Sure it’s a lot of ceremony, but it’s less ceremony than human communication in emails and issue threads to clarify that undocumented features are undocumented on purpose.

Reply on news.ycombinator.com