6 ms·

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 too

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.

andrewchambers 11y ago
I dont think there is any configuration? Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.
- reallyRaoul 11y ago
  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...
  - andrewchambers 11y ago
    So the extent of the obtuse configuration you are talking about is a single environment variable?
    - deleted 11y ago
      [deleted]
  - spotman 11y ago
    curious then, what in your opinion solves these "ux" problems better?
  - lloeki 11y ago
    > I detest the whole GOPATH idea 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. [0]: https://github.com/lloeki/dotfiles/blob/master/shell/go https://github.com/lloeki/dotfiles/blob/master/shell/go
    - ngrilly 11y ago
      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.
  - laumars 11y ago
    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.
    - mahmoudimus 11y ago
      Have you tried modern Java development and deployment lately? It's really not that bad -- projects like https://github.com/puniverse/capsule https://github.com/puniverse/capsule, Oracle's http://openjdk.java.net/jeps/208 http://openjdk.java.net/jeps/208 and reference implementation of such JEP, http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/packager.html http://docs.oracle.com/javase/8/docs/technotes/guides/deploy... have made Java deployment a breeze. 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 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.
- deleted 11y ago
  [deleted]
MetaCosm 11y ago
What language is simpler to setup? 1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place> ... 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!

andrewchambers 11y ago

I dont think there is any configuration? Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.

reallyRaoul 11y ago
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...
- andrewchambers 11y ago
  So the extent of the obtuse configuration you are talking about is a single environment variable?
  - deleted 11y ago
    [deleted]
- spotman 11y ago
  curious then, what in your opinion solves these "ux" problems better?
- lloeki 11y ago
  > I detest the whole GOPATH idea 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. [0]: https://github.com/lloeki/dotfiles/blob/master/shell/go https://github.com/lloeki/dotfiles/blob/master/shell/go
  - ngrilly 11y ago
    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.
- laumars 11y ago
  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.
  - mahmoudimus 11y ago
    Have you tried modern Java development and deployment lately? It's really not that bad -- projects like https://github.com/puniverse/capsule https://github.com/puniverse/capsule, Oracle's http://openjdk.java.net/jeps/208 http://openjdk.java.net/jeps/208 and reference implementation of such JEP, http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/packager.html http://docs.oracle.com/javase/8/docs/technotes/guides/deploy... have made Java deployment a breeze. 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 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.
deleted 11y ago
[deleted]

MetaCosm 11y ago

What language is simpler to setup? 1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place> ... 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!