Because of memory safety? Because you want low-level control without absolute speed? Because of a small memory footprint? Because of having a good async story without giving up a lot of speed?
There are plenty of other features to Rust then "absolute speed". Just because that's *your* usecase for it doesn't mean you should force it on others. On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel <[email protected]> wrote: > > Even though Rust is a performance conscious language (since it aims at > displacing C and C++), the 80/20 rule still applies and most of Rust code > should not require absolute speed > > This is a mistaken assumption. Systems programming exists on the extreme > end of the programming spectrum where edge cases are the norm, not the > exception, and where 80/20 does not apply. If you don't require absolute > speed, why are you using Rust? > > > On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq < > [email protected]> wrote: > >> I am not a fan of having wrap-around and non-wrap-around types, because >> whether you use wrap-around arithmetic or not is, in the end, an >> implementation detail, and having to switch types left and right whenever >> going from one mode to the other is going to be a lot of boilerplate. >> >> Instead, why not take the same road than swift and map +, -, * and / to >> non-wrap-around operators and declare new (more verbose) operators for the >> rare case where performance matters or wrap-around is the right semantics ? >> >> Even though Rust is a performance conscious language (since it aims at >> displacing C and C++), the 80/20 rule still applies and most of Rust code >> should not require absolute speed; so let's make it convenient to write >> safe code and prevent newcomers from shooting themselves in the foot by >> providing safety by default, and for those who profiled their applications >> or are writing hashing algorithms *also* provide the necessary escape >> hatches. >> >> This way we can have our cake and eat it too... or am I missing something >> ? >> >> -- Matthieu >> >> >> >> On Sun, Jun 22, 2014 at 5:45 AM, comex <[email protected]> wrote: >> >>> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay <[email protected]> >>> wrote: >>> >> Er... since when? Many single-byte opcodes in x86-64 corresponding to >>> >> deprecated x86 instructions are currently undefined. >>> > >>> > http://ref.x86asm.net/coder64.html >>> > >>> > I don't see enough gaps here for the necessary instructions. >>> >>> You can see a significant number of invalid one-byte entries, 06, 07, >>> 0e, 1e, 1f, etc. The simplest addition would just be to resurrect >>> INTO and make it efficient - assuming signed 64 and 32 bit integers >>> are good enough for most use cases. Alternatively, it could be two >>> one-byte instructions to add an unsigned version (perhaps a waste of >>> precious slots) or a two-byte instruction which could perhaps allow >>> trapping on any condition. Am I missing something? >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
