Hacker News Reader

Comment by dvt | Hacker News Reader

> knows that a huge chunk of why it's so excellent is the macro system

Macros are bad and you're bad if you use them. This has been essentially a de facto mantra since the early 90s (when I was a wee lad) and it's quite common to see people writing very long articles on why you shouldn't use them[1]. They are magic, so should be avoided.

There's a reason languages like C# or Go don't have them, and you should take heed of the very smart people that designed these languages. Even in Rust, they are controversial[2] (the most obvious reason is that your IDE is worthless when macros are involved). Metaprogramming (i.e. macros) adds extreme complexity (in some cases, pre-runtime-Turing-completeness) with many footguns, including the classic, and very "fun," double evaluation.

Here be dragons.

[1] https://www.linkedin.com/pulse/why-considered-bad-practice-u...

[2] https://www.reddit.com/r/rust/comments/taxfe3/what_are_the_p...

View on HN

C# _does_ have a macro system. See https://dotnetfiddle.net/y3zFQ4 for example. This has a macro called Foo which, when calls, prints out the AST of the given expression. It could also manipulate part of the expression and evaluate it, if desired.

> There's a reason languages like C# or Go don't have them,

Go has a quasi macro system though (go generate)

https://gradha.github.io/articles/2015/01/the-day-go-reinven...

I like the macro systems in Crystal and Haxe (reifed macros)

https://haxe.org/manual/macro-reification-expression.html

https://crystal-lang.org/reference/1.8/syntax_and_semantics/...

I think C would have benefited from such system at the AST level instead of text substitution.

Javascript is dynamic enough there is absolutely no need for Macros.

> Javascript is dynamic enough there is absolutely no need for Macros.

TypeScript macroses would be very useful for the same things codegenerators are useful: for example generating api client from swagger schema. Ofc you can do some trickery with metaprogramming, for example build and eval strings on fly and the result could be a dynamically generated function, but the point is: we want the process and the result to be typesafe and efficient, which is what is missing with hacky dynamic metaprogramming approaches.

A swagger schema looks like YAML with a finite set of types. I don't see why you'd need to use eval in that case when from one hand you already have the schema in a javascript object and the other hand a simple builder pattern would build your API directly from that schema. Absolutely no need for macros.

Generally speaking, because it would be very nice to have types without having to do offline code generation.

I'd argue Turing completeness is bad also, Rices theorem and all. But like with macros, sometimes you just need to accept and deal with the badness because the alternatives are worse (or undiscovered).

If magic was unnuancedly bad we'd all be using assembly. Rust-style macros are a tradeoff; you get constrained magic, localized to the spot where you said `!`. Presenting using them at all in Rust as 'controversial', with a Reddit thread that says nothing of the sort, is disingenuous; proper Rust usage is littered with macros (and the presentation of said 'mantra' would be news to any Lisp user).

As is usually the case, it depends. Macros for “reducing boilerplate” or other syntactic reasons are poorly justified. While the resulting code might look cleaner, it’s often much harder to decipher (JS “decorators” suffer from the same issue). Macros can be invaluable for trading compile time for runtime performance, compensating for missing language features, and general metaprogramming… in a compiled language. It’s beyond me why would anybody think that macros are a good fit for interpreted JS.

Reply on news.ycombinator.com