On ArchLinux Go is pretty massive ~294 MB (compared to the jdk7-openjdk at ~19MB) installed. I, personally, have avoided installing some small programs because they had Go as a dependency, obviously you can compile a binary to resolve this for the editor itself. It seems like quite a bit of work just to generate a screenshot though.
I've heard this argument from people refusing to install packages that depend on haskell too. I don't get it, 294mb is a trivial amount of space nowadays.
If you pull in lots of dependencies, people think "great, now there are a whole bunch of dependencies that I'll need to keep updated, may break my program if they update in the future, may not be available (or available in the appropriate version) on another platform if I switch platforms, etc."
Dependencies have a cost that is more than just size. There's the extra overhead in managing them any time you need to do something beyond the first time installation.
Sure, if dependencies are all appropriately semantically versioned, with proper symbol versioning and sonames in libraries and so on, and you have a proper packaging system which keeps all of those dependencies updated properly, the cognitive overhead is not that high. But people screw these things up all the time; making backwards incompatible changes without incrementing major versions or updating sonames, packaging systems that don't allow you to have two incompatible versions installed at once, etc. And the larger the dependency set, the more likely it is that you'll run into once of these problems.
It's more the fact that honestly, I don't want to take the time... It's easier for me to shell out $70 to Sublime Text knowing that I can see it before I buy it than take the time to download and install all dependencies, build it, then be like "I don't even like this at all..."
I tried to make it clear in my original comment that you wouldn't even need the Go environment if there was just a binary distributed, so I agree with you on that. I also realize that this is in the early stages of the development process and it doesn't necessarily make all that much sense to distribute binaries when it is changing frequently. My point was that it is a lot to download to get a screenshot.
I can't reply to drbawb (I don't know why sometimes HN doesn't give you reply links and it doesn't seem to be in the FAQ). I am not so worried about Qt because there are a lot of programs that use it and overall if you have a lot of programs using it, it should decrease the size of the individual programs.
True, though it does look like this is using `cgo` though (for the Qt support?)
Do those dependencies end up statically linked as well? Otherwise you'll need Qt installed. I don't happen to have it on my system, but I'd imagine Qt is quite large compared to the Go development tools.
Unless you are building these packages from source then they don't have Go as a dependancy as Go creates static binaries.
And if you are building from source then you can just delete the Go package once you've compiled the program, since you are also on Arch that would be a simple: pacman -Rs go
Or even better, submit a PR that builds the project on Travis and dumps the binaries to an S3 bucket. I did this for an experimental pandoc-based ebook, and it worked great:
Indeed. I think I stated that you could just build a binary. This could also be released as a binary package (which is likely what would happen if it gains traction). I mean just to get a screenshot this is quite a bit of downloading. Then every time you want an update you have to do the same thing (in the absence of just downloading a binary).
Chances are good that a maintainer will pick this up and add it to your distro's official repositories in time, meanwhile it's not such a hassle to build from source imo.
You can click the "View the file list for `go`" link at the bottom of the page to see what it's pulling in.
Looks like, regardless of architecture, it has compiled forms of the packages from the standard library for both i386 and amd64 as well as their source form.
