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