Just because I said there exists a strong argument for communism doesn't mean I am not aware of other arguments for other alternatives which might be stronger.
It took me a little while to figure out that your one-word post meant the practice of selling below cost to gain market share, with the intent to force marginal competitors out of your business and gain pricing power to be used later to make up for the losses.
I am not convinced that this practice is worthy of concern. I don't think that a short-term predatory pricing loss incurred by a dumper can ever be recovered. This opinion is based mostly on the personal belief that the substitution effect is far greater than most economists care to admit, particularly when the potential substitution is to not buy anything at all.
You can't dump alfalfa to bankrupt existing hay growers and then make a killing by raising alfalfa prices once you dominate the market. Why? Farmers will feed their livestock gummy bears[0]. And then they will plant their own damned hay crops at the very next available opportunity. The net result is that you go bankrupt, too, because you took a huge loss right before killing your own market.
Your concept of pleasant / your uses of Go must drastically diverge from mine! :-} I find Go to be needlessly obtuse in the language, the configuration, the tools, and the documentation. This is turning into another horror: it used to be that lots of jobs required javascript; now I fear the kool aid is making people push for Go. Note that I have not used Go for the concurrency stuff. Some might say that means I'm not allowed to have an opinion ;-) whereas I think it means I see the crappy foundation more clearly exposed.
Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...
Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack.
You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system.
But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary).
I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.
Last, but certainly not least, the state of the art tooling for Java, the world class GC (and advanced ones like G1), the breadth and depth of its incredible ecosystem, the performance monitoring and extension API, the innovative Quasar library (https://github.com/puniverse/quasar) for concurrency alongside the features and additions in Java 8 pretty much make Java a serious contender for new projects.
If you haven't explored modern Java, I suggest you give it another look.
I haven't, and that's good to hear. But it's still more complicated than Go if just in regards to how you need to be aware of these tools to begin with. Where as Go's behaviour is out-of-the-box.
This is purely from a "this is my first language" angle though. So I'm not to say that the aforementioned Java tooling isn't better than Go's, and in many other ways too.
Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside.
Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead.
I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.
... if you want to get fancy and make sure all your binaries are automatically in your path
5. export PATH=$PATH:$GOPATH/bin
... at this point setup is done, to build your first project using an external library
6. go get github.com/<user>/<library>
7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package>
8. go install <your_package>
9. $ <your_package> # runs it
this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!
