5 ms·

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

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.
      - _delirium 12y ago
        The majority of JRE vulnerabilities are also not really relevant to a local app in the first place. They're sandbox vulnerabilities that let carefully crafted applets break out of the sandbox and execute arbitrary code. But regularly installed desktop/server software doesn't run in the applet sandbox, and is already assumed to be able to execute arbitrary code.
  - deleted 12y ago
    [deleted]
- heavenlyhash 12y ago
  In addition to the bundle-the-jre option (which is extremely workable), you can also feed java bytecode into robovm [1], which spins it through LLVM and produces native binaries for any platform you can go with LLVM. (Most of the documentation emphasizes IOS, but speaking from experience, yes, you absolutely can make mac desktop and linux native binaries as well.) What robovm can do is a great example of the joys of toolchains with a well-defined stable intermediate representation. (Or one of the joys, I should say -- the flowering of languages on top of the jvm is another.) Go's first-class AST work is excellent stuff, but I'd love it even more if they fleshed out a well-defined, stable, portable intermediate format like LLVM's IR and java's bytecode. Making a release of software and knowing it can run on architectures you haven't even thought of yet is liberating. Sure, architectures don't come along "very often" (but they're starting to happen more often!), and sure, you can use a full vm at the bottom layer (but it's slow! It can't do a fraction of the optimizations possible with an IR/bytecode), and sure, you can just pretend the source is an IR (but if some library you use chooses a different build tool chain than you, you're going to have a bad time -- don't laugh, golang is too young to have bifurcated much yet, but give it time, and look at what happened around the go-get mess already; or, consider what happens when someone just adds more tooling like source generation, which has also already happened)... Taking the long view, I think an intermediate representation has proven incredibly useful for the jvm as a platform, and I hope golang also grows to offer such a route sometime in the future. [1] http://robovm.com/ http://robovm.com/
  - pcwalton 12y ago
    LLVM IR is neither portable nor stable.
    - mcpherrinm 12y ago
      But that isn't really relevant here: robovm is just a step in a build pipeline: Java -> java bytecode -> llvm IR -> native binary you distribute
  - tempodox 12y ago
    There was a time when you just compiled the sources when you wanted to port a system to a new platform.
condiment 12y ago
I've been experimenting with it as well and it looks like you have to copy several directories to get it to work out of the box - templates, public, custom, log, and data. But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. What we've done for our internal Go projects is wrap them up with an .rpm installer that handles the creation of directories throughout the system, drops init scripts where they're appropriate, and sets up necessary cron jobs and logrotate rules. I don't think this is the best approach, but at the same time I'm not familiar with any good alternatives.
- andmarios 12y ago
  If the project permits it (size, complexity, what kind of bugs I expect to encounter) I like to have my static assets in a separate git repository. System configuration I think is a problem independent of the programming language and anything you try will feel as hack. As long as it works, it is ok. :)
- elithrar 12y ago
  > But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. This is mostly a sysadmin/devops issue, since all languages have the same issue. I solve it through a CM tool (Ansible, in my case) that sets up my directories, rsyncs my templates and TOML config, and uploads my binary. Not having to worry the server running the same env as my dev environment removes a whole class of bugs/frustration.
  - serverhorror 12y ago
    > This is mostly a sysadmin/devops issue, since all languages have the same issue. You're kidding right? I thought that whole "devops" movement (call it what you like) was to get rid of the attitude of "other people's problem". I live in environments that are (for the most part) regulated and demand by law that there is a strict separation between the people running and developing software, often open to interpretation is the 3rd role of people configuring the software. The problem is that "I solve it..." just doesn't work. Either people solve it by working cooperatively together or it simply won't ever be deployed. There's no such thing as a sysadmin problem, devops problem, developer problem. (No go downvote me for the tone of the next sentence) -- For me it's either get your ass moving, stand up, walk over to people and talk to them or get lost!
philsnow 12y ago
> With Go you need a directory structure to store your templates, CSS, etc. Is there anything stopping one from appending a zip archive to the go binary, and having the binary open the executable as a zip file to get at the static assets ?
- mjibson 12y ago
  go.rice (https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice) does things like this.
  - DAddYE 12y ago
    Thanks guys I was looking for something like that and I was aware of go-data, this with the next go generate should be very neat!
- kyrra 12y ago
  There are some 3rd party build tools to help with that. Below are a couple I found. https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata EDIT: to add, the Go team is looking to add a generate command in go1.4 to help with this. See: https://groups.google.com/forum/m/#!topic/golang-dev/ZTD1qtpruA8 https://groups.google.com/forum/m/#!topic/golang-dev/ZTD1qtp...
kawera 12y ago
It is possible to pack static assets directly inside go binaries using statik[0] or rice[2]. I've been using then for small webapps and they both work very well. [0] https://github.com/rakyll/statik https://github.com/rakyll/statik [1] https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice

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.
    - _delirium 12y ago
      The majority of JRE vulnerabilities are also not really relevant to a local app in the first place. They're sandbox vulnerabilities that let carefully crafted applets break out of the sandbox and execute arbitrary code. But regularly installed desktop/server software doesn't run in the applet sandbox, and is already assumed to be able to execute arbitrary code.
- deleted 12y ago
  [deleted]
heavenlyhash 12y ago
In addition to the bundle-the-jre option (which is extremely workable), you can also feed java bytecode into robovm [1], which spins it through LLVM and produces native binaries for any platform you can go with LLVM. (Most of the documentation emphasizes IOS, but speaking from experience, yes, you absolutely can make mac desktop and linux native binaries as well.) What robovm can do is a great example of the joys of toolchains with a well-defined stable intermediate representation. (Or one of the joys, I should say -- the flowering of languages on top of the jvm is another.) Go's first-class AST work is excellent stuff, but I'd love it even more if they fleshed out a well-defined, stable, portable intermediate format like LLVM's IR and java's bytecode. Making a release of software and knowing it can run on architectures you haven't even thought of yet is liberating. Sure, architectures don't come along "very often" (but they're starting to happen more often!), and sure, you can use a full vm at the bottom layer (but it's slow! It can't do a fraction of the optimizations possible with an IR/bytecode), and sure, you can just pretend the source is an IR (but if some library you use chooses a different build tool chain than you, you're going to have a bad time -- don't laugh, golang is too young to have bifurcated much yet, but give it time, and look at what happened around the go-get mess already; or, consider what happens when someone just adds more tooling like source generation, which has also already happened)... Taking the long view, I think an intermediate representation has proven incredibly useful for the jvm as a platform, and I hope golang also grows to offer such a route sometime in the future. [1] http://robovm.com/ http://robovm.com/
- pcwalton 12y ago
  LLVM IR is neither portable nor stable.
  - mcpherrinm 12y ago
    But that isn't really relevant here: robovm is just a step in a build pipeline: Java -> java bytecode -> llvm IR -> native binary you distribute
- tempodox 12y ago
  There was a time when you just compiled the sources when you wanted to port a system to a new platform.

condiment 12y ago

I've been experimenting with it as well and it looks like you have to copy several directories to get it to work out of the box - templates, public, custom, log, and data. But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. What we've done for our internal Go projects is wrap them up with an .rpm installer that handles the creation of directories throughout the system, drops init scripts where they're appropriate, and sets up necessary cron jobs and logrotate rules. I don't think this is the best approach, but at the same time I'm not familiar with any good alternatives.

andmarios 12y ago
If the project permits it (size, complexity, what kind of bugs I expect to encounter) I like to have my static assets in a separate git repository. System configuration I think is a problem independent of the programming language and anything you try will feel as hack. As long as it works, it is ok. :)
elithrar 12y ago
> But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. This is mostly a sysadmin/devops issue, since all languages have the same issue. I solve it through a CM tool (Ansible, in my case) that sets up my directories, rsyncs my templates and TOML config, and uploads my binary. Not having to worry the server running the same env as my dev environment removes a whole class of bugs/frustration.
- serverhorror 12y ago
  > This is mostly a sysadmin/devops issue, since all languages have the same issue. You're kidding right? I thought that whole "devops" movement (call it what you like) was to get rid of the attitude of "other people's problem". I live in environments that are (for the most part) regulated and demand by law that there is a strict separation between the people running and developing software, often open to interpretation is the 3rd role of people configuring the software. The problem is that "I solve it..." just doesn't work. Either people solve it by working cooperatively together or it simply won't ever be deployed. There's no such thing as a sysadmin problem, devops problem, developer problem. (No go downvote me for the tone of the next sentence) -- For me it's either get your ass moving, stand up, walk over to people and talk to them or get lost!

philsnow 12y ago

> With Go you need a directory structure to store your templates, CSS, etc. Is there anything stopping one from appending a zip archive to the go binary, and having the binary open the executable as a zip file to get at the static assets ?

mjibson 12y ago
go.rice (https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice) does things like this.
- DAddYE 12y ago
  Thanks guys I was looking for something like that and I was aware of go-data, this with the next go generate should be very neat!
kyrra 12y ago
There are some 3rd party build tools to help with that. Below are a couple I found. https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata EDIT: to add, the Go team is looking to add a generate command in go1.4 to help with this. See: https://groups.google.com/forum/m/#!topic/golang-dev/ZTD1qtpruA8 https://groups.google.com/forum/m/#!topic/golang-dev/ZTD1qtp...

kawera 12y ago

It is possible to pack static assets directly inside go binaries using statik[0] or rice[2]. I've been using then for small webapps and they both work very well. [0] https://github.com/rakyll/statik https://github.com/rakyll/statik [1] https://github.com/GeertJohan/go.rice https://github.com/GeertJohan/go.rice