Hacker News Reader

Comment by andmarios | Hacker News Reader

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.

View on HN

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

[1] https://github.com/GeertJohan/go.rice

(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.

you can bundle the jre into your executable to remove all foreign deps

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.

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.

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.

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/

LLVM IR is neither portable nor stable.

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

There was a time when you just compiled the sources when you wanted to port a system to a new platform.

That is the greatest possible defence of golang's current course and heading, and god knows I want as much of my world to build from source as possible, but

> 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

In the jvm world right now, for example, I won't touch maven with a ten foot poll. And yet I regularly use libraries produced by people who do. The portable, stable bytecode is a boundary between me and them where the buck stops. Anyone can use any build toolchain they like, and the interface for collaboration is well-defined.

Don't get me wrong, there are many things to love about golang, and there are many things to love about building from source. But I do think it's worth pausing to consider the flexibility that an intermediate representation can unlock.

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.

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. :)

> 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.

> 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!

I missed this at the time, but I think you read past what I said: I used "devops" in the tools sense, not the people sense. A programming language (the syntax, the compiler, the linter) can't be everything to everyone, and therefore most don't attempt to shoehorn in things like static asset bundling, etc.

That's why frameworks exist, or packages like go-bindata or rakyll/statik (https://github.com/rakyll/statik), or CM tools that can wrap it all together.

> 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 ?

go.rice (https://github.com/GeertJohan/go.rice) does things like this.

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!

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/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/ZTD1qtp...

Reply on news.ycombinator.com