Oldschooling
Sep. 15th, 2014 03:13 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
migmitIt's XXI century. We have flying cars now. What we also have, is a lot of research in programming languages. We have heavy books on refactoring. We have tons of "best practices". And then...
You know, a while ago I bitched about generics in Rust not being really generics, but rather templates, as they are specialized for every type they are used with. In fact, they are more limited than templates, as they don't allow partial specialization.
A few days ago I got wind that they finally woke up and implemented generics as, well, generics. I've checked immediately, and, no, we are still at the same spot.
But then another thought came: how can they specialize generic functions for types they know nothing about? I mean, if module A defines a generic function, and module B uses it with the type also defined in B, and A is compiled first — there is no possible way to specialize this function for the type defined in B, right? C++ avoids this by having all templates implemented in header files, so that they are available when compiling B — which really means that the function is NOT compiled with A (unless it uses it with some other type), but rather with B. Rust can't do that, after compiling the module you can safely remove the source code, and it will work fine.
And somebody answered my question with this: http://www.reddit.com/r/rust/comments/2c6pn0/how_does_rust_implement_calling_generic_functions/cjcio0p
Yep. They keep the source code in the compiled file.
Well, not EXACTLY the source code — the AST. But the difference is, in my book, négligeable.
Yeah. It's THAT bad.
On the other hand, there is Go — which is another new language, intended to fill the same niche as Rust — or at least a close one. It solves the problem with generics elegantly and efficiently — by not having generics. At all.
Which is fine, if there were hope that generics would emerge in some later version — like it was with Java. But it seems that Go people rather enjoy not having generics: "Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it."
Yes, its XXI century, and the earth is doomed.
You know, a while ago I bitched about generics in Rust not being really generics, but rather templates, as they are specialized for every type they are used with. In fact, they are more limited than templates, as they don't allow partial specialization.
A few days ago I got wind that they finally woke up and implemented generics as, well, generics. I've checked immediately, and, no, we are still at the same spot.
But then another thought came: how can they specialize generic functions for types they know nothing about? I mean, if module A defines a generic function, and module B uses it with the type also defined in B, and A is compiled first — there is no possible way to specialize this function for the type defined in B, right? C++ avoids this by having all templates implemented in header files, so that they are available when compiling B — which really means that the function is NOT compiled with A (unless it uses it with some other type), but rather with B. Rust can't do that, after compiling the module you can safely remove the source code, and it will work fine.
And somebody answered my question with this: http://www.reddit.com/r/rust/comments/2c6pn0/how_does_rust_implement_calling_generic_functions/cjcio0p
Yep. They keep the source code in the compiled file.
Well, not EXACTLY the source code — the AST. But the difference is, in my book, négligeable.
Yeah. It's THAT bad.
On the other hand, there is Go — which is another new language, intended to fill the same niche as Rust — or at least a close one. It solves the problem with generics elegantly and efficiently — by not having generics. At all.
Which is fine, if there were hope that generics would emerge in some later version — like it was with Java. But it seems that Go people rather enjoy not having generics: "Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it."
Yes, its XXI century, and the earth is doomed.
no subject
Date: 2014-09-16 08:27 am (UTC)no subject
Date: 2014-09-16 10:40 am (UTC)1. A lot of things being written in C++ where inlining is performed earlier, so LTO is not so important there.
2. Typical C code doesn't do so many calls to little functions as would a language full of type classes do, so again, not so crucial for C as for Rust-like.
3. Inertia.
4. Probably low gain from LTO for C. Which means C++ and other aggressively inlining and optimizing languages are bound to be faster than C. Canonical example is sorting: C++ blows C out of the water, being able to inline the comparison instead of calling a function each time.
no subject
Date: 2014-09-16 03:29 pm (UTC)no subject
Date: 2014-09-16 06:03 pm (UTC)no subject
Date: 2014-09-16 07:22 pm (UTC)