Re:File System Interfaces for Go – Draft Design
by codys on Wednesday August 05, 2020 @06:33PM
(#24066348)
The fact that go eventually fixed things doesn't really speak to the top-level comment on this thread that "The best thing about Go is how things are designed thinking ahead in the future and avoiding hypes."
That the things needed fixing (and especially in cases where there were previous ways of doing things that had to be entirely discarded) seems to go against the idea that there was thinking ahead in those areas.
Re:File System Interfaces for Go – Draft Design
by Sean-Der on Wednesday August 05, 2020 @06:46PM
(#24066431)
I think the 'In favor of Go' argument is that the Go authors defer decisions they don't know the answer for yet. They would rather leave something unimplemented, then do it the wrong way.
But maybe you are right and they didn't anticipate these issues! I have no idea either way :)
Re:File System Interfaces for Go – Draft Design
by infogulch on Thursday August 06, 2020 @01:15AM
(#24068301)
I appreciate the answer "I don't know" when it's the right answer. And I think the Go team is an excellent example of holding steady on "I don't know" until the answer arrives, despite all the flak they've received for taking their time. I also think the way they've decided to go about announcing/framing these recent drafts is smart; they're learning from the past.
Re:File System Interfaces for Go – Draft Design
by Gibbon1 on Wednesday August 05, 2020 @08:53PM
(#24067180)
You can compare golang's package/version management with .net's. It's obvious that the latter's designers got kicked in their delicate regions enough in the 90's that that they made it a first class priority from day one.
Probably doesn't help that at google when a package breaks they'll just force some faceless drone to make it work. And since they don't have customers in the traditional sense that works for them.
* no package management
I use Go Modules for Pion and really love them https://github.com/pion/webrtc/blob/master/go.mod I select the versions I want and everyone that downloads my code uses the proper version.
* No vendoring
Just do `go mod vendor` and you are done
* importing modules directly from GitHub without any concept of versioning
You set the versions in your `go.mod` file.
> Go itself seems like kind of an awkward mess when viewed outside of the context of "internal Google tool".
Go is actually really nice from a community standpoint. WebRTC is driven by Google and is magnitudes worse. I deal with a wonderful mix of arrogance and ignorance. I appreciate the great tech they bankroll and try not to let the other stuff bother me.