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

131–140 of 277 posts

Re: Announcing Rust 1.20

#131

Post by steveklabnik »

jeffdavis wrote: post #122
steveklabnik wrote: post #106

Earlier quoted context omitted.

> 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.

Interesting. Then rust should not care about the destruction order, right?

For this purpose, no, I don't think. That said I might be missing something and maybe th compiler doesn't understand this, so I'm not saying it's a panacea in your case, just might be worth looking at.

Re: Announcing Rust 1.20

#132

Post by staticassertion »

whyever wrote: post #126
msbarnett wrote: post #119

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. It's still "hard to get right" in that at any time nothing is stopping you from violating any of the assumptions that make this "easy". It's never easy to write a solution that's "guaranteed to be safe" in C, but that's what you're trying to d…

Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.

And integer out of bounds, and (most) segfaults, and data races, etc

Re: Announcing Rust 1.20

#133

Post by Animats »

hashmal wrote: post #118
kannanvijayan wrote: post #108

Earlier quoted context omitted.

Frankly, I'd just use unsafe pointers for the backrefs, and wrap the tree API up in a typesafe layer, and build on top of that. RefCells seem to add unnecessary redundancy here. You'll take a hit for runtime borrow for every pointer chase up the tree. If walking from a leaf to the root is important, you don't want to add an extra compare/branch/set to every pointer chase. Turns a single memory read into a branch, a w…

I'd take a similar approach. After all `unsafe` use cases include the implementation of data structures.

I've argued this issue before.

The answer isn't generics, Coq, or some fancy type system nobody will understand or use properly. There are only a few inherent trouble spots in pure Rust code safety. The big two are:

- Partially initialized arrays. "Vec" has to be unsafe because growing an array involves uninitialized slots. You just need a way to say "this array is initialized from 0..N only", where N is in a data structure associated with the array. Then you need an operation that says "initialize entry N+1 and update the count". That's all it takes.

"Map" could be implemented on top of "Vec", instead of using unsafe code. It would be worth trying this and seeing what the performance penalty is. That may be a premature optimization.

- Backpointers. Backpointers have an easily checked invariant relationship with the forward pointer that owns their containing object, but there's no way to tell the language that something is a backpointer.

Re: Announcing Rust 1.20

#134

Post by smegel »

steveklabnik wrote: post #130
smegel wrote: post #129

Earlier quoted context omitted.

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

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.

Re: Announcing Rust 1.20

#135

Post by steveklabnik »

staticassertion wrote: post #132
whyever wrote: post #126

Earlier quoted context omitted.

Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.

And integer out of bounds, and (most) segfaults, and data races, etc

Notably integer overflow is NOT UB and is checked in debug builds.

Re: Announcing Rust 1.20

#136

Post by Animats »

msbarnett wrote: post #74
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

> I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once. The simple way to do that would be to allocate an array, and use indices into the array rather than pointers/references. Doing it with pointers isn't so much harder in Rust than C as it is that Rust is making you deal with how hard it is to get this right , whereas in C the c…

The simple way to do that would be to allocate an array, and use indices into the array rather than pointers/references.

I've done that in code for a collision detection engine. The object descriptions for convex polyhedra have lists of faces, lists of edges, and lists of vertices, all referencing each other. The original implementation (I-Collide) actually used lists for them. When I re-implemented that in C++, I used arrays with indices for each of those. When you're done with a polyhedron, all those structures, which are owned by the Polyhedron object, go away more or less simultaneously.

Re: Announcing Rust 1.20

#137

Post by burntsushi »

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.

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 optional GC to Rust proper, although many folks have worked/written about writing their own.

Re: Announcing Rust 1.20

#138

Post by oscargrouch »

steveklabnik wrote: post #130
smegel wrote: post #129

Earlier quoted context omitted.

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

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).

Re: Announcing Rust 1.20

#139

Post by evincarofautumn »

JoshTriplett wrote: post #80
evincarofautumn wrote: post #77

Earlier quoted context omitted.

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past. So that[2] sounds wrong: This[3] probably screwed you up. The somewhat confusing thing is that “this” is also used fo…

> English is unusual in that it generally uses “this” for the future and “that” for the past. I don't know that I'd describe it as "future" and "past"; it's more that English uses "this" for "current" and "that" for "other", whether past or future. For instance, "this situation is broken, that solution looks promising" uses "this" to refer to the present and "that" for the future.

I was referring to past/future in the text. Deixis is about how words and phrases like “this”, “that”, “here”, &c. are contextualised. Your example is unrelated to discourse deixis because it’s not referring to a piece of the surrounding discourse. We use different forms of deixis and spatial metaphors for time, like “the end is near” or “the past is behind us”—in some languages, the past is in front of you (mnemonic: you can see it) while the future is behind (you can’t).

Re: Announcing Rust 1.20

#140

Post by burntsushi »

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).

To clarify, Rust has its own ABI, just like C++ has its own ABI. And just like C++, you can expose a C ABI if you want by defining special functions. In C++, it's an `extern "C" { ... }` block, and in Rust, it's a `extern "C" fn foo() ...` function declaration. You can see an example here: https://github.com/rust-lang/regex/tree/master/regex-capi

Adding C++ ABI support is a significant effort.

Post reply on HN