Things Rust shipped without • Hacker News Board

Re: Things Rust shipped without

#271

Post by kzrdude » Sat, Jul 04, 2015, 2:02 PM UTC

JoshTriplett wrote: post #122

SomeCallMeTim wrote: post #86

Earlier quoted context omitted.

Which is actually a useful feature in some obscure optimizations, like this fast (approximate) square root: float half_r=r*0.5F; union { float y; int32_t i; }; y=r; i=0x5f375a86-(i>>1); y=y*(1.5F-(half_r*y*y)); return y;

If you want to reinterpret a float as an integer or vice versa, you can do that easily enough with Rust's unsafe functions: fn approx_invsqrt(r : f32) -> f32 { let y : f32 = unsafe { let i : i32 = std::mem::transmute(r); std::mem::transmute(0x5f375a86 - (i>>1)) }; return y*(1.5-(0.5*r*y*y)); } fn main() { println!("approx_invsqrt(2.0) = {}", approx_invsqrt(2.0)); } Result: approx_invsqrt(2.0) = 0.70693

And Rust specifies their floats to be IEEE 754, so it always works (endianness may apply though).

Re: Things Rust shipped without

#272

Post by pjmlp » Sat, Jul 04, 2015, 2:03 PM UTC

geofft wrote: post #218

jlarocco wrote: post #194

I'm sorry, but I have a hard time being impressed by any of those. They're all just fixing things that were busted in C. I mean good for Rust, but C is a pretty low bar. Does any language created in the last 20 years make those same mistakes?

Rust is the first language that fixes all of these things, can be used as a replacement for all of C's use cases (including ABI-stable libraries, kernels, etc.), and has a sufficient community / mindshare that you can expect libraries to exist in the language for functionality that you generally expect to find in libraries. Maybe we should be embarrassed as an industry that it took us 20 years to get there, yes.

Many of the Rust fixes, aren't an issue in Ada, Modula-2, Modula-3, Turbo Pascal, Delphi, Oberon, Oberon-2, Component Pascal, Eiffel, Dylan...

However in those 20 years we saw the rise of UNIX in the industry and with it C and C++, to the point those languages lost mindshare and are only known to those that experienced the IT world before they got widespread.

So new generations have to re-learn system programming without C and C++ way of doing things is possible.

Re: Things Rust shipped without

#273

Post by sklogic » Sat, Jul 04, 2015, 2:07 PM UTC

pjmlp wrote: post #264

sklogic wrote: post #253

Earlier quoted context omitted.

If you're not implementing fast FSMs, fast bytecode interpreters (and dynamic dispatchers in general), and you're not using metaprogrming to the full power, not implementing multiple embedded DSLs - then you can live without a goto. Otherwise it is essential.

Metaprogramming to the full power sounds like Lisp. It doesn't have goto.

> Metaprogramming to the full power sounds like Lisp.

It does, yes, although many Lisps got a pretty limited backend for this sort of things. My preferred metaprogramming environment must have a fallthrough mode for allowing generating low-level code where Lisp semantics is not sufficient. Rust seems like a very good target platform in this sense, so the lack of goto really hurts.

> It doesn't have goto.

Of course they do (tagbody in Common Lisp, for example). And when they don't, it's often relatively easy to add one.

Re: Things Rust shipped without

#274

Post by sklogic » Sat, Jul 04, 2015, 2:34 PM UTC

eddyb wrote: post #252

beeforpork wrote: post #250

Earlier quoted context omitted.

If Rust misses 'goto', it is not suitable for translating SSA into it, which most compilers natually produce (also for LLVM, obviously). I.e., it is not suitable for being used in a compiler backend. Here, it can never fully replace C. 'goto' should not be daemonized, we know better today.

I don't follow, why would SSA need to be translated into an input language? LLVM used to have a C backend, yes, but that hasn't been maintained for a while now.

> I don't follow, why would SSA need to be translated into an input language?

Rust is a meta-language with very powerful macros in it.

What is a macro? Macro, essentially, is a compiler. You can have some petty macros implementing tiny syntax sugar on top of your language, that's totally fine, but that's not their purpose.

The real metaprogramming kicks in when you implement very high-level eDSLs on top of your macros. And for this sort of things, having a proper compilation pipeline is a must. Many eDSLs may end up being represented as an SSA. E.g., I'm doing this with a Packrat eDSL - it pays to represent its intermediate language as an SSA for doing some high level optimisations before spitting out the host language code.

Re: Things Rust shipped without

#275

Post by phaylon » Sat, Jul 04, 2015, 2:41 PM UTC

andrepd wrote: post #12

What about things that Rust shipped without that should have been included?

Or to continue the train of thought, what about things that it did ship with that could have been excluded? :)

Personally I'm starting to dislike index operations since they can panic (and are the shortest way to access), and I rather use the explicit Option based APIs. Though I'm not too worried about those, since a lint disallowing them shouldn't be too hard.

Re: Things Rust shipped without

#276

Post by jacquesm » Sat, Jul 04, 2015, 2:41 PM UTC

sklogic wrote: post #270

jacquesm wrote: post #268

Earlier quoted context omitted.

Yes, there may be exceptions when this kind of code is preferable. But it's definitely not the rule and the speed difference between the one and the other is so small that only a profiler can guide you to optimizations like these.

> Yes, there may be exceptions when this kind of code is preferable. In my practice these exceptions are ubiquitous. Multiple tiny interpreted DSLs (which cannot be compiled more efficiently for the latency reasons), efficient protocols, all that stuff. System programming, in other words, and it's exactly the stuff Rust was supposed to be designed for. > But it's definitely not the rule and the speed difference betwe…

2-4 times is a spectacular speed-up, of course the inner loop of an interpreter is important but you're implying the rest of the code-path is only 3-4 instructions long (otherwise you can't get that kind of speed-up) which I find hard to believe. Even the inner loop of an interpreter usually calls routines that are longer than the inner loop itself. Is there a particular benchmark you have in mind for that 2-4 number?

Re: Things Rust shipped without

#277

Post by mafribe » Sat, Jul 04, 2015, 3:07 PM UTC

sklogic wrote: post #274

eddyb wrote: post #252

Earlier quoted context omitted.

I don't follow, why would SSA need to be translated into an input language? LLVM used to have a C backend, yes, but that hasn't been maintained for a while now.

> I don't follow, why would SSA need to be translated into an input language? Rust is a meta-language with very powerful macros in it. What is a macro? Macro, essentially, is a compiler. You can have some petty macros implementing tiny syntax sugar on top of your language, that's totally fine, but that's not their purpose. The real metaprogramming kicks in when you implement very high-level eDSLs on top of your macro…

The compiler implementing the macros (a form of compile-time meta-programming) should be the same compiler as that for the rest of the language.

Re: Things Rust shipped without

#278

Post by DannyBee » Sat, Jul 04, 2015, 3:18 PM UTC

" Next time you're in a conversation about language design and someone sighs, shakes their head and tells you that sad legacy design choices are just the burden of the past and we're helpless to avoid repeating them, try to remember that this is not so."

I think rust is neat, but this is somewhat arrogant.

Rust is amazingly young. 10-20 years from now, when rust hopefully has bajillions of users, if this is still true, then you can say it. I mean, do you really believe that Rust won't have things that turn out to be warts from 1.0 it can't remove 10-20 years from now?

Re: Things Rust shipped without

#279

Post by justthistime_ » Sat, Jul 04, 2015, 3:32 PM UTC

DannyBee wrote: post #278

" Next time you're in a conversation about language design and someone sighs, shakes their head and tells you that sad legacy design choices are just the burden of the past and we're helpless to avoid repeating them, try to remember that this is not so." I think rust is neat, but this is somewhat arrogant. Rust is amazingly young . 10-20 years from now, when rust hopefully has bajillions of users, if this is still tr…

Exactly. It's not like we don't know plenty of mistakes yet, which will bite them a few years down the road.

Re: Things Rust shipped without

#280

Post by mbrubeck » Sat, Jul 04, 2015, 3:33 PM UTC

jroesch wrote: post #240

milspec wrote: post #227

Earlier quoted context omitted.

Rust should have untagged unions. Obviously, ones that allow pointer abuse would be restricted to code marked unsafe. Note that a union of two pointer-containing structs is safe as long as the pointers line up, having the same type and offset in each struct.

Do you have a compelling use case? I can't imagine a use for untagged unions in Rust that isn't subsumed by other features in the language.

The most common use case would be interop with C libraries that use untagged unions. This is a significant hassle when writing C bindings in Rust today.