Go 1.11 got me to stop ignoring Go

119 点作者 waits超过 6 年前

14 条评论

brandur超过 6 年前

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] <a href="https://golang.org/doc/code.html#Workspaces" rel="nofollow">https://golang.org/doc/code.html#Workspaces</a>

评论 #18179510 未加载

评论 #18179511 未加载

评论 #18180319 未加载

评论 #18179452 未加载

sebcat超过 6 年前

Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned.GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a service to 1 (I/O bound), reducing the costs for that service a lot. If you are willing to let the environment get in between that...Of course, you could have implemented that system using assembler for all I care, but Go really made it possible within that organization, something Java, C and other languages failed at before Go was introduced.N=1, ymmv, &c

评论 #18179695 未加载

评论 #18179878 未加载

sonaltr超过 6 年前

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.to the point that all my go projects are now organized as `project_name/go/src/github.com/username/project_name` as an example.This was really really annoying to say the least.

评论 #18179277 未加载

评论 #18179208 未加载

jerf超过 6 年前

If you read over the rest of this thread, you can find opinions ranging from "GOPATH is horrible" to "It's wonderful". And I just want to point out this is pretty good example of how important the marginal improvements can be. Abstractly, you might have a hard time sitting there imagining how for a thousand of your users, improving $ONE_SMALL_FEATURE might flip them from not paying you to paying you, but at scale, yes, such margin-based thinking really is important. Just like you may find it hard to really intuit that going from .75s page rendering to .5s page rendering can have a significant impact on the bottom line for an e-retailer, but, yeah, it does.Just wanted to point this out as a clear example of such an issue, since it doesn't come up very often so cleanly.

tingletech超过 6 年前

I guess go 1.11 introduced a modules experimental feature as an alternative to `GOPATH`> Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution. Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible. <a href="https://golang.org/doc/go1.11#modules" rel="nofollow">https://golang.org/doc/go1.11#modules</a>

symmitchry超过 6 年前

> 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?

评论 #18179077 未加载

评论 #18179203 未加载

评论 #18179124 未加载

docker_up超过 6 年前

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.

评论 #18179305 未加载

评论 #18179534 未加载

评论 #18184501 未加载

评论 #18179326 未加载

评论 #18179359 未加载

paxy超过 6 年前

I have used goinstall, go get (in GOPATH), godep, dep, multiple GOPATHs, symlinks, git submodules and lots more to figure out dependencies in Go, and modules is FINALLY something that actually makes sense.

neduma超过 6 年前

GOPATH issues - Elaborate more?

评论 #18179064 未加载

评论 #18179017 未加载

评论 #18178987 未加载

评论 #18178996 未加载

throw7超过 6 年前

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

评论 #18179307 未加载

floatboth超过 6 年前

I actually adopted GOPATH for everything. I use <a href="https://github.com/motemen/ghq" rel="nofollow">https://github.com/motemen/ghq</a> to quickly clone non-Go projects into the ~/src/github.com/user/project style paths.But… I don't like Go itself (anymore).It's not just the 'if err != nil', it's more the general attitude/philosophy from which it comes. Go is anti-intellectual, the designers basically don't respect the user. "You're too stupid to use generics/Result<A,B>/monads/whatever" is what it feels like they think of you.Go internals are more infuriating than Go language though…Especially the Plan9-based custom assembler. It truly is a horrific atrocity. I've had to deal with it two times:1. That assembler does not support all instructions and even addressing modes (!) of amd64, so people have had to create hacks like <a href="https://github.com/minio/c2goasm" rel="nofollow">https://github.com/minio/c2goasm</a> to run asm functions without the overhead of cgo. Please actually read that project's README, but tl;dr it assembles your code using a normal assembler and STICKS THE BINARY CODE INTO A GO ASSEMBLY FILE AS HEX CONSTANTS. This hack actually didn't work for me when I tried to use some SIMD code, so I had to resort to cgo with its call overhead.2. I also tried (and failed) to port the Go runtime to FreeBSD/aarch64. This was the last straw, this is what made me actually hate Go.

haolez超过 6 年前

Side note: I really liked the design of his blog.

xet7超过 6 年前

Yes, but how to do error handling correctly with Go? My Go code crashes.

sdinsn超过 6 年前

Server is down?