3 ms·

I keep thinking they could add macros instead but I guess the C++ version is too much history for them to be associated with. It would basically be like code ge

I keep thinking they could add macros instead but I guess the C++ version is too much history for them to be associated with. It would basically be like code generation at compile time, except much cleaner than the current, version-specific mess of tools.

candiodari 8y ago
They have macros. Sort of. Search "go generate".
- andy_ppp 8y ago
  It looks gross. Why not quote and unquote - it makes it so much easier to reason about...
- aikah 8y ago
  This isn't a macro language. It relies on an external program that the developer needs to write himself at first place. "go generate" just facilitates the execution of a third party program. It does nothing more, and doesn't even do it automatically when compiling a program.
emersion 8y ago
Macros are another can of worms. Even if they're AST-aware like in Rust, you can do very complicated stuff with them and they are very hard to read/write/debug. This would kill the advantage that it's very hard to write obscure Go code.
- heavenlyblue 8y ago
  >> his would kill the advantage that it's very hard to write obscure Go code. But it's very easy to spread that Go code into tens of Kloc. The amount of error handling and if constructs make me feel as if I am readying assembly: predictable AF, but it doesn't help because the volume of the code is huge.
  - robmccoll 8y ago
    That's so true. It would be great to be able to have very limited / very short macros as a compromise. var a = n1; if a < n2 { a = n2 } vs. var a = max(n1, n2) without having to write and make a function call. I still want something more powerful for error handling like a type that if it is ever assigned non-nil the method returns immediately. var err autoreturn error rslt, err = pkg.MaybeError()
  - j16sdiz 8y ago
    This is true. But it is go design philosophy not to hide too much magics, it favours verbose, explicit codes. Design choice. You can't have both.

candiodari 8y ago

They have macros. Sort of. Search "go generate".

andy_ppp 8y ago
It looks gross. Why not quote and unquote - it makes it so much easier to reason about...
aikah 8y ago
This isn't a macro language. It relies on an external program that the developer needs to write himself at first place. "go generate" just facilitates the execution of a third party program. It does nothing more, and doesn't even do it automatically when compiling a program.

emersion 8y ago

Macros are another can of worms. Even if they're AST-aware like in Rust, you can do very complicated stuff with them and they are very hard to read/write/debug. This would kill the advantage that it's very hard to write obscure Go code.

heavenlyblue 8y ago
>> his would kill the advantage that it's very hard to write obscure Go code. But it's very easy to spread that Go code into tens of Kloc. The amount of error handling and if constructs make me feel as if I am readying assembly: predictable AF, but it doesn't help because the volume of the code is huge.
- robmccoll 8y ago
  That's so true. It would be great to be able to have very limited / very short macros as a compromise. var a = n1; if a < n2 { a = n2 } vs. var a = max(n1, n2) without having to write and make a function call. I still want something more powerful for error handling like a type that if it is ever assigned non-nil the method returns immediately. var err autoreturn error rslt, err = pkg.MaybeError()
- j16sdiz 8y ago
  This is true. But it is go design philosophy not to hide too much magics, it favours verbose, explicit codes. Design choice. You can't have both.