3 ms·

The proposal for `try` made my eyes bleed. It combines a number of features from metaprogramming and generic types but in a hard-coded manner and doing a number

The proposal for `try` made my eyes bleed. It combines a number of features from metaprogramming and generic types but in a hard-coded manner and doing a number of assumptions about functions signatures, etc. I guess that's the idea of Go, to restrict the language power by giving just the functionality the designers think the programmer should have, but to not allow anything too fancy. However, if you put some thought to it, it really sounds silly when you know that this will only limit your ability to actually use the language and not really "simplify" anything, since it only adds to the general cognitive load of the language - in this case, one more exceptional case.

swiley 7y ago
Having read a decent amount of go code I'm really quite convinced the restrictions are beneficial. Personally I find it easier to read than just about any other language.
- qtplatypus 7y ago
  Can I politely suggest that the fact that you have read a decent amount of go code is directly related to the fact that you find it easy to read? I’ve read and programmed in many languages and apart from some outlayers the more I’ve read that language the more readable it is.
nullwasamistake 7y ago
I'm of the opinion that making a language too simple results in the worst code. Sure it's easier to learn, but you end up with crap when you're trying to do something complex and there's no good way to represent it. BASIC and VBA are extreme examples but they support my opinion :). Go has a ton of shortcomings. No good popular package management system with versioning, hacky JSON parsing, no generics. Rust is becoming a good counter example, they listen to the community and pump out features that everyone is excited about. Like async recently. Google has a habit of ignoring the community. Angular is a great example. I've been following a feature request for close to 3 years that has over 100 comments asking for it. A simple thing too. Many people have opened PR's and begged for it in vein, even as recent as a week ago.
throwaway34241 7y ago
One of the most common issues (from surveys, etc) that Go users want to see addressed is verbose error checking, and this proposal is to add some syntactic sugar to make one of the more common error checking idioms less verbose, in order to address that specific issue. You are suggesting that they implement a metaprogramming system (and then build this solution on top of that) instead? On the grounds that it will reduce cognitive load overall? Surely that is a drastically more difficult solution to the problem this is meant to address. I think it might be difficult to implement that in a way that maintains key properties of Go (like consistently fast compile times), and it might add a lot more work to tooling that needs to understand code like editors etc. And although that would allow each Go project to invent their own error handling mechanisms, and some projects might benefit from that, there's clear downsides to that as well.
baq 7y ago
it's much less magic than defer, panic and recover - it's basically just a macro. if that irks you, all of the above should make you hate the language.

swiley 7y ago

Having read a decent amount of go code I'm really quite convinced the restrictions are beneficial. Personally I find it easier to read than just about any other language.

qtplatypus 7y ago
Can I politely suggest that the fact that you have read a decent amount of go code is directly related to the fact that you find it easy to read? I’ve read and programmed in many languages and apart from some outlayers the more I’ve read that language the more readable it is.

nullwasamistake 7y ago

I'm of the opinion that making a language too simple results in the worst code. Sure it's easier to learn, but you end up with crap when you're trying to do something complex and there's no good way to represent it. BASIC and VBA are extreme examples but they support my opinion :). Go has a ton of shortcomings. No good popular package management system with versioning, hacky JSON parsing, no generics. Rust is becoming a good counter example, they listen to the community and pump out features that everyone is excited about. Like async recently. Google has a habit of ignoring the community. Angular is a great example. I've been following a feature request for close to 3 years that has over 100 comments asking for it. A simple thing too. Many people have opened PR's and begged for it in vein, even as recent as a week ago.

throwaway34241 7y ago

One of the most common issues (from surveys, etc) that Go users want to see addressed is verbose error checking, and this proposal is to add some syntactic sugar to make one of the more common error checking idioms less verbose, in order to address that specific issue. You are suggesting that they implement a metaprogramming system (and then build this solution on top of that) instead? On the grounds that it will reduce cognitive load overall? Surely that is a drastically more difficult solution to the problem this is meant to address. I think it might be difficult to implement that in a way that maintains key properties of Go (like consistently fast compile times), and it might add a lot more work to tooling that needs to understand code like editors etc. And although that would allow each Go project to invent their own error handling mechanisms, and some projects might benefit from that, there's clear downsides to that as well.

baq 7y ago

it's much less magic than defer, panic and recover - it's basically just a macro. if that irks you, all of the above should make you hate the language.