Hacker News Reader

Comment by JustSomeNobody | Hacker News Reader

Being a developer myself, I'm well aware of this. Still, it's ugly.

When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug.

This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too much fancy template stuff is being baked into the low level libraries. This may not end well.

C++ went down this road. The template system turned out to be more powerful than intended. Then people started writing cool stuff as fancy templates. Then the C++ committee added features to support the fancy templates better. Overly elaborate templates damaged C++; nobody could figure out what was going on. Use of C++ for new work declined.

All of this comes from smart people with good intentions. But when there's too much of this stuff, the mental load required to keep up with all of it becomes excessive. Especially if it changes a lot.

This is silly. Rust could not achieve its performance and safety goals without macros and generics. Generics may have been optional for Go (I don't agree, but let's go with it), but there is no way to achieve zero-cost memory safety without generics (while supporting first-class references and dynamic allocation).

Rust generics are deliberately less expressive than C++ templates, in that they're strongly typed. That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability.

This is a terrible example if you want to prove that point, anyway. This 6502 assembler is obviously a total abuse of the system, and nobody will deploy it to production. It's a neat hack, and that's all. Nobody would use an obfuscated quine written in Go to argue that Go is unreadable. This is exactly analogous.

Finally, Diesel is just an ORM. It uses exactly enough features to be an ORM; the only "problem" with it is that it's an ORM.

Animats had a very important point. While magic is so attractive and perhaps even useful in moderation, it causes so much damage in a large code base.

In C++, you get this damage from for example operator overload abuse (ok for math, not many other defensible uses), template abuse (ok in moderation), ninja exceptions and inheritance (especially multiple inheritance, ugh).

Anyways, if Rust proves to be a feasible workhorse building medium/large systems with bigger teams, it does sound interesting to me. Especially catching concurrency issues at compile time.

I just hope it won't ever become another C++.

And my point is that nobody would ever deploy this to production. Would you say you're worried about Go becoming C++ if someone posted a quine written in Go to HN?

By the way, Rust has no "template abuse", "ninja exceptions", or "inheritance".

I do think Rust is currently the most likely language to become the C++ killer. And attract significant number of developers from other major commercial languages/platforms as well.

Rust might eventually become the new industry standard. That'd be a clear improvement for sure.

But we'll see what happens. Hopefully there'll be no Rust committees at least.

You end up with it in production because some lower level library uses it.

No Rust production program will ever transitively depend on a library with a 6502 assembler written in the macro language.

You are missing the point.

It is not the ORM library or the 6502 Assembler.

It is the library written by the clever guy on the third floor from blue team, for the new product being developed at Corpo X.

However I also have seen lots of convoluted code, exactly because such expressiveness is missing from the language.

For example, JVM bytecode manipulation or use of external code generators.

> However I also have seen lots of convoluted code, exactly because such expressiveness is missing from the language.

That's the operating point here. Leave out expressivity, and tons of programmers write convoluted code. Leave it in, and a couple of clever people use it in an over-clever way.

> That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability.

In what sense are Rust macros "strongly-typed"? D and C++ templates are also strongly typed, just like the rest of the language.

Rust generics are strongly typed. C++ and D templates are, however, untyped. You can get errors at template instantiation time in C++ and D, because the compiler makes no attempt to ensure that the types your template operates on actually support the operations you're performing on them at the time you declare the template. In Rust (and basically every other language), though, the compiler typechecks your templates at the time you write them, so template instantiation can never result in errors inside the template.

Ah, I see. I'm assuming then that Rust generics are not generative templates like C++/D, but closer to Java/C#.

They're like Java/C# syntactically. Implementation-wise, they're monomorphized (code is generated for each specialization at compile time) like C++.

Maybe there still should be a compiler option to automatically evaluate the degree of abstraction complexity of a code, much like cyclomatic complexity, to prevent abuses ?

Not that I agree with your point, but cyclomatic complexity checks are actually implemented as a compiler plugin in rust-clippy project[1]. You'll get a compile time warning if your function becomes too complex.

[1]: https://github.com/Manishearth/rust-clippy/wiki#cyclomatic_c...

> It's so easy to write useful but awful things with them, and they're really hard to fix and debug.

And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.

Back when I did a 4GL with them, my amateur trick was to write and test them like normal programs first. Then in the templated form as a normal program. Then do macros. On first two, I can use any technique known to benefit software quality. For programming in the large, interface checks that enforce correct usage are a straight-forward solution.

Curious, with your LISP and ML background, what method or methods do you use to ensure your macros are correct and easy to debug?

A couple of very simple tricks:

Macros must be staged - similarly to a good practice of not having too big functions, macros also must be small, and must transform code in small steps, with more macros further breaking the result down. Ideally, each macro must be a trivial rewrite doing only one small thing.

Another trick is to have a bunch of macros that would inject debugging output when enabled. Wrap every macro definition body in such a macro, and, with debugging turned on (can be selective), both source and output would be displayed. Another macro can be used to inject debugging info into a generated code.

I usually start writing macros the other way around - not from a code I'd like to see generated, but from a final form. Once I find the code with macros passable, I'll start implementing the macros, in small steps.

Same applies to a DSL design in general - first I write a code I want to see, and only then I fill in an implementation.

I can't remember the exact quote but :

LISP's FOR macro got so clever that LISP programmers do everything they can to avoid using it

> This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this.

> C++ went down this road.

Also a big problem in the Haskell community. Trying to prove all sorts of complicated properties in a simple type system leads to overcomplicated design.

I don't think I'm against static code generation. But it incurs mental overhead. If you do it using a language which wasn't designed for that, much more so.

I can partly understand your points. I actually hated the "traditions" like Just Another Perl Hacker because it strongly gives an illusion of Perl as an obfuscated language.

My corresponding counterpoint is that you can write an obfuscated code in any language, no exception---probably a side-effect of Turing-completeness. If people has a general dislike towards too much magic and magic can be replaced with science^W saner alternatives there is no problem. The problem arises when you have to rely on magic for the certain class of tasks; it's no doubt that C++ (even the modern one) has this problem, but I think it is too early to claim that Rust has the same symptom.

> This is getting to be a big problem with Rust.

I haven't seen any examples of this happening in actual code. Sure, you have lots of toy things but that's just stuff people do for fun.

And as was adequately explained in that thread, ORM is an existing pattern from other languages that people like using. It's got some nifty benefits to it; so while it's not what you'd usually do it's not an overcomplication. Like Patrick said, its only "problem" is that it's an ORM.

> Overly elaborate templates damaged C++; nobody could figure out what was going on. Use of C++ for new work declined.

This happens because C++ templates aren't typechecked, so working with them requires you to understand their internals to some degree ("what kind of type does this expect?"). Rust generics are typesafe. Rust macros aren't, but they're not encouraged as much as generics/templates are so you don't see much convoluted things except as fun experiments (who doesn't want to write a brainfuck interpreter in rust macros?). People understand that macros will give substandard error traces and mostly only use them for quick and straightforward deduping of code.

Reply on news.ycombinator.com