10 ms·

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up b

by asien 8y ago

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

smudgymcscmudge 8y ago
If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.
- freedomben 8y ago
  That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).
  - jjtheblunt 8y ago
    That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
  - klodolph 8y ago
    That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
  - developer2 8y ago
    Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project. [1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"
- geezerjay 8y ago
  > there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.
  - llimllib 8y ago
    Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.
    - weberc2 8y ago
      Same here. I've been using them in production with no issues.
    - geezerjay 8y ago
      > they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.
      - llimllib 8y ago
        I don't understand what you mean, sorry
        Cyph0n 8y ago
        Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?
        throwaway2048 8y ago
        Its not like there is much of a barrier there.
treis 8y ago
>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.
- vram22 8y ago
  > In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those. Not saying that features like byebug have no use at all, of course.
  - outworlder 8y ago
    Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases. Compilation is not a magic bullet. Although, to be fair, I pushed Golang at work precisely because you have to compile it first. Not everyone is diligently testing their code...
    - vram22 8y ago
weberc2 8y ago
Actually, the issues you mention are already fixed by Go modules. EDIT: Removed a parenthetical that was based on a misreading of the parent.
- yroc92 8y ago
  I believe they’re saying that vendor support is a good thing in Golang.
  - weberc2 8y ago
    Thanks; I definitely misread. I deleted the relevant bit from my post.
- dmoy 8y ago
  No oxford comma: the performance, the community around it, and vendors support
nicoburns 8y ago
You might like Rust. It has a much better story in these areas.
simfoo 8y ago
Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)
- elcomet 8y ago
  Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt). It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.
  - quickben 8y ago
    "you'll get used to it" is a bad measure of usability.
    - randomdata 8y ago
      But so is "I am already used to it," and so how do you find an objective, non-biased, measure of what is usable?
  - PavlovsCat 8y ago
    I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.
    - elcomet 8y ago
      Yeah I completely agree. Though I think when you really get used to a language and understand it deeper, you tend to understand the trade-offs that were made, if the language is well designed. Then you can still think that the trade-off don't match your requirements.
the_clarence 8y ago
Weird syntax? I’m sorry this doesn’t look like your favorite language.
floatboth 8y ago
hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.
- thanatos_dem 8y ago
  > direct usage of syscalls instead of libc But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?
  - _ph_ 8y ago
    No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.
- paulddraper 8y ago
  > direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?
  - djur 8y ago
    It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue. On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.
ChrisCinelli 8y ago
I agree with the package management system and $GOPATH. I would add that is awkward that most of the libraries are not thread safe when go routines are core to the language.
icedchai 8y ago
Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."
- AsyncAwait 8y ago
  It's a bit Pascale-y, which may be a turn off to some. I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?
  - icedchai 8y ago
    Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++. Haskell, I feel, needs no explanation.
    - AsyncAwait 8y ago
      Rust syntax being busy is something I've heard, but people point to things like lifetime annotations, which sort of make Rust what it is so...
      - majewsky 8y ago
        Also, lifetime annotations are not required on the overwhelming majority of functions. If you have, say, fn substr(text: &str, start: usize, length: usize) -> &str; the compiler will infer automatically that the return value inherits the lifetime of the `text` argument. I don't find that line up there particularly busy.
cdoxsey 8y ago
FWIW GOPATH has not been required since 1.8. It now defaults to $HOME/go if not set. Go is pretty easy to get up and running in Windows. There's an installer for the compiler and you can install vscode and the Go extension pretty quickly. Windows is an afterthought for most programming languages (ever try ruby or c++?) and Go's cross-platform capabilities were a breath of fresh air.

by asien 8y ago

smudgymcscmudge 8y ago

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

freedomben 8y ago
That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).
- jjtheblunt 8y ago
  That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
- klodolph 8y ago
  That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
- developer2 8y ago
  Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project. [1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"
geezerjay 8y ago
> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.
- llimllib 8y ago
  Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.
  - weberc2 8y ago
    Same here. I've been using them in production with no issues.
  - geezerjay 8y ago
    > they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.
    - llimllib 8y ago
      I don't understand what you mean, sorry
      - Cyph0n 8y ago
        Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?
        throwaway2048 8y ago
        Its not like there is much of a barrier there.

treis 8y ago

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.

vram22 8y ago
> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those. Not saying that features like byebug have no use at all, of course.
- outworlder 8y ago
  Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases. Compilation is not a magic bullet. Although, to be fair, I pushed Golang at work precisely because you have to compile it first. Not everyone is diligently testing their code...
  - vram22 8y ago

weberc2 8y ago

Actually, the issues you mention are already fixed by Go modules. EDIT: Removed a parenthetical that was based on a misreading of the parent.

yroc92 8y ago
I believe they’re saying that vendor support is a good thing in Golang.
- weberc2 8y ago
  Thanks; I definitely misread. I deleted the relevant bit from my post.
dmoy 8y ago
No oxford comma: the performance, the community around it, and vendors support

nicoburns 8y ago

You might like Rust. It has a much better story in these areas.

simfoo 8y ago

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)

elcomet 8y ago
Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt). It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.
- quickben 8y ago
  "you'll get used to it" is a bad measure of usability.
  - randomdata 8y ago
    But so is "I am already used to it," and so how do you find an objective, non-biased, measure of what is usable?
- PavlovsCat 8y ago
  I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.
  - elcomet 8y ago
    Yeah I completely agree. Though I think when you really get used to a language and understand it deeper, you tend to understand the trade-offs that were made, if the language is well designed. Then you can still think that the trade-off don't match your requirements.

the_clarence 8y ago

Weird syntax? I’m sorry this doesn’t look like your favorite language.

floatboth 8y ago

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

thanatos_dem 8y ago
> direct usage of syscalls instead of libc But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?
- _ph_ 8y ago
  No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.
paulddraper 8y ago
> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?
- djur 8y ago
  It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue. On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.

ChrisCinelli 8y ago

I agree with the package management system and $GOPATH. I would add that is awkward that most of the libraries are not thread safe when go routines are core to the language.

icedchai 8y ago

Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."

AsyncAwait 8y ago
It's a bit Pascale-y, which may be a turn off to some. I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?
- icedchai 8y ago
  Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++. Haskell, I feel, needs no explanation.
  - AsyncAwait 8y ago
    Rust syntax being busy is something I've heard, but people point to things like lifetime annotations, which sort of make Rust what it is so...
    - majewsky 8y ago
      Also, lifetime annotations are not required on the overwhelming majority of functions. If you have, say, fn substr(text: &str, start: usize, length: usize) -> &str; the compiler will infer automatically that the return value inherits the lifetime of the `text` argument. I don't find that line up there particularly busy.

cdoxsey 8y ago

FWIW GOPATH has not been required since 1.8. It now defaults to $HOME/go if not set. Go is pretty easy to get up and running in Windows. There's an installer for the compiler and you can install vscode and the Go extension pretty quickly. Windows is an afterthought for most programming languages (ever try ruby or c++?) and Go's cross-platform capabilities were a breath of fresh air.