81–90 of 107 posts
I'm curious as to why they went with the monorepo approach. This might sound really stupid, but couldn't you just have a seperate repo for each team/service? My approach is to shove everything in $GOPATH/src.
This seems like an enormous amount of tooling complexity to simply have a few dependencies for your program.
The go vendoring stuff and GOPATH sounds like a complete nightmare to me. Also the fact that imports are full git URLS sounds totally crazy. Is `dep` fixing all that stuff? Last time I checked out go a few years ago, I didn't continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn't even `go get` a specific git tag or something. I'm happy that th…
What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.
With proper package names via a package manager, usually the name stays the same.
The go vendoring stuff and GOPATH sounds like a complete nightmare to me. Also the fact that imports are full git URLS sounds totally crazy. Is `dep` fixing all that stuff? Last time I checked out go a few years ago, I didn't continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn't even `go get` a specific git tag or something. I'm happy that th…
> The go vendoring stuff and GOPATH sounds like a complete nightmare to me. Also the fact that imports are full git URLS sounds totally crazy. It is. > Is `dep` fixing all that stuff? Not from what I can tell; it lets you pin to git tags and branches, but the only versioning you'll get beyond that is if the maintainer of your dependency is gracious enough to use tags. It certainly isn't changing the way import paths…
'dep' seems great for Noddy projects where all the code you are working on is in a single package, and fails (like most of the vendoring tools) when you need to work on multiple packages. It is has unfortunately been focused on vendoring at the package level rather than at the project level, and has many assumptions buried deeply into the code. The recommendation for larger projects is the 'vg' tool, which wraps 'dep' with some GOPATH tricks to help manage your dependencies at the project level.
The go vendoring stuff and GOPATH sounds like a complete nightmare to me. Also the fact that imports are full git URLS sounds totally crazy. Is `dep` fixing all that stuff? Last time I checked out go a few years ago, I didn't continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn't even `go get` a specific git tag or something. I'm happy that th…
What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.
Earlier quoted context omitted.
What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.
Managing vendoring yourself is impractical once you end up with more than a handful of dependencies, or once one of your dependencies pulls in more than a handful of transient dependencies. A larger project will have hundreds of dependencies and transient dependencies, and if you just pull them into your vendor directory and forget about them then you have a problem waiting to happen.
I prefer to be conservative about adding dependencies, and to always manually include them into the project.
Earlier quoted context omitted.
Managing vendoring yourself is impractical once you end up with more than a handful of dependencies, or once one of your dependencies pulls in more than a handful of transient dependencies. A larger project will have hundreds of dependencies and transient dependencies, and if you just pull them into your vendor directory and forget about them then you have a problem waiting to happen.
I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I prefer to be conservative about adding dependencies, and to always manually include them into the project.
Earlier quoted context omitted.
Well imagine you use language foo, bar and go. Go insists all code lives in ~/go/src and foo insists it all lives in ~/foo/source. Neither likes symlinks, which one wins? Also people like to keep other artefacts alongside source code like scripts, resources, templates, tools etc and often have an existing elaborate project structure in order to accommodate that. Go forces them to throw that out and use something unde…
Go doesn't insist that your code lives in ~/go/src. It can live anywhere beneath a directory of your choice. Note that there's no requirement that GOPATH contains only Go source code. You can put your scripts and resources, as well as other source code, right next to the Go sources. So you just put your code into ~/src/project/a.go and ~/src/project/b.foo (assuming a GOPATH=$HOME).
Earlier quoted context omitted.
Another possible reason: my understanding is that Go works really well for web apps (including the standard library covering http and templates), while Rust isn't as strong there. But I might just have seen less web-focused Rust; are there any good frameworks for web apps in Rust?
The first one I ever saw was iron ( https://github.com/iron/iron ) -- weirdly enough, it's not on the list @ https://crates.io/categories/web-programming::http-server . I wouldn't think that web frameworks were the reason -- at this point, almost all the frameworks that aren't django/rails size are the same, set up a route, add a handler, do whatever you need to in the handler, start the server. python's flask/ruby's…