Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

141–150 of 277 posts

Re: Announcing Rust 1.20

#141

Post by dbaupp »

steveklabnik wrote: post #106
jeffdavis wrote: post #97

Earlier quoted context omitted.

But in my example this is not hard to get right in C. The tree is constructed (on the stack would be fine), then used for a while without mutating it, then freed all at once. The thing that makes this hard in rust is destructors. If there's a cycle between A and B, and you destruct A first, then B, then B's destructor would see a dangling reference to A. And vice versa if you destruct B first. But I don't need destru…

> But I don't need destructors, or at least ones that can see these references, so it's frustrating. If you bound it so that it only accepts Copy types, then you can know there are no destructors.

The tree itself will need destructors to clean up allocations, and that's what's problematic here: if the tree is destroyed top down, the destructor of the children may access the parent which has already been invalidated, and similarly destroying bottom up risks the destructor of the parent accessing the children.

Re: Announcing Rust 1.20

#142

Post by steveklabnik »

burntsushi wrote: post #137
smegel wrote: post #134

Earlier quoted context omitted.

I swear I had read Rust had optional GC at one point. And similarly Rust wanting to own main(). Maybe not then.

I don't know the precise history, but at one point, it did have a "gc" type, which I believe was demarcated by the `@` sigil. So, for example, `@T` was a garbage collected pointer to `T`. IIRC, the actual garbage collector was simplistic, and was mostly just reference counting under the hood. At some point (in 2014, I think), the GC type went away. Since then, there has never been any serious talk of adding an option…

This is pretty accurate; however, a very long time ago there was a tracing GC!

Re: Announcing Rust 1.20

#144

Post by steveklabnik »

smegel wrote: post #134
steveklabnik wrote: post #130

Earlier quoted context omitted.

Rust doesn't have any more runtime than C, and also doesn't have a GC. Servo has bindings into SpiderMonkey's GC so that the JavaScript stuff works properly, but that's only that part. That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. (I don't work on Firefox though so I could be wrong about some details.)

I swear I had read Rust had optional GC at one point. And similarly Rust wanting to own main(). Maybe not then.

Rust had almost everything at some point :)

Rust binaries do define a "main", and setting that up is the runtime's job, like C. But you can also make a library that needs no main at all.

Re: Announcing Rust 1.20

#145

Post by leshow »

steveklabnik wrote: post #111
leshow wrote: post #107

Earlier quoted context omitted.

is bounded another word for ad-hoc? I always considered Rust's polymorphism implementation like Haskell's, and AFAIK they call it ad hoc polymorphism.

IIRC, "bound" has more to do with quantification than polymorphism more generally. There is "parametric" vs "ad-hoc". https://stackoverflow.com/questions/6730126/parametric-polym... has a link to the text of TAPL explaining the difference here. Rust traits and Haskell typeclasses would be ad-hoc.

That's interesting, I always assumed parametric polymorphism was a requirement of ad hoc polymorphism. I suppose I'm using a more narrow definition. On the opposite end,

Elm for instance, has parametric polymorphism:

type Parametric a = Parametric a

f : (a -> b) -> Parametric a -> Parametric b

f fn (Parametric a) = Parametric but no support for ad-hoc, like you said, in Haskell:

data Parametric a = Parametric a

f :: Ord a => Parametric a -> Parametric a -> Parametric a

f (Parametric a) (Parametric b) = Parametric (min a b)

Re: Announcing Rust 1.20

#146

Post by knz42 »

kbenson wrote: post #120
slavik81 wrote: post #89

Earlier quoted context omitted.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference: Rust: fn main() { let a: f32 = 1e7 + 0.5 + 0.5; let b: f32 = 1e7f32 + 0.5f32 + 0.5f32; println!("{}", a==c); // true } C: #include int main() { float a = 1e7 + 0.5 + 0.5; float b = 1e7f + 0.5f + 0.5f; printf("%s\n", a==b ? "true" : "false"); // false } That's awesome. I'm tot…

> While f might be a nicer suffice than f32, no suffix is even better. Well, isn't float in C and C++ platform dependent, and just usually 4 bytes on common platforms? I like the idea of being explicit in the storage type, even if it's slightly more verbose.

No. ISO C has standardized "float" to 32 bits and "double" to 64 bits. The one that's platform-dependent is "long double".

Re: Announcing Rust 1.20

#149

Post by Arkanosis »

steveklabnik wrote: post #96
slavik81 wrote: post #89

Earlier quoted context omitted.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference: Rust: fn main() { let a: f32 = 1e7 + 0.5 + 0.5; let b: f32 = 1e7f32 + 0.5f32 + 0.5f32; println!("{}", a==c); // true } C: #include int main() { float a = 1e7 + 0.5 + 0.5; float b = 1e7f + 0.5f + 0.5f; printf("%s\n", a==b ? "true" : "false"); // false } That's awesome. I'm tot…

You often don't need it at all; fn foo(x: f32) { println!("{}", x); } fn main() { let x = 5.0; foo(x); } It will look at the signature for foo, and infer that x must be f32.

Whoa!

Isn't this kind of inference dangerous? It seems that whichever call comes first is used to infer the type, so a single added line of code can change the type of a variable…

  fn foo32(x: f32) { println!("{}", x); }
  fn foo64(x: f64) { println!("{}", x); }

  fn bar64() {
      let x = 5.0; // f64
      foo64(x);
      foo32(x);
  }

  fn bar32() {
      let x = 5.0; // f32, not f64
      foo32(x);
      foo64(x);
  }

Re: Announcing Rust 1.20

#150

Post by Manishearth »

oscargrouch wrote: post #138
steveklabnik wrote: post #130

Earlier quoted context omitted.

Rust doesn't have any more runtime than C, and also doesn't have a GC. Servo has bindings into SpiderMonkey's GC so that the JavaScript stuff works properly, but that's only that part. That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. (I don't work on Firefox though so I could be wrong about some details.)

> That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. So it means the compiled binary ends up in a simple compatible C ABI? thats pretty nice, if thats the case. But giving the project is using LLVM, even C++ ABI would be achievable without too much effort (i guess).

bindgen actually has the option to generate wrappers for C++ methods and other stuff for Rust to call. We don't use this, but we do use its ability to generate templates and stuff.

The other way around -- getting Rust to use the C++ abi -- needs compiler changes and also has questionable benefits.

Post reply on HN