3 ms·

> You might as well bite the bullet accept that the people who say “You guys are dumb, just copy Zig’s type system” have a point, and shed some of the ivory tow

> You might as well bite the bullet accept that the people who say “You guys are dumb, just copy Zig’s type system” have a point, and shed some of the ivory tower dogma in exchange for a better language. The fact that you call it "dogma" (and your other comments about Zig) suggests that you aren't going to be very open to changing your mind on this. But as far as "the touted advantages" go, I've experienced them firsthand. Being able to write generic code and know that if the code compiles in your library, it will compile for people who depend on it, is a pretty nice workflow. Being able to change that generic code and still be confident it will still compile for downstream users who download the new version is pretty nice too. Being able to download some random dependency full of generic code, and to instantiate that code without having to dread reading mile-long call stacks that end with "foo.bar is not implemented in this function you didn't write" is pretty nice too. (And yes, post-monomorphization errors can still happen in theory; I've never seen one happen in practice, certainly not with the frequency I saw the mile-long call stacks in C++.) Those aren't some aesthetic details that language designers cling to out of some perfectionist desire to keep the language theoretically pure. It's part of what makes pulling dependencies especially painless in Rust.

gpderetta 3y ago
I don't want to discount the usefulness of definition-time type checking of generics, but (compile time) tests against archetypes are an obvious way to make sure that your generic code instantiates correctly.
j-pb 3y ago
There a million ways your code can break downstream dependencies, generic code is just one of them. Breaking stuff when you change things is just in the nature of it, which is why not changing APIs is so important. But I'd rather have the compiler errors you describe as something my IDE can jump to, than to spend hours poking around in opaque macro black boxes, because half of every library is a huge chunk of copy pasted code and macro magic to get around the type system. Rust as is, is a de Bruijn criteria fulfilling proof language, with the macro system ending up as the meta language.

gpderetta 3y ago

I don't want to discount the usefulness of definition-time type checking of generics, but (compile time) tests against archetypes are an obvious way to make sure that your generic code instantiates correctly.

j-pb 3y ago

There a million ways your code can break downstream dependencies, generic code is just one of them. Breaking stuff when you change things is just in the nature of it, which is why not changing APIs is so important. But I'd rather have the compiler errors you describe as something my IDE can jump to, than to spend hours poking around in opaque macro black boxes, because half of every library is a huge chunk of copy pasted code and macro magic to get around the type system. Rust as is, is a de Bruijn criteria fulfilling proof language, with the macro system ending up as the meta language.