Live data from Hacker News

Go 1.11 got me to stop ignoring Go

drewdevault.com

31–40 of 79 posts

Re: Go 1.11 got me to stop ignoring Go

#31

Earlier quoted context omitted.

He says it in the next sentence. "...but with GOPATH its opinions extended beyond my Go work and into the rest of my system. [...] I already have opinions about how to use my computer."

Not sure I agree with that statement. Yes Golang has an opinion on where it wants you to keep your go code but it dosen't effect the rest of your system, just your go work.

Sure, but there are 100 other languages out there that do the same thing as Go but don't have an opinion about the organization of my system. I'd rather just use one of those, and really I don't think I'm missing out on much by not using Go.

Re: Go 1.11 got me to stop ignoring Go

#32
post #15

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):

My preference is to do this, which I think is quite nice and easy to work with:

    def my_very_very_very_very_very_long_function_name(
            self,
            param1,
            param2,
            ):
        do_it()  # function body here.

Re: Go 1.11 got me to stop ignoring Go

#33
A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community.

Also, having helped a number of people now through their early days of the language it's also the one biggest thing by far that reliably confuses every single person. And I mean everyone — from first time programmers all the way up to people who've been in the industry for decades and are learning Go as their tenth language. Being forced to put files in certain places is incredibly non-intuitive because there's nothing else out there that requires it. I must have sent the Go documentation on workspaces [1] to two dozen different people at this point.

But on the other hand, once you've grasped the system and are using it, `GOPATH` is surprisingly not bad. It's always obvious where your dependencies are located and which versions are going to be used to build your project. Even better, it lets you very easily drop into those dependencies and add minor changes or debugging lines if you need to. This can be incredibly useful if you're trying to understand how one of them works or think that that you might have found a bug and trying to verify or patch it. A very powerful feature once you know about it.

The new Go modules seem good, and will be a huge improvement in lowering the barrier to entry for Go, but I'll miss the old `GOPATH` style of work at this point.

[1] https://golang.org/doc/code.html#Workspaces

Re: Go 1.11 got me to stop ignoring Go

#35
post #29
post #12

I whole heartedly agree with the author. While I disagree with GO's style guide and a ton of other choices - I don't mind following them since that's what the language requires. But it goes past that and wants me to organize everything my working directory just for it - it's absolutely crossing a line. While I didn't stop using Go because of GOPATH, it's one of those things that absolutely annoyed the crap out of me.…

That's funny, but since I started using Go, I now organize all projects under GOPATH, i.e. in `~/src/github.com/user/project`, no matter what language it is in. GOPATH and HOME are almost synonims now. I find it so much better experience than using tons of `~/Work`, `~/Projects`, `~/Code`, `~/SomeLang/` etc. as I used to have before.

I have been using something similar to ~/site/user/project for years and it worked well so far.

Re: Go 1.11 got me to stop ignoring Go

#36
My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity.

With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc.

Because of a lack of a constructor in Go, I can't do that and I need to continuously validate the data, which is annoying and a source of bugs. It can be said that this can be accomplished with interfaces but that's adding a lot of complexity to something that should be a lot easier to handle, in my opinion.

Re: Go 1.11 got me to stop ignoring Go

#37
post #12

I whole heartedly agree with the author. While I disagree with GO's style guide and a ton of other choices - I don't mind following them since that's what the language requires. But it goes past that and wants me to organize everything my working directory just for it - it's absolutely crossing a line. While I didn't stop using Go because of GOPATH, it's one of those things that absolutely annoyed the crap out of me.…

Is it really that hard to solve bad UX of GOPATH? When Go 1.0 came out I remember I couldn't care less about Rob Pike's thoughts on GOPATH and GOROOT and just made a tiny wrapper for go tool that was looking for src/ directory in my tree to populate GOPATH, starting with the current directory (sort of like git does with .git/ directory). And for GOROOT I used a path relative to the wrapper itself.

If you are investing time into learning a new language anyway, these things take very little time in comparison and definitely worth it.

Re: Go 1.11 got me to stop ignoring Go

#38

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because…

By authoring private structs with public constructors, you can get what you want out of this. Gets a bit messy with testing, but not impossible.

Re: Go 1.11 got me to stop ignoring Go

#39
post #34

But how did Go solve the GOPATH problem? He didn't say.

Go modules

FTA: "Go modules are great, and probably the single best module system I’ve used in any programming language. Go 1.11 took my biggest complaint and turned it into one of my biggest compliments."

https://github.com/golang/go/wiki/Modules

Re: Go 1.11 got me to stop ignoring Go

#40

Earlier quoted context omitted.

He says it in the next sentence. "...but with GOPATH its opinions extended beyond my Go work and into the rest of my system. [...] I already have opinions about how to use my computer."

Not sure I agree with that statement. Yes Golang has an opinion on where it wants you to keep your go code but it dosen't effect the rest of your system, just your go work.

Where I want to keep my code is not one of the things I grant the language the right to dictate - even if the code is written in that language.
Post reply on HN