Live data from Hacker News

Go 1.11 got me to stop ignoring Go

drewdevault.com

51–60 of 79 posts

Re: Go 1.11 got me to stop ignoring Go

#51

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

I have major gripes with it too and don't use it unless a project enforces it. The main ones that get me are the whitespace (4 characters) and restrictive line length (79 characters) rules. They don't work well together, and also don't work well with python's significant whitespace (can't easily break up a line), namespaces, generator expressions, and type hints. All for a subjective formatting decision. I'll also of…

I don't see many projects enforcing a line length, and if they do it's generally set much higher (120-150).

Re: Go 1.11 got me to stop ignoring Go

#52
Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned.

GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a service to 1 (I/O bound), reducing the costs for that service a lot. If you are willing to let the environment get in between that...

Of course, you could have implemented that system using assembler for all I care, but Go really made it possible within that organization, something Java, C and other languages failed at before Go was introduced.

N=1, ymmv, &c

Re: Go 1.11 got me to stop ignoring Go

#53
post #33

A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their…

There's going to be a large group of people (myself included) who graps the system but refuses to use it because it's pointless and stupid.

> It's always obvious where your dependencies are located and which versions are going to be used to build your project.

More obvious than specifying the version in some dependencies file?

> Even better, it lets use very easily drop into those dependencies and add minor changes or debugging lines if you need to.

What dependency management system doesn't allow you to do this if you insist?

Re: Go 1.11 got me to stop ignoring Go

#54
post #33

A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their…

> Even better, it lets use very easily drop into those dependencies and add minor changes or debugging lines if you need to.

I've done this quite a bit with typical Ruby+bundler setups. I think the key is that both Go and Ruby start from source code, vs. something like Java where your dependencies are compiled JARs without source (of course, there is infrastructure to enable easy fetching of the source when available).

This is similar to my experience with Nix package manager. It's purely source-based with binary packages seen as something like a compiler cache. It's easy to get the source to a package, make some tweaks, and build (and use) a custom version (at least I personally have found it far easier than Debian, even with apt making it easy to get the source).

Re: Go 1.11 got me to stop ignoring Go

#55

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because…

You're getting downvoted here, but I agree with you. Once you really lean on Java constructors to guarantee initialized state, it's hard to go to something like Go that doesn't have this. Sure, you could do a lot of gymnastics to try to work around it, but that's the thing about Java that's nice. It's just built-in with that in mind.

Re: Go 1.11 got me to stop ignoring Go

#56
post #17

Earlier quoted context omitted.

Your go code has to live in go's directory structure. If your project is github.com/jrockway/whatever, then your source code must live in ~/go/src/github.com/jrockway/whatever/ . There is no other place you can put it (though you can change ~/go to something else by setting $GOPATH in your environment). I assume what upsets people is that everything in go is in a global namespace. So if you have ~/foo-project with so…

One nit: it's not "global" because it comes from $GOPATH. If you want, you can create a project like this: `~/myproject/src/app/main.go` and it will work fine so long as you set `GOPATH=$HOME/myproject` for your current shell.

It's not that trivial in my experience. I tried hacking my shell so that the `go` command would automatically set GOPATH for me, but then I also had to set GOBIN for some reason, and even then I had to move my repository from ~/code/myproject to ~/code/myproject/src/github.com/myuser/myproject - which is just hugely unnecessary.

Re: Go 1.11 got me to stop ignoring Go

#57
post #2

GOPATH issues - Elaborate more?

Your go code has to live in go's directory structure. If your project is github.com/jrockway/whatever, then your source code must live in ~/go/src/github.com/jrockway/whatever/ . There is no other place you can put it (though you can change ~/go to something else by setting $GOPATH in your environment). I assume what upsets people is that everything in go is in a global namespace. So if you have ~/foo-project with so…

> cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there

In addition to your bash alias for navigation, you can use the `autocd` option of bash so that from your home directory you can say `cd /project`.

You can also use the CDPATH variable for quick navigation into a deep directory structure like that.

Re: Go 1.11 got me to stop ignoring Go

#58

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because…

How is this any different than namespace_init(); functions from C? I hear language complaints like this all the time, and it always sounds like developers grasping for something to complain about. I'm not even a Go fan, but I think you can cut the language some slack here at least in this department. The entire approach Go is selling from what I've hear is they're entirely forgoing the traditional object-oriented (in…

> How is this any different than namespace_init(); functions from C?

It's not; presumably that's the point. C isn't exactly famous for its support for data hiding and enforcing invariants.

Re: Go 1.11 got me to stop ignoring Go

#59
I actually adopted GOPATH for everything. I use https://github.com/motemen/ghq to quickly clone non-Go projects into the ~/src/github.com/user/project style paths.

But… I don't like Go itself (anymore).

It's not just the 'if err != nil', it's more the general attitude/philosophy from which it comes. Go is anti-intellectual, the designers basically don't respect the user. "You're too stupid to use generics/Result/monads/whatever" is what it feels like they think of you.

Go internals are more infuriating than Go language though…

Especially the Plan9-based custom assembler. It truly is a horrific atrocity. I've had to deal with it two times:

1. That assembler does not support all instructions and even addressing modes (!) of amd64, so people have had to create hacks like https://github.com/minio/c2goasm to run asm functions without the overhead of cgo. Please actually read that project's README, but tl;dr it assembles your code using a normal assembler and STICKS THE BINARY CODE INTO A GO ASSEMBLY FILE AS HEX CONSTANTS. This hack actually didn't work for me when I tried to use some SIMD code, so I had to resort to cgo with its call overhead.

2. I also tried (and failed) to port the Go runtime to FreeBSD/aarch64. This was the last straw, this is what made me actually hate Go.

Post reply on HN