3 ms·
I also prefer the option monad, etc. over returning (result, result..., err) tuples but terseness of error handling is as much a property of the language (i.e.
by platinumrad 8y ago
I also prefer the option monad, etc. over returning (result, result..., err) tuples but terseness of error handling is as much a property of the language (i.e. operators, features, etc.) as it is a property of the type system. Consider the "try!/?" pseudo-macro from Rust. If Go had macros, there would be nothing preventing something similar from being implemented.
- majewsky 8y agoIf Go had macros, it wouldn't have been as successful as it is. The appeal of Go is that it's both very readable and very writable, even if verbose.
- bbatha 8y agoGo already has code generation built into the standard tooling. It also has reflection which is arguably worse because the generated code is totally opaque. Good macros would cover most of the uses cases for the tools in a more cohesive and more tooling friendly way.
- cesarb 8y ago> Consider the "try!/?" pseudo-macro from Rust. On Rust, try! is not a pseudo-macro, it's an actual macro (which could be defined by anyone, since it uses only the public API for Result and From). Go to https://doc.rust-lang.org/std/macro.try.html https://doc.rust-lang.org/std/macro.try.html and click on the [src] link at the top to see its current definition.
- platinumrad 8y agoI called it a pseudo-macro because while "try!" is a macro, its usage is discouraged in favor of "?", which is an operator.