81–90 of 93 posts
I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
Earlier quoted context omitted.
> Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling le…
Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
Earlier quoted context omitted.
That's not really idiomatic. You should be adding context to the error you return, or a new error.
Given its prevalence all across Go code, are you _sure_ it's not idiomatic? Hell, look at the presentation in the link: http://talks.golang.org/2014/readability.slide#11 . If the oracle of idioms does not write idiomatic code, then wtf is idiomatic code?
Earlier quoted context omitted.
> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.
Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). I wonder what an appropriate adjective could be for idiomatic Go code. Gonic? Gonian?
Earlier quoted context omitted.
Go does not require it. Interface compliance is statically checked. This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.
How do you list all interfaces a give type supports just by looking at it? Both by design, as well as, by accident (usually it different method semantics). You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.
That question doesn't make any sense. I can write a new interface that an existing type supports and then use that type as that interface. That's the awesome power of go interfaces. Using existing types for things their original creators couldn't have thought of.
Earlier quoted context omitted.
So it's a static typing check ? the code won't even compile if the ColumnWriter struct doesn't implement the interface ?
Yes. It won't compile. This check is not really needed as the code would fail when a function which accepts scan.Writer would fail (compilation) if ColumnWriter is sent and if it doesn't satisfy the interface. However, this is easier to debug.
Earlier quoted context omitted.
Feel free to enlighten us specifically about how they are better.
In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.
Earlier quoted context omitted.
How do you list all interfaces a give type supports just by looking at it? Both by design, as well as, by accident (usually it different method semantics). You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.
> How do you list all interfaces a give type supports just by looking at it? That question doesn't make any sense. I can write a new interface that an existing type supports and then use that type as that interface. That's the awesome power of go interfaces. Using existing types for things their original creators couldn't have thought of.
You are a consultant playing fireman in a Fortune 500 corporation.
Your task, in case you accept it, is to fix a performance problem no one from in-house teams has been able to track down.
The code is developed in three sites, all in separate time zones, with an overall size of 40 developers ideally churning code 8 hours a day.
Now dive in into this code and fix the issue.
It is a fixed price project of one week.
This is an example how code navigation is valuable.
> That's the awesome power of go interfaces.
Like any language that supports structural typing, nothing awesome about it.
Earlier quoted context omitted.
> How do you list all interfaces a give type supports just by looking at it? That question doesn't make any sense. I can write a new interface that an existing type supports and then use that type as that interface. That's the awesome power of go interfaces. Using existing types for things their original creators couldn't have thought of.
> That question doesn't make any sense. You are a consultant playing fireman in a Fortune 500 corporation. Your task, in case you accept it, is to fix a performance problem no one from in-house teams has been able to track down. The code is developed in three sites, all in separate time zones, with an overall size of 40 developers ideally churning code 8 hours a day. Now dive in into this code and fix the issue. It i…
Earlier quoted context omitted.
> That question doesn't make any sense. You are a consultant playing fireman in a Fortune 500 corporation. Your task, in case you accept it, is to fix a performance problem no one from in-house teams has been able to track down. The code is developed in three sites, all in separate time zones, with an overall size of 40 developers ideally churning code 8 hours a day. Now dive in into this code and fix the issue. It i…
If, somehow, figuring out what interfaces a type implements is valuable, I would use a tool, like this one: https://github.com/dominikh/implements