Conversation

Graydon Hoare
@graydon_pub
I won’t @ them but limiting expressivity in order to limit cognitive load and keep codebases approachable is a totally legitimate move in language design. I’d even say essential. It’s all about balance, and expressivity _does_ have tradeoffs.
Quote Tweet
¯\_(ツ)_/¯
@SeanTAllen
·
Almost all the arguments I see against generics in go are pretty awful. "People might create abstractions I can't understand" is an awful argument. And that's the root of most argument I see. That's so broad that you can apply it to the base language itself. Don't @ me.
Show this thread
9
126
soc
@oxnrtr
Seeing the draft, I'm not sure it's practical to retrofit Generics into the lang without making it completely unreadable. The first rule of language design should be: “You got 4 pairs of brackets: (), {}, [] and <>. Use them wisely." A lesson Rust failed to learn, too, though.
1
1
soc
@oxnrtr
I believe that Rust 2 will be the point in history where it shows whether Rust is able to only grow new features and will go the way of C++, or if its current designers are able to acknowledge & correct mistakes (like abusing <> for generics) and manage to reduce some complexity.
2
soc
@oxnrtr
It was a decision made with decades of precedent of <> working out poorly, and with dozens of languages as evidence which tried to work around the innate problems and failed. But so is language design ... two steps forward, three steps back. ¯\_(ツ)_/¯
2
Stephan Tolksdorf
@s_tolksdorf
Could you elaborate on the problems you're having with <> being used for generics? In C++ it sometimes hurts the readability of expressions specified for non-type template parameters, but other than I can't think of any significant issues.
1
soc
@oxnrtr
- Poor readability compared to []. - Almost impossible to parse without sacrificing consistency in other parts of the language. - Leads to inconsistent usage of all the language's brackets. - Has lead to confusing syntax in every lang: <> vs. ::<>, new <A>B<C>(), D.<E>f() etc.
1
Stephan Tolksdorf
@s_tolksdorf
It's not clear to me that [] for template parameters would be more readable. Since brackets are also used for array types, indexing operators and lambda capture lists, that syntax wouldn't be conflict-free either, at least in C++. And in the eyes of a C++ programmer '<' being ...
3
soc
@oxnrtr
I'm not really seeing this complexity here. You could just do the same thing as vec! – or realize that varargs are annoying to implement for compiler authors, but a necessary part of a language and add them proper, instead of making people go the macro route to emulate varargs.