91–100 of 117 posts
Earlier quoted context omitted.
This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.
That’s, like, the opposite of npm though. It does dependencies per project, versioning, and does not impose any filesystem restrictions. Not that it doesn’t have issues.
It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…
It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use. Not that it justifies any pain, just found it to be a pleasant side-effect. Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lesson…
Earlier quoted context omitted.
Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one. And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.
Irrelevant
Surely not the the discussion here, which is about "how to start a Go project in 2018" -- or the subthread, about the kind of tooling Go lacks.
Couple of quick notes from my phone, as a googler gopher: - IIRC package management was historically left to the community to solve for, rather than the go maintainers mandating how package mgmt should be done. Many languages have followed this model. I've never heard of it having to do anything with our mono repo model. The community never ended up standardizing on a model; since then, the go team has endorsed godep…
If I may ask, how do you handle the use of other languages within a project that uses Go? I am new to Go, so it might be a silly question. I currently have a project that uses Node and React for the front-end and Go for streaming and scraping large .xml + .json data due to its great standard library. With Node I can start a project wherever I would like — e.g. D:/work/node_project. Go seems to be much more opinionate…
Here is a boilerplate Go Lambda app with a Node Lambda function and a static Vue app:
Earlier quoted context omitted.
I've been using `scratch` final builds .- FROM golang:1.10 WORKDIR /go/src/bitbucket.code.company-name.com.au/scm/code COPY ./ ./ RUN CGO_ENABLED=0 go build -a -installsuffix cgo -o /dist/main . FROM scratch COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=0 /go/src/bitbucket.code.company-name.com.au/scm/code/dist/main / ENTRYPOINT ["/main"] It requires a bit more "magic", but is a smaller…
Serious question: Why do you need Docker for a Go project? Cant you build it, and copy the binaries over to the host you want to run it on?
It feels so good to skip over all the Docker tools, config and services to build a Go app.
I wrote up more details here:
https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...
Earlier quoted context omitted.
Except Cargo, none of these are default toolings and were made by the community.
Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one. And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.
Earlier quoted context omitted.
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
It's still a bit new, but I think pipenv [1] is the new standard now. No need to directly work with pip or virtualenv anymore, and the equivalent requirements file works more like npm/yarn. [1] https://github.com/pypa/pipenv
Out of morbid curiosity, what's the current answer for "how to pack up a Python program into a single executable/directory for Windows" now?
It’s a good thing that Go is such a good language, because getting started with it is downright PAINFUL compared to Ruby or Python.
I'm not sure that's particularly true. Getting started is easy: 1. Install go. 2. mkdir -p ~/go/src/yourproject 3. Start writing Go in yourproject. go build will build your code. go install will put your executable in ~/go/bin. When you need some code from github, run "go get" and don't worry about where it goes. You're just starting out.
Compare getting started with Python: 1. Install python. 2. Create your project directory anywhere you like. 3. Start writing python. Python will run your code. pip will install libraries if you ask for them. Don't worry about where they are going, you're just starting out.
Other than "choice of directory" that's not very different.
Industrial-strength dependency management is harder than that, but you can retrofit it on later quite easily in Go. Both dep and vgo (from personal experience, I assume others too) can examine a project that is a mess of hand-vendored directories and references to the general package space and extract out a manifest file for you, which is probably exactly what you want, since it will reflect the current project.
It may actually even be easier than Python here, since Go source can be examined and the exact packages you are using confidently and accurately plucked out; I don't recall if pip has a "just examine this directory and freeze its exact dependencies" command and blew out my "HN comment time budget" trying to google the answer. In Go, you can just cruise along for a long time, using dozens of packages, and drop dep or vgo in at the last minute and get functional dependency management on your existing project in one command. I've converted two projects that ended up using over 30 packages (at least a middlin' size in the Go world) each to dep in the ~5 minutes it took "dep init". (It checks things out fresh, so that's mostly source code retrieval.)
Earlier quoted context omitted.
It's still a bit new, but I think pipenv [1] is the new standard now. No need to directly work with pip or virtualenv anymore, and the equivalent requirements file works more like npm/yarn. [1] https://github.com/pypa/pipenv
With all due respect to the Python community, and without intending this as an insult per se, if this really is the "current recommendation", the Python community is in no position to be criticizing the Go community on this point. This is about the fourth answer I've heard in the past 10 years. I've been programming off and on in Python for at least 15 years and I've never heard of this tool. Out of morbid curiosity,…
What does your comment add to the discussion other than snark and aggression?