> 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…
Go 1.11 got me to stop ignoring Go
51–60 of 79 posts
Re: Go 1.11 got me to stop ignoring Go
#52GOPATH 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
#53A 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…
> 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
#54A 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…
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
#55My 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…
Re: Go 1.11 got me to stop ignoring Go
#56Earlier 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.
Re: Go 1.11 got me to stop ignoring Go
#57GOPATH 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…
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
#58My 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…
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
#59But… 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.