41–50 of 79 posts
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…
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…
By authoring private structs with public constructors, you can get what you want out of this. Gets a bit messy with testing, but not impossible.
If you’re in a different package things aren’t too bad if you have meaningfully abstracted interfaces. And with Go’s duck typing, even if you’re using another package that doesn’t have good abstraction, you can create your own interfaces with the functionality you need for mocking purposes.
> 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…
To be honest it says right at the beginning of PEP-8 that "A Foolish Consistency is the Hobgoblin of Little Minds" but it seems little minds are the norm (and usage of 'pep8' package to make developers do what a computer could do faster and better)
Earlier quoted context omitted.
IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):
My preference is to do this, which I think is quite nice and easy to work with: def my_very_very_very_very_very_long_function_name( self, param1, param2, ): do_it() # function body here.
func some_name(
arg: Type,
arg2: Type
) -> RetVal {
…
}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…
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 the C++ and Java sense of the term) approach for composability. Okay, sure, whatever, good for Go developers; but you can't complain about a leopard having spots. Just accept it or move on.
Just wanted to point this out as a clear example of such an issue, since it doesn't come up very often so cleanly.
EVERY piece of software requires a root path to function from. $GOPATH could be /go or /tmp/go or /projects/go/
All software has a file system structure internal to its needs.
Like a lot of things in Go, it makes this implicit status quo plain up and up front.
Earlier quoted context omitted.
That's funny, but since I started using Go, I now organize all projects under GOPATH, i.e. in `~/src/github.com/user/project`, no matter what language it is in. GOPATH and HOME are almost synonims now. I find it so much better experience than using tons of `~/Work`, `~/Projects`, `~/Code`, `~/SomeLang/` etc. as I used to have before.
I have been using something similar to ~/site/user/project for years and it worked well so far.
~/projects/USER/NAMESPACE/PROJECT
Company projects:
~/projects/COMPANY_SLUG/NAMESPACE/PROJECT
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…
> 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?
IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):