Comment by danudey | Hacker News Reader

Comment by danudey | Hacker News Reader

Parent Full thread

I'm viewing this from outside of the ecosystem, but nothing I've seen from Go externally shows any sort of "thinking ahead", so much as "building what Google needs and wants to have".

This blog post is just one example of those kinds of issues, and it's just the most recent of such that I've read: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Things like no package management, no vendoring, importing modules directly from GitHub without any concept of versioning, the confusing mess that is $GOPATH, the awkward handling of errors, and so on. Lots of things that were fixed, but shouldn't have been broken in the first place.

Go certainly has use and functionality and benefits (goroutines sound awesome), but Go itself seems like kind of an awkward mess when viewed outside of the context of "internal Google tool".

Maybe not relevant to your actual point! But most of the things you mentioned aren't a problem anymore.

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

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.

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 :)

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.

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.

> Things like no package management, no vendoring, importing modules directly from GitHub without any concept of versioning, the confusing mess that is $GOPATH

You just said "no dependency management" 4 times in a row.

maybe you should try it ... what about that? I bet you will change your mind. Both posts that you have linked are pretty much: "meh... i need s.th. to complain about"-posts. I've never been really affected by the issues they are screaming so loud about and believe me, I did not only write some toy projects [1]

go is mega awesome and I love going back to the projects where I use it. It's a simple language that makes it very easy to write good code. And the library ecosystem is pretty good as well, especially when it comes to networking stuff.

[1] https://github.com/MarkusPfundstein/taylor

Note that they state "all things that have already been fixed". Did you use Go when these oversights were present?

I did. Contrary a point above, I vendored dependencies in Go in 2012 the old school way: copy them into a vendor directory. It worked fine for end-user binaries, and you didn't have to worry about painfully long builds like you can get doing that with C++.

The Go authors have explicitly stated they don't do things until they figure out the right way to do them. No language gets it all right out of the gate, but Go got pretty close with e.g. its standard library.

So he complains about stuff that is alread fixed? Shall we now go back to the first version of ffmpeg? Or php pre php5? or pre java 8? or C++ pre C++11?

Come on.

He should try golang and then come back instead of relying on blogposts to form his opinion

The argument being made is that Go's design isn't so much "forward thinking" as it is driven by Google's interests.

What they are not stating is that Go is a conservative language with a standard library hampered by that conservatism, nor are they making a judgment on the current state of the language.

If you are going to criticize someone's post, give them the respect of actually reading their argument, and not just writing a knee-jerk reaction.

Back in 1999/2000 Rob Pike responded to this comment.

You can read it https://slashdot.org/story/11794

He didn’t even need a time machine.

Reply on news.ycombinator.com