Hacker News Reader

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any.

Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use for the rest of your program.

Even _if_ you draw the line between macro writers and users, you've effectively made macros a black box you're not supposed to look into. Having trouble debugging anything related to a custom derive or a macro? Too bad, macro's are hard. This is (a) not useful and (b) not necessary, as Zig clearly shows.

I think Rust made the C++ mistake of trying to accommodate everyone by having both low level control of things, but not too low level since that's dangerous, so we'll come up with some rules that you can't break, and oh by the way the rules aren't really ready yet, oh, and if you're not used to dereferencing pointers, don't worry we have this deref trait, what's a trait you say? and so on and so on.

It's effectively a barrier to entry, which, ironically, is a thing the Rust community tries really hard to combat.

If you mix a bunch of nice colors, blue, red, green, turqouise, purple, orange, eggshell white, you just get ... brown.

> the Rust community tries really hard to combat

How? My impression is that they are not trying to do the language easier at every release. Contrarily, I see more new features added all the time (which is a good thing if Rust is your thing).

What I see is top-quality documentation. No doubt about it. Perhaps they focus on quality learning material, but the truth is the more I read, the more I scratch my head thinking "what is this construct and when and why do I need to use this?". Then overchoice[1] anxiety kicks in and I go back to zero, that is, my good old C.

[1] https://en.wikipedia.org/wiki/Overchoice

On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library.

I understand why it is this way but it is very much not ergonomic

I think that what is lost in the conversation when this topic comes up is that the current macro alternatives, macros by example and procedural macros, are stop-gap features: the first is what was available in 1.0 that got stabilized with the explicit intent to deprecate in eventually (its replacement is an ongoing effort[1]) and the later is a minimal stabilization of compiler internals that had proven to be useful both internally and in nightly crates, where an API surface that we didn't mind maintaining into the future was stabilized.

The entire macro space in Rust (just like async/await) is in MVP status: they are available and useful already, but their current feature set and approachability isn't the end-state.

I know some will read that and think to themselves "Great! More changes to the language! See, they can't help themselves.", but these changes are about removing restrictions and tapering edges.

[1]: https://rust-lang.github.io/rfcs/1584-macros.html

The author is obviously in the top ~1% or something of programmers: the article is thoughtful and shows a lot of technical depth and knowledge about things most programmers won't even have heard of and he clearly has a fair amount of practical experience. So telling him he's just somehow imagining all this complexity and cognitive load, because he doesn't have to use all this complexity feels a tad tone deaf, in a very HN way.

> The author is obviously in the top ~1% or something of programmers

Appeal to authority much?

This reminds me of the (by now) old saying that code is more often read than written - sure, you're not forced to write macros, but if you use macros (or more exotic features), you force the developers who read your code to become familiar with (possibly arcane) features that they maybe would have never used (or needed). That's why I think Go's approach to not try to be "everybody's darling" by implementing every conceivable feature is commendable (even if mentioning this in a Rust-related thread will get me downvoted again).

As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.

Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.

On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...

This is a good observation. Some of the best codebases I’ve worked with are the ones whose authors insisted on keeping things easy to modify or remove (not by introducing unnecessary abstraction, but by simplifying things as much as possible). Some of the worst codebases are those where the author assumed that their elegant solution is ultimate and will never be read in circumstances other than to be admired.

I don't disagree, but this goes both ways (and I typically only see one side of this argument put forward). They also allow the person who designed the types to make the types so complex that the average user cannot understand what is going on. You may argue "well that person has no business looking at the code" but sometimes you have to look into other people's code when you are debugging an issue.

No doubt type systems can allow you to write safer, more robust code. But they can also allow you to introduce new risks to your codebase, one of which is difficult to read/understand code.

I don't think that people complain about Go's simplicity. People complain about the hamfistedness of Go's simplicity. The downstream effects of it include, for example the wat that you handle JSON in Go.

But there are a lot of quite frankly crazy choices, like making (milliseconds) an integer type that is incompatible with numbers. This means to multiply an time with a non-constant integer, you have to cast an integer to millisecond type first, then multiply. Which breaks the brain of a scientist like me and makes me want to throw my computer out the window.

My daily driver is Elixir, and it's not impossible to jump into totally foreign code and debug it. In fact, just the other day I did an interview where the 20 minute technical problem was drilling down from the frontend into the backend of a new-to-me system and finding the logic bug in a database query that was causing the wrong data to be surfaced.

I think your words come from experience.

It's not about how effortless the code is to write, but the total lifecycle effort. This includes for example maintenance, security, extending and on-boarding new team members.

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any.

I think one of the problems with this mindset is, you are only assuming the case with you have full control on the code-base e.g. writing thing from scratch so that you can only use those features in rust that you feel comfortable with, in other cases, you have little control on what others use.

> Complaining on pattern matching?

I've read that as a (minor) complaint that Zig doesn't have Rust's pattern matching, not that there's anything wrong with pattern matching (and that Zig's switch still does 90% of what the author uses Rust's pattern matching for).

As someone with lots of Rust experience I agree with the author. Rust has more concepts that users need to learn. It's not gratuitous/accidental complexity. Each of these features is IMHO pretty well designed and useful, but nevertheless Rust does have a larger toolbox.

It's not necessarily bad. Do you prefer to put more effort into your program before it compiles, or debug it after it's up an running? Do you want a static guarantee, or do you trust yourself to get it right? These are fair trade-offs.

> the author was overwhelmed

It strikes me that you start off meaning to rebut the author's point and end up supporting it.

Well, by that logic, Java is overwhelming if you dive right into Aspect oriented programming, the Atomics and Multi-threaded Java.

I don't consider myself an expert in Rust, but hell, the borrow checker was always helpful. I.e. even if it prohibited a sound program, it explained its reasoning at length. It was easy to fix the issue even if it came.

Macros are meta programming, of course they are hard. And even then, there are ways around. Like cargo-expand, it makes procedural macros easier to reason about.

Sure, the rust language is "simple" if you abstain from using 80% of the features of rust, but then it would be impossible to write non-trivial programs. Zig, on the other hand, gets rid of this 80% as well, AND still lets you write non-trivial programs.

You're right, but I find Rusts concepts/keywords also a bit confusing.

I know what a class and what an interface is, but Rust doesn't have these. It has a struct, which is kinda like a class without methods? It has a trait, which is kinda like an interface but with implementations for methods? It has ... implementations... which kinda make a struct to a class, but not really.

I don't mean to hate here, but these are all things that need to be understood in some kind of way.

Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.

I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.

I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just means that if you already know those, you will have to learn new concepts to learn Rust, which can be surprising if you aren't told about it ahead of time, particularly when you already know several languages that don't use traits.

I did learn much about classes and interfaces in university, independent of language.

But not much on traits and ADTs(?).

Can you recommend some general learning resources on that?

I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor.

ADTs are Abstract Data Types[1][2][3]:

> ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List is actually implemented.

In the context of Rust it means that the traits, structs and enums are ADTs, while the impls are Data Structures.

Having structs and enums be the way they are in Rust (simplistic and with little extensibility beyond implementing traits) is that pattern matching[4][5] and destructuring is cheap and built in. Pattern matching becomes specially useful when combined with sum types/tagged unions/enums[6][7][8]. On the other corner you have Scala which lets you implement specific interfaces to allow structuring and destructuring for arbitrary types, but that has the same problems as overriding constructors in C++: the performance implications of pattern matching is impl dependent and hidden at the point of calling.

[1]: https://softwareengineering.stackexchange.com/questions/1487...

[2]: https://en.wikipedia.org/wiki/Abstract_data_type

[3]: https://abrickshort.wordpress.com/2005/03/06/abstract-data-t...

[4]: https://en.wikipedia.org/wiki/Pattern_matching

[5]: https://docs.scala-lang.org/tour/pattern-matching.html

[6]: https://www.schoolofhaskell.com/school/to-infinity-and-beyon...

[7]: https://chadaustin.me/2015/07/sum-types/

[8]: https://stackoverflow.com/questions/2502354/what-is-pattern-...

Thanks!

I'm basically looking for a comparison of classes and ADT, I guess.

You said, applying your class-based way of doing things didn't work, so I asked myself how would you do it the ADT way.

ADTs are only concerned with the "shape" of the data and what interactions you can have. It is related to classical OOP in the sense that the "interactions" you can have are equivalent to the message passing from the original conception of OOP[1].

The distinction is similar to database design in SQL: the Schema is how the data is laid out and what the relationship between tables is (ADTs) while the queries is the operations performed on them (traits). On the other hand, in OOP there's a higher reliance on encapsulation, making behavior an integral part of what the class is and using inheritance for expansion. When all you have is ADTs, you _can't_ have inheritance, so you end up using composition (which is generally considered better design) and you are more likely to rely on the creation of "new-type" container types for everything. You think of them as a way to describe what the data is, not how you interact with it.

Apologies if this is a bit hand-wavy, I'll try to write a more thoughtful answer at a later time.

[1]: https://medium.com/javascript-scene/the-forgotten-history-of...

Hm, but composition over inheritence was already mainstream when I studied 10 years ago.

Also, ECS design is a thing in game development.

Are ADTs taken these concepts into language design?

Less rules doesn't mean simpler.

Also, I don't mean Rust is harder than C++ or Java. It's just quite different.

If you are used to visualizing software as graphs of functions or classes in your mind for years, switching to the Rust model is quite a change of thinking.