4 ms·
Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the
by t43562 5y ago
Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot.
I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting services and have something that operates in a simple and predictable manner like C includes and include paths (although obviously I don't like preprocessing so not that).
As for the language, I like the range reference idea but my own minor pet peeve is an issue with pre-assignment in if-statements etc which makes a neat feature almost useless:
// This is nice because err only exists within the if so we don't have to
// reuse a variable or invent new names both of which are untidy and have potential
// to cause errors (esp when copy-pasting):
if err := someoperation(); err != nil; {
// Handle the error
}
// This however won't work:
func doThing() string {
result := "OK"
if result, err := somethingelse(); err != nil { // result does not need to be created but err does so we cannot do this.
return "ERROR"
}
return result
}
I don't have any good ideas about how to change the syntax unfortunately.
- fastest963 5y agoYou should be able to use "replace" to use your forked module instead of the original and you don't have to change anything.
- jatone 5y agounfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.
- cube2222 5y agoI've been doing forks of modules and using replace to use them in my code base extensively. I had 0 problems, it works marvelously. If you're doing some kind of global find/replace on fork, then something's definitely not right.
- infogulch 5y agoYou mean this? https://thewebivore.com/using-replace-in-go-mod-to-point-to-your-local-module/ https://thewebivore.com/using-replace-in-go-mod-to-point-to-...
- jatone 5y agoyes. now try to go install your application with the replace directive. it will silently replace the code with the original upstream version.
- jatone 5y agoyeah it sucks, I think IDEs should help here. 1 click uplift var error to parent scope.
- assbuttbuttass 5y agoThe fix is pretty simple, just declare err ahead of time: func doThing() string { result := "OK" var err error if result, err = somethingelse(); err != nil { return "ERROR" } return result }
- rocqua 5y agoPart of the reason OP liked the `if assignment` was to avoid polluting the higher-level scope with a variable that is only needed during the if statement. Your solution fixes the error, but at the cost of losing the upside OP saw.
- jaggederest 5y agoIs there no equivalent to a lexical scope let definition? let { var err := error scoped code }
- usrbinbash 5y agoOf course there is: { var err error scoped code }
- ptomato 5y agoyes, you can wrap code in {} to scope it.
- Gwypaas 5y agoThe issue is now you have a potential nil value hanging around in the code with no real reason for its existence. Three refactors and some moving around later and you manage to hit a runtime panic in production.
- usrbinbash 5y agoEasily fixed using lexical scopes: func doThing() string { result := "OK" { var err error if result, err = somethingElse(); err != nil { return "ERROR" } } return result } `err` is introduced in the lexical scope, `result` isn't so it still refers to the string from the surrounding scope. `err` does not pollute the surrounding scope. You can also try the complete version here: https://go.dev/play/p/kDEB11YdvSs https://go.dev/play/p/kDEB11YdvSs
- travisd 5y agoIn my experience this isn’t idiomatic Go and would definitely turn heads in a code review. But in such a small function, it’s fine to just not worry about the lifetime of your variables (and in bigger functions you can often decompose into smaller functions).
- usrbinbash 5y agoI agree. The idiomatic thing here would be to simply declare `var err error` in the surrounding scope, especially since this example is a small function where this wouldn't matter. But "idiomatic" always takes a backseat compared to technical necessity. If there is a requirement, for some reason, to limit the scope of `err` and still allow `result` to be changed in the if's pre-assignment, then this is the way to do it.