7 ms·

What i love about Go from a user of some of the open source apps like Gogs, is that its so easy to get the application running. A single binary with zero depen

What i love about Go from a user of some of the open source apps like Gogs, is that its so easy to get the application running. A single binary with zero dependancies is so awesome. With a ruby on rails app I need to worry about ruby version, ruby implementation, gem versions, compilation of C based gems, etc etc. With Go i simply copy up the binary and run it.

joe2010xtmf 12y ago
Thanks for your words, we really appreciate!
- lukeholder 12y ago
  Thanks for your work on Gogs! looks forward to seeing it grow. Would love to help out on the front end - let me know if you are needing any contributors.
  - joe2010xtmf 12y ago
    Hi there, how can I contact you? My e-mail is on the GitHub.
shurcooL 12y ago
I agree, that is one of my most favorite aspects of Go. go get -u github.com/go/project If you're writing native Go code, it doesn't matter if there's 0 or 1000+ dependencies, that one command will take care of everything. So there's no need to fear having extra dependencies, and you are welcome to reuse more code. Go takes the common parts of writing software and abstracts them away. Take any two distinct Go projects, and the only difference will be: - Import Path - Actual Code Everything else works exactly the same no matter what project it is (assuming it follows idiomatic Go package conventions). Docs via godoc.org, standard testing, go vet, http://go-lint.appspot.com/ http://go-lint.appspot.com/, http://gocover.io/ http://gocover.io/ No need to figure out how to install that particular project/library, how to get docs, how to run tests, etc.
- swanson 12y ago
  You mean like `bundle install` or `pip install -r requirements.txt` or `npm install package.json`? I mean, it's great that Go has something similar, but it's not like other languages are missing dependency managment...
  - andmarios 12y ago
    Mind you that these are compile time dependencies. Go produces static binaries that can run as standalone apps. So only the developer has to install them. Ruby, nodejs and python have runtime dependencies, thus the user has to install them too (or use the bundled ones if they exist). Also their package managers have many issues you don't see with go (because go doesn't have a package manager, rather a source code dependency manager). For example python and ruby have many versions and not everything is available in all versions. What a user will do if he want to run a 2.7 and a 3.x python app? Sometimes they use the system compiler to produce binaries. I have seen it fail occasionally; for example charlock_holmes on a gentoo hardened system. Npm just floods your filesystem with npm_modules directories. I use a package manager so I won't have to install the same thing multiple times at multiple locations. Also it is very difficult to understand its directory structure. I searched the docs for hours in order to find where it stores the programs I install as a user (its path). Go is difficult to understand too in that aspect but it has all this info in one online document. You read it until you understand it. Finally there are always the questions; should I use pip or easy_install? What does rvm, what gem and what bundle(r)? Why should users learn them? How may I update my current gems and remove old versions? Where is gruntjs and how do I run it?
    - DAddYE 12y ago
      Wait what? Ocaml, Haskel, Rust? Nix? Probably many more. If `go get` was good enough as you intended to say why do we have `godep, godeps, gom, gondler, goop, vendorize, party, gpm` and many more? Which one should I pick? It's better do GOPATH="_vendor:$GOPATH" go install or use one of them? Also, should I install go with apt/brew/pac or use gvm? I like go, I use it for fun and work, but really, is getting annoying seeing all this `gophers` totally out of reality.
girvo 12y ago
Funnily, it's also why I sort of like Java web apps. Deploying a JAR or a WAR as a single file is pretty great.
- kinofcain 12y ago
  Easier than some other languages, but you still need something to run what's in your jar. Being able to deploy executables eliminates a whole layer of dependencies, which ends up being really handy.
  - girvo 12y ago
    I definitely agree! Statically linked binaries are my favourite part of Go, and one of the reasons why I've started moving towards it at work for some projects. Really takes a lot of hassle out of it all.
  - pjmlp 12y ago
    You can compile that jar to native code with the likes of Excelsior JET, for example.
general_failure 12y ago
Agreed. Gitlab is awesome but very painful to setup
- sytse 12y ago
  GitLab B.V. CEO here, have you tried our packages? With them you can now install GitLab in two minutes.
vectorpush 12y ago
Indeed. Gitlab is a similar software that I absolutely love, but the setup process is quite lengthy (though straightforward) and updating to new versions can be a considerable effort. I'll definitely be giving this a try, especially since the design is of a similar quality to gitlab.
- geerlingguy 12y ago
  The new Omnibus installer (which is basically a nice wrapper around Chef) makes the install process much simpler, FYI; it was released sometime late in the 6.x era.
  - sytse 12y ago
    GitLab B.V. CEO here, thanks for mentioning the Omnibus installer packages, they indeed make the installation much faster (2 minutes total) and updates are simple as well.
andmarios 12y ago
To be fair (and I am a Go fan) it is the same with Java and Scala. That's the main reason I switched from gitlab to gitbucket. Also with Java and Scala you can have all the resources inside your jar file. With Go you need a directory structure to store your templates, CSS, etc. The second reason I switched was RAM consumption and here Go shines compared to Java, although I'll have to let Gogs run for a few days to see what happens. I gave it a spin and it looks nice. I can see migrating from gitbucket to gogs, mainly for being able to run it on a small VPS. One thing that I didn't like was that the source version can only run from the source code directory. If I copy public and templates directories it should run from anywhere.
- mholt 12y ago
  (Slight nit-pic: To run a jar file, you need the JRE installed, whereas a Go binary contains the runtime.) But you're right about static resources, they need to be in a directory structure. Fortunately, zip files make them easy to distribute.
  - Alupis 12y ago
    you can bundle the jre into your executable to remove all foreign deps
    - adrusi 12y ago
      Which is a security risk in that the jre can't be updated without an update to your product. Granted the same applies to go since it statically links to its runtime.
      - deleted 12y ago
        [deleted]
      - hueving 12y ago
        Not really a security risk if you think of it like an embedded library in your software. A JRE vulnerability is then just like a vulnerability in the app itself and the vendor needs to update it.
pjmlp 12y ago
> A single binary with zero dependancies is so awesome. You mean, like every single language out there with native code compilers? A big generation gap must have happened, for static compilation to be touted as awesome feature.
- justincormack 12y ago
  Glibc does not properly support static binaries, you need libc around even for static binaries mostly (eg dns resolution). Its annoying. You can make real static binaries with Musl libc though, or on the BSDs.
  - pjmlp 12y ago
    Yes, but it doesn't change the fact how strange it is to see people amazed by having a language compiler supporting static compilation. Two decades ago it was the only option in most operating systems.
    - justincormack 12y ago
      Yes, I blame glibc for deprecating what should be perfectly normal...
      - pjmlp 12y ago
        May be. But it is an issue for the C developers that choose to link with it, need to sort out. Not an excuse for the lack of understanding, that static compilation is a standard feature that any language compiler to native code usually provides.
  - ithkuil 12y ago
    Well currently this applies to Go as well: when linking to the "net" package it links to the system libc shared library for the same reason. You can build your binary with the netgo build tag, but you must take into consideration that your binary might not behave correctly when running on systems with customised name resolution (NSS) settings, such as nss-ldap etc.
jingo 12y ago
This is why I prefer static binaries and preferably "crunched" binaries. Same goes for the use of "read-only" mounts and "RAM disks" as opposed to dependence on other, less reliable media. I hope your comment continues to be upvoted; usually I see downvotes at any mention of static linking. Why, I can never be sure. If static binaries make some power user's life easier why should anyone else care? With reasonably-sized, well-written programs (or the use of a system like Go's), compilation can be quite fast. And easy enough for anyone to do if and when libraries change.

joe2010xtmf 12y ago

Thanks for your words, we really appreciate!

lukeholder 12y ago
Thanks for your work on Gogs! looks forward to seeing it grow. Would love to help out on the front end - let me know if you are needing any contributors.
- joe2010xtmf 12y ago
  Hi there, how can I contact you? My e-mail is on the GitHub.

shurcooL 12y ago

I agree, that is one of my most favorite aspects of Go. go get -u github.com/go/project If you're writing native Go code, it doesn't matter if there's 0 or 1000+ dependencies, that one command will take care of everything. So there's no need to fear having extra dependencies, and you are welcome to reuse more code. Go takes the common parts of writing software and abstracts them away. Take any two distinct Go projects, and the only difference will be: - Import Path - Actual Code Everything else works exactly the same no matter what project it is (assuming it follows idiomatic Go package conventions). Docs via godoc.org, standard testing, go vet, http://go-lint.appspot.com/ http://go-lint.appspot.com/, http://gocover.io/ http://gocover.io/ No need to figure out how to install that particular project/library, how to get docs, how to run tests, etc.

swanson 12y ago
You mean like `bundle install` or `pip install -r requirements.txt` or `npm install package.json`? I mean, it's great that Go has something similar, but it's not like other languages are missing dependency managment...
- andmarios 12y ago
  Mind you that these are compile time dependencies. Go produces static binaries that can run as standalone apps. So only the developer has to install them. Ruby, nodejs and python have runtime dependencies, thus the user has to install them too (or use the bundled ones if they exist). Also their package managers have many issues you don't see with go (because go doesn't have a package manager, rather a source code dependency manager). For example python and ruby have many versions and not everything is available in all versions. What a user will do if he want to run a 2.7 and a 3.x python app? Sometimes they use the system compiler to produce binaries. I have seen it fail occasionally; for example charlock_holmes on a gentoo hardened system. Npm just floods your filesystem with npm_modules directories. I use a package manager so I won't have to install the same thing multiple times at multiple locations. Also it is very difficult to understand its directory structure. I searched the docs for hours in order to find where it stores the programs I install as a user (its path). Go is difficult to understand too in that aspect but it has all this info in one online document. You read it until you understand it. Finally there are always the questions; should I use pip or easy_install? What does rvm, what gem and what bundle(r)? Why should users learn them? How may I update my current gems and remove old versions? Where is gruntjs and how do I run it?
  - DAddYE 12y ago
    Wait what? Ocaml, Haskel, Rust? Nix? Probably many more. If `go get` was good enough as you intended to say why do we have `godep, godeps, gom, gondler, goop, vendorize, party, gpm` and many more? Which one should I pick? It's better do GOPATH="_vendor:$GOPATH" go install or use one of them? Also, should I install go with apt/brew/pac or use gvm? I like go, I use it for fun and work, but really, is getting annoying seeing all this `gophers` totally out of reality.

girvo 12y ago

Funnily, it's also why I sort of like Java web apps. Deploying a JAR or a WAR as a single file is pretty great.

kinofcain 12y ago
Easier than some other languages, but you still need something to run what's in your jar. Being able to deploy executables eliminates a whole layer of dependencies, which ends up being really handy.
- girvo 12y ago
  I definitely agree! Statically linked binaries are my favourite part of Go, and one of the reasons why I've started moving towards it at work for some projects. Really takes a lot of hassle out of it all.
- pjmlp 12y ago
  You can compile that jar to native code with the likes of Excelsior JET, for example.

general_failure 12y ago

Agreed. Gitlab is awesome but very painful to setup

sytse 12y ago
GitLab B.V. CEO here, have you tried our packages? With them you can now install GitLab in two minutes.

vectorpush 12y ago

Indeed. Gitlab is a similar software that I absolutely love, but the setup process is quite lengthy (though straightforward) and updating to new versions can be a considerable effort. I'll definitely be giving this a try, especially since the design is of a similar quality to gitlab.

geerlingguy 12y ago
The new Omnibus installer (which is basically a nice wrapper around Chef) makes the install process much simpler, FYI; it was released sometime late in the 6.x era.
- sytse 12y ago
  GitLab B.V. CEO here, thanks for mentioning the Omnibus installer packages, they indeed make the installation much faster (2 minutes total) and updates are simple as well.

andmarios 12y ago

To be fair (and I am a Go fan) it is the same with Java and Scala. That's the main reason I switched from gitlab to gitbucket. Also with Java and Scala you can have all the resources inside your jar file. With Go you need a directory structure to store your templates, CSS, etc. The second reason I switched was RAM consumption and here Go shines compared to Java, although I'll have to let Gogs run for a few days to see what happens. I gave it a spin and it looks nice. I can see migrating from gitbucket to gogs, mainly for being able to run it on a small VPS. One thing that I didn't like was that the source version can only run from the source code directory. If I copy public and templates directories it should run from anywhere.

mholt 12y ago
(Slight nit-pic: To run a jar file, you need the JRE installed, whereas a Go binary contains the runtime.) But you're right about static resources, they need to be in a directory structure. Fortunately, zip files make them easy to distribute.
- Alupis 12y ago
  you can bundle the jre into your executable to remove all foreign deps
  - adrusi 12y ago
    Which is a security risk in that the jre can't be updated without an update to your product. Granted the same applies to go since it statically links to its runtime.
    - deleted 12y ago
      [deleted]
    - hueving 12y ago
      Not really a security risk if you think of it like an embedded library in your software. A JRE vulnerability is then just like a vulnerability in the app itself and the vendor needs to update it.

pjmlp 12y ago

> A single binary with zero dependancies is so awesome. You mean, like every single language out there with native code compilers? A big generation gap must have happened, for static compilation to be touted as awesome feature.

justincormack 12y ago
Glibc does not properly support static binaries, you need libc around even for static binaries mostly (eg dns resolution). Its annoying. You can make real static binaries with Musl libc though, or on the BSDs.
- pjmlp 12y ago
  Yes, but it doesn't change the fact how strange it is to see people amazed by having a language compiler supporting static compilation. Two decades ago it was the only option in most operating systems.
  - justincormack 12y ago
    Yes, I blame glibc for deprecating what should be perfectly normal...
    - pjmlp 12y ago
      May be. But it is an issue for the C developers that choose to link with it, need to sort out. Not an excuse for the lack of understanding, that static compilation is a standard feature that any language compiler to native code usually provides.
- ithkuil 12y ago
  Well currently this applies to Go as well: when linking to the "net" package it links to the system libc shared library for the same reason. You can build your binary with the netgo build tag, but you must take into consideration that your binary might not behave correctly when running on systems with customised name resolution (NSS) settings, such as nss-ldap etc.

jingo 12y ago

This is why I prefer static binaries and preferably "crunched" binaries. Same goes for the use of "read-only" mounts and "RAM disks" as opposed to dependence on other, less reliable media. I hope your comment continues to be upvoted; usually I see downvotes at any mention of static linking. Why, I can never be sure. If static binaries make some power user's life easier why should anyone else care? With reasonably-sized, well-written programs (or the use of a system like Go's), compilation can be quite fast. And easy enough for anyone to do if and when libraries change.