Hacker News Reader

Comment by andy_ppp | Hacker News Reader

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.

View on HN

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.

>> 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.

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()

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.

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

It looks gross. Why not quote and unquote - it makes it so much easier to reason about...

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.

Reply on news.ycombinator.com