7 ms·

I know HN gets a lot of crap for having a ton of Go fanboys but the reasons given here for liking C are the reasons I am in love with Go. No magic, no overloadi

by donatj 10y ago

I know HN gets a lot of crap for having a ton of Go fanboys but the reasons given here for liking C are the reasons I am in love with Go. No magic, no overloading, very clear when I do this this happens, and very easy to read code including in the standard library. It's a more friendly C.

shakna 10y ago
I want to like Go. But its insistence on $GOPATH is infuriating. I have many, many projects in dozens of languages, organised in a way that reflects both my development and deployment practices. But Go wants to be different. And it wants to be separate. It's a tiny knitpick, and there is much I like about Go, even the way it handles exceptions. But it inconveniences me. And so, I guess I'll pout.
- patates 10y ago
  I just set the $GOPATH per project and it stops being a big problem, and turns into just an inconvenience. If you have a ProjectX with the path $pathx, set $GOTPATH to $pathx and place your source files in $pathx/src/projectx I also hate that I have to do this though and I totally understand what you mean. Just wanted to mention my favorite work-around to see if I get some feedback on it being stupid/clever/ordinary.
  - shakna 10y ago
    It's what I've been recommended, but it really seems like a terrible hack that shouldn't have to exist.
    - laumars 10y ago
      It's not really any different to supplying the source paths in C / C++ build scripts. Or setting the Java variables in your preferred IDE. At the of the day the compiler isn't going to know where to import external source files from if you don't specify it somewhere. The GOPATH envvar just shortcuts the need to use build flags but if you want to do away with system wide Go variables then you can always write build scripts more akin to those we see in some other languages.
      - shakna 10y ago
        $(CC) $(FILES) -L$(LIBS) -o $(EXE) Allows me to change and modify on a per project basis how to compile a program. In fact, it allows me to change exactly how it's compiled or cross-compiled. I can use system libs if available, and if not, drag down the latest, build that locally, and link locally. Go isn't as flexible. It's opinionated. There doesn't seem to be any benefit other than standards compliance in having a GOPATH. I have to circumvent how Go wants to work so that it can fit with the standards I have that C, C++, C#, F#, Haskell, D, Nim, Red, Chicken, Python all work with without being bashed into submission, they supply tools to make it easier. They don't have lead developers standing up and saying "All Python libraries should be developed in this particular folder structure. Even if it makes integrating C code more difficult." That feels... Wrong. So repeatedly setting GOPATH sucks, and can cause havoc if the envar isn't released properly by, say, a failing build. But, as I said to start with: This is a tiny knitpick. It means I come back and try Go, time and again. It also means I spend more time wrestling Go into submission within my automated testing and deployment structures, than writing code in it.
        laumars 10y ago
        But again, you can do that with Go very easily. eg the -pkgdir flag in `go build`. You can also write your own wrapper script around Go build tools. Or even bypass `go build` entirely and call the Go compiler in the exact same way you'd described above (-o and -L flags included). Run `go build -n` against your project to see what `go build` does (it's print only mode, no compiling will happen) and you'll see it's really no different to what you were asking for So everything you want to do can and is supported by Go. It's just not it's default behaviour so you needed to do a little digging to find it. Personally though, I find the inconvenience of having to change GOPATH / GOOS / GOARCH to be significantly less annoying than having to write makefiles and configure scripts to handle every platform I might want to target. For most people `go build` abstracts away the pain of cross compiling and build scripts quite nicely. In fact that was one of the biggest reasons I started using Go in the first place (I wanted something I could rapidly code and compile on AMD64 then rsync onto ARM devices back when I was experimenting with building custom embedded devices for my car). edit: just want to add that I'm not under any illusion that Go nor it's tooling is perfect. I'm just saying Go can easily support your specific workflow preferences even though superficially it appears otherwise.
- laumars 10y ago
  I can see why Go might become annoying with that kind of file system hierarchy but I think it's an easily solvable problem. Most IDE's I've used allow you to set custom $GOPATH variables and for the CLI stuff you could write a wrapper makefile or similar. I understand that different people find themselves preferring different programming languages based on their syntax, features, tooling, etc. But I do think it would be a shame not to use a language you conceptually like just because of a single and easily changeable environmental variable.
- virmundi 10y ago
  I have/had this issue too. While I'm just exploring go, it looks like $GOPATH can be split into multiple directories. So you could just update it to have a new project. Still weird coming from a Maven/Java perspective, but more reasonable than having to have a script that alters the shell in order to change projects. Am I wrong in my understanding?

by donatj 10y ago

shakna 10y ago

I want to like Go. But its insistence on $GOPATH is infuriating. I have many, many projects in dozens of languages, organised in a way that reflects both my development and deployment practices. But Go wants to be different. And it wants to be separate. It's a tiny knitpick, and there is much I like about Go, even the way it handles exceptions. But it inconveniences me. And so, I guess I'll pout.

patates 10y ago
I just set the $GOPATH per project and it stops being a big problem, and turns into just an inconvenience. If you have a ProjectX with the path $pathx, set $GOTPATH to $pathx and place your source files in $pathx/src/projectx I also hate that I have to do this though and I totally understand what you mean. Just wanted to mention my favorite work-around to see if I get some feedback on it being stupid/clever/ordinary.
- shakna 10y ago
  It's what I've been recommended, but it really seems like a terrible hack that shouldn't have to exist.
  - laumars 10y ago
    It's not really any different to supplying the source paths in C / C++ build scripts. Or setting the Java variables in your preferred IDE. At the of the day the compiler isn't going to know where to import external source files from if you don't specify it somewhere. The GOPATH envvar just shortcuts the need to use build flags but if you want to do away with system wide Go variables then you can always write build scripts more akin to those we see in some other languages.
    - shakna 10y ago
      $(CC) $(FILES) -L$(LIBS) -o $(EXE) Allows me to change and modify on a per project basis how to compile a program. In fact, it allows me to change exactly how it's compiled or cross-compiled. I can use system libs if available, and if not, drag down the latest, build that locally, and link locally. Go isn't as flexible. It's opinionated. There doesn't seem to be any benefit other than standards compliance in having a GOPATH. I have to circumvent how Go wants to work so that it can fit with the standards I have that C, C++, C#, F#, Haskell, D, Nim, Red, Chicken, Python all work with without being bashed into submission, they supply tools to make it easier. They don't have lead developers standing up and saying "All Python libraries should be developed in this particular folder structure. Even if it makes integrating C code more difficult." That feels... Wrong. So repeatedly setting GOPATH sucks, and can cause havoc if the envar isn't released properly by, say, a failing build. But, as I said to start with: This is a tiny knitpick. It means I come back and try Go, time and again. It also means I spend more time wrestling Go into submission within my automated testing and deployment structures, than writing code in it.
      - laumars 10y ago
        But again, you can do that with Go very easily. eg the -pkgdir flag in `go build`. You can also write your own wrapper script around Go build tools. Or even bypass `go build` entirely and call the Go compiler in the exact same way you'd described above (-o and -L flags included). Run `go build -n` against your project to see what `go build` does (it's print only mode, no compiling will happen) and you'll see it's really no different to what you were asking for So everything you want to do can and is supported by Go. It's just not it's default behaviour so you needed to do a little digging to find it. Personally though, I find the inconvenience of having to change GOPATH / GOOS / GOARCH to be significantly less annoying than having to write makefiles and configure scripts to handle every platform I might want to target. For most people `go build` abstracts away the pain of cross compiling and build scripts quite nicely. In fact that was one of the biggest reasons I started using Go in the first place (I wanted something I could rapidly code and compile on AMD64 then rsync onto ARM devices back when I was experimenting with building custom embedded devices for my car). edit: just want to add that I'm not under any illusion that Go nor it's tooling is perfect. I'm just saying Go can easily support your specific workflow preferences even though superficially it appears otherwise.
laumars 10y ago
I can see why Go might become annoying with that kind of file system hierarchy but I think it's an easily solvable problem. Most IDE's I've used allow you to set custom $GOPATH variables and for the CLI stuff you could write a wrapper makefile or similar. I understand that different people find themselves preferring different programming languages based on their syntax, features, tooling, etc. But I do think it would be a shame not to use a language you conceptually like just because of a single and easily changeable environmental variable.
virmundi 10y ago
I have/had this issue too. While I'm just exploring go, it looks like $GOPATH can be split into multiple directories. So you could just update it to have a new project. Still weird coming from a Maven/Java perspective, but more reasonable than having to have a script that alters the shell in order to change projects. Am I wrong in my understanding?