5 ms·

One feature that could achieve generics, eliminated `if err != nill{}` stutter, and allow for backwards compatibility: macros (borrowing the '@' prefix for mac

• mseepgood 8y ago
  Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".
  • thibran 8y ago
    No, they solve a complex problem. Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible. Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.
    • cageface 8y ago
      One big problem with macros is that they make it very difficult to build good tools. You can't really understand the meaning of any particular piece of syntax without completely evaluating any macros that might be in use.
      • Groxx 8y ago
        That sounds exactly like what a compiler has to do. And what all type-aware Go tools currently have to do. So we're already doing that, we just have no language-level support for doing so, so we have incredibly less-capable workarounds like makefiles and go:generate.
  • coldtea 8y ago
    Well, they sort of give the same message already, but with custom code-level solutions instead of macros... "Everybody go an invent your own way to handle error checking/propagation" etc...
  • nostalgeek 8y ago
    > Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore". I prefer safe AST based macro than runtime reflection like Go has. The latter is actually a cop-out, unlike the former in the context of type safety at compile time.
  • pjmlp 8y ago
    Instead one gets to use go generate for the same purpose.
• kodablah 8y ago
  At this point, Go would just see macros as automatically called code generation, which leads to an unpredictable speed reduction in compile times especially with large dependency trees. Slowing down compile times at any noticeable level is probably a non-starter based on language goals.
• kevhito 8y ago
  My preferred solution for the err handling stutter would be something like "whenever". func Foo(x int) (int, error) { var err error a, err := whatever() if err != nil { return 0, err } b, err := whatever() if err != nil { return 0, err } ... } becomes func Foo(x int) (int, error) { var err error whenever err != nil { return 0, err } a, err := whatever() b, err := whatever() ... } Essentially, "whenever" just means "insert this line at every point in the remainder of this code block where err is assigned a new value. It is explicit, simple, easy to understand, and would be identical in function to how most errors are currently handled.
  • LukeShu 8y ago
    Indent your code with 4 spaces to prevent HN from eating the newlines: func Foo(x int) (int, error) { var err error a, err := whatever() if err != nil { return 0, err } b, err := whatever() if err != nil { return 0, err } ... } func Foo(x int) (int, error) { var err error whenever err != nil { return 0, err } a, err := whatever() b, err := whatever() ... }
    • mseepgood 8y ago
      That's not error handling, that's error noticing. https://www.youtube.com/watch?v=Ph4eYD7Bgek&t=2m35s https://www.youtube.com/watch?v=Ph4eYD7Bgek&t=2m35s