What do you think would have happened? I know @stebalien said it worked, but why did you think it didnt?
Haha, I typod that!
struct Point<S>([u8; S]);
[quote="stdsync, post:18, topic:1815"]
No, that's what I consider C.
[/quote] I consider C just as relatively simple language for low lever or system programming tasks. Its productivity is heavily relayed on the wise usage of the well-defined simple conceptions and models(like linear adress space, pointers, stackframes, calling by values...). yet thouse conseptions are in the greate synergy with underlaying hardware/ So understanding of the conceptions and the hardware (or system) models is the key to the most effective C programs. On the Rust's side we have typical C layer+functional programming layer/The last one has no simple interpretation in the terms of the low level concepts.... more over it has never been designed for it or for the speed. So i see no ways for extra optimizations - but forecast a whole bunch ineffective (among C-s typical tasks) progs... But I admit there is the good chance for Rust to find its domen specific area (as did Google Go).
Well, I'll have to let Rust core developers reply to that. Fact is that Rust is already in C's ballpark in most benchmarks, and the work that has been done for pure functional languages like Haskell (which are hard to get running fast) is very promising. Both show that raw speed can be safe
Ah yes, you are right. That is definitely something that a lot of people are missing in Rust.
I wonder if there are there any current proposals on type level integers?
1 Like
It's not good kind of the arguments...On the some tasks one can find old Fortran better than C (with very simple reason for)...Yet for some decades C had no match in the many fields of the applications in wich it is not well suited.. just due to harsh underlaying hardware limitations. So there are open road for speculations with speed for "special" cases.