5 ms·

Projects like these and their popularity are indicative of how unapproachable the Go development environment is to new users. One of the first things I did when

by Ruphin 10y ago

Projects like these and their popularity are indicative of how unapproachable the Go development environment is to new users. One of the first things I did when introducing Go at work is write a bunch of script that solved this exact issue for our team, and I suspect that a solution like this has been written a million times over already. I love the Go language but the development environment tooling is just awful (aside from some great things like gofmt). This requirement of having files in specific folders to be able to build, the (lack of a sane) vendoring system, both problems keep popping up and spawning new solutions over and over. There is no excuse for a modern language to force people to learn how to use the tools before they can even start using the language. Tools should work for the user, not the other way around. Other languages get this right, so why can't Go? Kudos to the author for spending some time to document and publish their solution to this specific issue. If these projects get enough traction, like govendor, perhaps the language authors will at some point incorporate the most popular solutions into the language platform. At least it'll save everyone else from rewriting the same tool.

bborud 10y ago
I started using Go last year and I was very pleased with how approachable and quick to learn it was. Including the tools. The role of $GOPATH was a bit new to me, but apart from that it has mostly been very smooth sailing. I'd be interested in reading a bit more about the problems you experienced. Can you recommend any articles or blog postings that describe what kinds of problems people tend to have?
- vbernat 10y ago
  People may just not want to have their source code into a special hierarchy where their own source code is mangled with the source code of the dependencies. I also use a Makefile to setup an ad hoc GOPATH to workaround this.
  - majewsky 10y ago
    Me too. I work under the assumption that a packager can just grab the tarball of the latest stable tag from the repo's releases page on Github, unpack it somewhere and `make && make install`. I converged upon the same approach of setting up an ad-hoc gopath.
    - bborud 10y ago
      I'm not a big fan of the make && make install route. I'm not thrilled about the GOPATH either. Not least because there is no really clean solution for actively developing code inside the GOPATH and working with GitHub. Also, I would have liked dependencies to be automatically downloaded and installed in a local cache rather than me having to crap it into the GOPATH by manually issuing a "go get". I had hoped we were done with that. But I can live with it because it requires no explanation to new developers on a project. Using some hack to "solve" problems means forcing developers to learn even more stuff before getting started on projects. And one might say "but it is only one small thing", but that has sort of been the mantra in the Java world. And it isn't so small when you spend 2 weeks learning Java and 5 years learning about the little small things that have been put in any non-trivial project.
      - majewsky 10y ago
        > But I can live with it because it requires no explanation to new developers on a project. Even if it does, I'm a big fan of still mentioning it in the README. For my Go projects, it's usually just one sentence: "This project is go-gettable, or you can make && make check && make install". Avoids a lot of useless confusion.
  - bborud 10y ago
    I can understand your problem. Thanks. Actually, I'm starting to think that the solution is to have per project GOPATH instead and build switching into the shell or the editor. Because messing with Makefiles is just about the last thing I'd like to do (it never stops there. it always escalates)
FiloSottile 10y ago
Then you'll be happy to hear that part of Russ Cox's 2017 resolutions [0] is to make the go tool work without GOPATH (worded in a way that essentially matches the hellogopher motto), and there's a nice proposal in that sense [1]. Moreover, an integrated package management tool to build the vendor folder is coming soon [2]. We're getting there, now that the problem is getting more understood! [0]: https://research.swtch.com/go2017 https://research.swtch.com/go2017 [1]: https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271 [2]: https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/ https://blog.gopheracademy.com/advent-2016/saga-go-dependenc...
- stouset 10y ago
  Why is go so late to the party on this? Other languages do not seem to have these kinds of problems. The more I experience go, the more I feel like the core team existed in a bubble away from the past 25 years of advancement in programming languages. They're stuck solving the problems they had with C, without the benefit of learning from or improving on any other modern languages or toolsets.
blablabla123 10y ago
The go command works pretty well for me since it exists. If you set GOROOT, GOPATH, PATH=$GOPATH/bin and place your projects into domain/dir/project then everything just works automagically. Without any script. >Other languages get this right, so why can't Go? Which one? I mean just compare this with other languages/systems that supposedly get it right, e.g. Java with Maven oder node.js with npm. They are complex monsters under the hood, ready to break for sometimes uncontrollable reasons. I really like the Go philosophy of being able to build and install cross-platform without any Makefile or even autoconf. As a developer I can choose whether to work with plain vi, Sublime or Eclipse with Go plugin. The only scripts I ended up writing were unit test automation (find -d . and then calling go test) and .deb pkg generation. IMHO the Go devs should rather communicate more why things are designed the way they are. Another often disputed feature is no generics. I really miss them as well, but maybe Go is just not well suited for every problem. Writing a linear algebra is probably better done in C++ or Scala than Go. Go is really good for building reliable Server software however.
- therein 10y ago
  > The go command works pretty well for me since it exists. If you set GOROOT, GOPATH, PATH=$GOPATH/bin and place your projects into domain/dir/project then everything just works automagically. Without any script. Yeah, it is really that simple. In my experience, most people are confused by this due to its simplicity. It feels like you missed a step or two coming from other toolchains.
laumars 10y ago
People are always quick to criticize GOPATH but when you look at other similar languages (not JIT "scripting" languages but competing ones like Java and C++) then Go is actually reasonably good in terms of the difficulty of its tools. I think the problem with Go is that it's attracted a lot of developers from languages like Python where you just install the runtime and a shebang at the top for the code then call it as if it were a native ELF. No AOT language can work that simply. But given a choice between makefiles and the Go CLI, I'd take the Go design every time.
- deleted 10y ago
  [deleted]
deleted 10y ago
[deleted]

by Ruphin 10y ago

bborud 10y ago

I started using Go last year and I was very pleased with how approachable and quick to learn it was. Including the tools. The role of $GOPATH was a bit new to me, but apart from that it has mostly been very smooth sailing. I'd be interested in reading a bit more about the problems you experienced. Can you recommend any articles or blog postings that describe what kinds of problems people tend to have?

vbernat 10y ago
People may just not want to have their source code into a special hierarchy where their own source code is mangled with the source code of the dependencies. I also use a Makefile to setup an ad hoc GOPATH to workaround this.
- majewsky 10y ago
  Me too. I work under the assumption that a packager can just grab the tarball of the latest stable tag from the repo's releases page on Github, unpack it somewhere and `make && make install`. I converged upon the same approach of setting up an ad-hoc gopath.
  - bborud 10y ago
    I'm not a big fan of the make && make install route. I'm not thrilled about the GOPATH either. Not least because there is no really clean solution for actively developing code inside the GOPATH and working with GitHub. Also, I would have liked dependencies to be automatically downloaded and installed in a local cache rather than me having to crap it into the GOPATH by manually issuing a "go get". I had hoped we were done with that. But I can live with it because it requires no explanation to new developers on a project. Using some hack to "solve" problems means forcing developers to learn even more stuff before getting started on projects. And one might say "but it is only one small thing", but that has sort of been the mantra in the Java world. And it isn't so small when you spend 2 weeks learning Java and 5 years learning about the little small things that have been put in any non-trivial project.
    - majewsky 10y ago
      > But I can live with it because it requires no explanation to new developers on a project. Even if it does, I'm a big fan of still mentioning it in the README. For my Go projects, it's usually just one sentence: "This project is go-gettable, or you can make && make check && make install". Avoids a lot of useless confusion.
- bborud 10y ago
  I can understand your problem. Thanks. Actually, I'm starting to think that the solution is to have per project GOPATH instead and build switching into the shell or the editor. Because messing with Makefiles is just about the last thing I'd like to do (it never stops there. it always escalates)

FiloSottile 10y ago

Then you'll be happy to hear that part of Russ Cox's 2017 resolutions [0] is to make the go tool work without GOPATH (worded in a way that essentially matches the hellogopher motto), and there's a nice proposal in that sense [1]. Moreover, an integrated package management tool to build the vendor folder is coming soon [2]. We're getting there, now that the problem is getting more understood! [0]: https://research.swtch.com/go2017 https://research.swtch.com/go2017 [1]: https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271 [2]: https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/ https://blog.gopheracademy.com/advent-2016/saga-go-dependenc...

stouset 10y ago
Why is go so late to the party on this? Other languages do not seem to have these kinds of problems. The more I experience go, the more I feel like the core team existed in a bubble away from the past 25 years of advancement in programming languages. They're stuck solving the problems they had with C, without the benefit of learning from or improving on any other modern languages or toolsets.

blablabla123 10y ago

The go command works pretty well for me since it exists. If you set GOROOT, GOPATH, PATH=$GOPATH/bin and place your projects into domain/dir/project then everything just works automagically. Without any script. >Other languages get this right, so why can't Go? Which one? I mean just compare this with other languages/systems that supposedly get it right, e.g. Java with Maven oder node.js with npm. They are complex monsters under the hood, ready to break for sometimes uncontrollable reasons. I really like the Go philosophy of being able to build and install cross-platform without any Makefile or even autoconf. As a developer I can choose whether to work with plain vi, Sublime or Eclipse with Go plugin. The only scripts I ended up writing were unit test automation (find -d . and then calling go test) and .deb pkg generation. IMHO the Go devs should rather communicate more why things are designed the way they are. Another often disputed feature is no generics. I really miss them as well, but maybe Go is just not well suited for every problem. Writing a linear algebra is probably better done in C++ or Scala than Go. Go is really good for building reliable Server software however.

therein 10y ago
> The go command works pretty well for me since it exists. If you set GOROOT, GOPATH, PATH=$GOPATH/bin and place your projects into domain/dir/project then everything just works automagically. Without any script. Yeah, it is really that simple. In my experience, most people are confused by this due to its simplicity. It feels like you missed a step or two coming from other toolchains.

laumars 10y ago

People are always quick to criticize GOPATH but when you look at other similar languages (not JIT "scripting" languages but competing ones like Java and C++) then Go is actually reasonably good in terms of the difficulty of its tools. I think the problem with Go is that it's attracted a lot of developers from languages like Python where you just install the runtime and a shebang at the top for the code then call it as if it were a native ELF. No AOT language can work that simply. But given a choice between makefiles and the Go CLI, I'd take the Go design every time.

deleted 10y ago
[deleted]

deleted 10y ago

[deleted]