5 ms·

When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way. - I have to source GOPATH in my rc files? Annoying. - File paths are network

by kortex 7y ago

When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way. - I have to source GOPATH in my rc files? Annoying. - File paths are network URI's? Ugly. - I have to deal with every err != nil? Verbose. But over time I've grown to love go more than almost any language (python is still bae, especially with type hints, and even then, it's close). - dependency pathing is a pain in most other languages. Singular source of truth is great (I've had virtualenvs leak and cmake do bizarre things when multiple libs are on the file tree) - host/paths are file/paths. I love this pattern now. It's just so obvious and natural. - ok the err != nil still drives me nuts. But it drives me to write things in a way where I don't need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces "the buck stops here" sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to

ShorsHammer 7y ago
installing or updating go is still a massive pain, it's mind-boggling why you'd have a modern language that behaves this way
- sagichmal 7y ago
  brew install go?
- ruffrey 7y ago
  I have not experienced problems installing or updating go in 5 years of use. What problems have you experienced?
  - ShorsHammer 7y ago
    Nor have I had problems, simply saying it is too much hassle for little gain so I rarely bother, whereas with other languages it is a breeze so I update all the time. Please document your workflow to update and compare it to other modern langs, it's all relative.
    - AlexCoventry 7y ago
      This workflow works fine for me: https://github.com/golang/go/wiki/Ubuntu https://github.com/golang/go/wiki/Ubuntu
      - ShorsHammer 7y ago
        Ok so for ubuntu (which has what desktop share again?) > _Add a 3rd party repository to apt_ > sudo add-apt-repository ppa:longsleep/golang-backports > sudo apt-get update > sudo apt-get install golang-go > Note that golang-go installs latest Go as default Go. If you do not want that, install golang-1.13 instead and use the binaries from /usr/lib/go-1.13/bin. > If that's too new for you, try: > $ sudo add-apt-repository ppa:gophers/archive > $ sudo apt-get update > $ sudo apt-get install golang-1.11-go Am I being trolled here? How would you compare this for both memorability and user experience compared to say "rustup update"? Please take a step back and look at that question without personal bias. Please!
        pushpop 7y ago
        That’s not really a fair comparison. This code is installing Go where as you’re assuming Rust is already installed in your example. Plus I’ve had way more issues with Rust versions than I have with Go. Ultimately though this all just a very small part of writing code in either language.
        herbstein 7y ago
        You're right, it's assuming Rust is installed since it's talking about updating the compiler. But let's install Rust instead then: `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh` Now you can `rustup install <version>` easily with everything taken care of. Of course, the latest stable release is automatically installed already. And Rust provides automatic install scripts for Windows, Mac, and Linux. Whereas Go is more involved than is expected for any modern language.
        7y ago
- nerdwaller 7y ago
  As far as I know, most new features are opt in - I’d be curious what issues you’ve seen? I recall one recent one that bit me in dependencies on private repos is the new mirror/sum where we need to `export GOPRIVATE=github.com/<us>`. In a way I’m thankful it was so simple, but while I figured out what happened I wasn’t very happy.
  - ShorsHammer 7y ago
    Go Modules are opt-in if you are trying to submit pr's? Either you use >1.13 or you don't submit the pr. I hate to be the rust shill but updating it is "rustup update" I dont have look anything up nor put in any effort, why exactly should a common process which will happen millions of times be so hard for Go to replicate? It's absurd and should be called out. Updating out of the box is a massive pain and I stand by that statement, it's hilarious how people get so defensive of what is absurdly poor UX for a modern language. Docs for anyone interested. You need to uninstall the previous version before going through this process. Again to reiterate, all it take in rust is "rustup update". https://golang.org/doc/install https://golang.org/doc/install
- thrwaway69 7y ago
  Have you tried using gvm? https://github.com/moovweb/gvm https://github.com/moovweb/gvm
gtycomb 7y ago
I am an average Go programmer, so I may not be deep into Go as you might be. However the mention of GOPATH catches my eye. All my issues with GOPATH went away for me when I started using the Go Modules: https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules. Also Go's approach to err is one the reasons I started gravitating to Go -- my old Go code is more readable because of the verbose (error as strings in my code) and hence easier to maintain. Go is a surprisingly practical language for distributed, system oriented, undertakings I'd say
- zbobet2012 7y ago
  I'm not going to lie, I never understood why the gopath was so hard for people until I saw a friend using it. The go developers where all unix heads, and as unix heads setting a path env variable was so natural it almost doesn't bear mentioning. A unix dev is going to follow the following flow: cd into the project i'm working on in the terminal (I use fasd for this) export my gopath from history (ctrl+r GOPATH=) launch emacs on the files I need develop However, many "younger" devs grewup with IDE's. They interact with a project by launching goland, which means mucking with this stuff isn't first class. Not that it adds much, just some food for thought on why GOPATH existed and you found it clunky.
fyfy18 7y ago
> dependency pathing is a pain in most other languages This has been a solved problem in the Ruby community for nearly a decade thanks to bundler. When I first started writing Ruby it had all the same problems as other languages, there were various attempts to solve it (similar to virtualenvs) but nothing really worked properly. Then bundler came along, and even from early releases it had pretty much figured it out. The way it works is by having a human generated manifest file with a list of libraries you think you need (Gemfile) and the tool will then fetch those libraries (they can be installed in a vendor directory or globally for the specific Ruby version). You don't need to specify versions or deps (but can if required), as when the tool runs it will generate another manifest file (Gemfile.lock) which lists the versions of all libraries and their dependencies. Both files should be committed, so when you coworker checks out the project they know they have the exact same versions as you. There's another command to list outdated libraries, and to upgrade all or a specific library later. The tooling checks the versions of libraries on every execution (unlike npm or yarn) and spits out an error if your local versions don't match the manifest. It automatically creates wrappers around binaries so you don't need to prefix commands from other tooling. There's built in support for installation in a deployment environment, so you don't install testing libraries there. Together with tools like rvm/rbenv, it makes managing multiple Ruby versions and multiple projects, just work. https://www.cloudcity.io/blog/2015/07/10/how-bundler-works-a-history-of-ruby-dependency-management/ https://www.cloudcity.io/blog/2015/07/10/how-bundler-works-a...
- nazka 7y ago
  Do you know if python or rust have something similar?
  - agersant 7y ago
    I don't know about Python but the standard Rust dependency management solution (Cargo) is extremely similar.
    - richardwhiuk 7y ago
      Rust was inspired by Ruby's Gemfile. Python is starting to make strides with Poetry but generally packaging Python is an exercise in pain.
lloeki 7y ago
> which is resiliant and is where most errors bubble up to a.k.a Pokémon exception handling? (gotta catch'em all)
crimsonalucard 7y ago
>- ok the err != nil still drives me nuts. But it drives me to write things in a way where I don't need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces "the buck stops here" sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to This was actually a huge flaw in the design of go. The way forward for this type of thing was sum types but go failed to implement this modern programming concept hence why your stuck with it. See how rust handles errors... that is the proper way.

by kortex 7y ago

ShorsHammer 7y ago

installing or updating go is still a massive pain, it's mind-boggling why you'd have a modern language that behaves this way

sagichmal 7y ago
brew install go?
ruffrey 7y ago
I have not experienced problems installing or updating go in 5 years of use. What problems have you experienced?
- ShorsHammer 7y ago
  Nor have I had problems, simply saying it is too much hassle for little gain so I rarely bother, whereas with other languages it is a breeze so I update all the time. Please document your workflow to update and compare it to other modern langs, it's all relative.
  - AlexCoventry 7y ago
    This workflow works fine for me: https://github.com/golang/go/wiki/Ubuntu https://github.com/golang/go/wiki/Ubuntu
    - ShorsHammer 7y ago
      Ok so for ubuntu (which has what desktop share again?) > _Add a 3rd party repository to apt_ > sudo add-apt-repository ppa:longsleep/golang-backports > sudo apt-get update > sudo apt-get install golang-go > Note that golang-go installs latest Go as default Go. If you do not want that, install golang-1.13 instead and use the binaries from /usr/lib/go-1.13/bin. > If that's too new for you, try: > $ sudo add-apt-repository ppa:gophers/archive > $ sudo apt-get update > $ sudo apt-get install golang-1.11-go Am I being trolled here? How would you compare this for both memorability and user experience compared to say "rustup update"? Please take a step back and look at that question without personal bias. Please!
      - pushpop 7y ago
        That’s not really a fair comparison. This code is installing Go where as you’re assuming Rust is already installed in your example. Plus I’ve had way more issues with Rust versions than I have with Go. Ultimately though this all just a very small part of writing code in either language.
        herbstein 7y ago
        You're right, it's assuming Rust is installed since it's talking about updating the compiler. But let's install Rust instead then: `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh` Now you can `rustup install <version>` easily with everything taken care of. Of course, the latest stable release is automatically installed already. And Rust provides automatic install scripts for Windows, Mac, and Linux. Whereas Go is more involved than is expected for any modern language.
        7y ago
nerdwaller 7y ago
As far as I know, most new features are opt in - I’d be curious what issues you’ve seen? I recall one recent one that bit me in dependencies on private repos is the new mirror/sum where we need to `export GOPRIVATE=github.com/<us>`. In a way I’m thankful it was so simple, but while I figured out what happened I wasn’t very happy.
- ShorsHammer 7y ago
  Go Modules are opt-in if you are trying to submit pr's? Either you use >1.13 or you don't submit the pr. I hate to be the rust shill but updating it is "rustup update" I dont have look anything up nor put in any effort, why exactly should a common process which will happen millions of times be so hard for Go to replicate? It's absurd and should be called out. Updating out of the box is a massive pain and I stand by that statement, it's hilarious how people get so defensive of what is absurdly poor UX for a modern language. Docs for anyone interested. You need to uninstall the previous version before going through this process. Again to reiterate, all it take in rust is "rustup update". https://golang.org/doc/install https://golang.org/doc/install
thrwaway69 7y ago
Have you tried using gvm? https://github.com/moovweb/gvm https://github.com/moovweb/gvm

gtycomb 7y ago

I am an average Go programmer, so I may not be deep into Go as you might be. However the mention of GOPATH catches my eye. All my issues with GOPATH went away for me when I started using the Go Modules: https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules. Also Go's approach to err is one the reasons I started gravitating to Go -- my old Go code is more readable because of the verbose (error as strings in my code) and hence easier to maintain. Go is a surprisingly practical language for distributed, system oriented, undertakings I'd say

zbobet2012 7y ago
I'm not going to lie, I never understood why the gopath was so hard for people until I saw a friend using it. The go developers where all unix heads, and as unix heads setting a path env variable was so natural it almost doesn't bear mentioning. A unix dev is going to follow the following flow: cd into the project i'm working on in the terminal (I use fasd for this) export my gopath from history (ctrl+r GOPATH=) launch emacs on the files I need develop However, many "younger" devs grewup with IDE's. They interact with a project by launching goland, which means mucking with this stuff isn't first class. Not that it adds much, just some food for thought on why GOPATH existed and you found it clunky.

fyfy18 7y ago

> dependency pathing is a pain in most other languages This has been a solved problem in the Ruby community for nearly a decade thanks to bundler. When I first started writing Ruby it had all the same problems as other languages, there were various attempts to solve it (similar to virtualenvs) but nothing really worked properly. Then bundler came along, and even from early releases it had pretty much figured it out. The way it works is by having a human generated manifest file with a list of libraries you think you need (Gemfile) and the tool will then fetch those libraries (they can be installed in a vendor directory or globally for the specific Ruby version). You don't need to specify versions or deps (but can if required), as when the tool runs it will generate another manifest file (Gemfile.lock) which lists the versions of all libraries and their dependencies. Both files should be committed, so when you coworker checks out the project they know they have the exact same versions as you. There's another command to list outdated libraries, and to upgrade all or a specific library later. The tooling checks the versions of libraries on every execution (unlike npm or yarn) and spits out an error if your local versions don't match the manifest. It automatically creates wrappers around binaries so you don't need to prefix commands from other tooling. There's built in support for installation in a deployment environment, so you don't install testing libraries there. Together with tools like rvm/rbenv, it makes managing multiple Ruby versions and multiple projects, just work. https://www.cloudcity.io/blog/2015/07/10/how-bundler-works-a-history-of-ruby-dependency-management/ https://www.cloudcity.io/blog/2015/07/10/how-bundler-works-a...

nazka 7y ago
Do you know if python or rust have something similar?
- agersant 7y ago
  I don't know about Python but the standard Rust dependency management solution (Cargo) is extremely similar.
  - richardwhiuk 7y ago
    Rust was inspired by Ruby's Gemfile. Python is starting to make strides with Poetry but generally packaging Python is an exercise in pain.

lloeki 7y ago

> which is resiliant and is where most errors bubble up to a.k.a Pokémon exception handling? (gotta catch'em all)

crimsonalucard 7y ago

>- ok the err != nil still drives me nuts. But it drives me to write things in a way where I don't need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces "the buck stops here" sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to This was actually a huge flaw in the design of go. The way forward for this type of thing was sum types but go failed to implement this modern programming concept hence why your stuck with it. See how rust handles errors... that is the proper way.