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

Abstraction without overhead: traits in Rust

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 150 posts

Re: Abstraction without overhead: traits in Rust

#81

Post by humanrebar »

geofft wrote: post #73
humanrebar wrote: post #45

Earlier quoted context omitted.

Sure it does. I can pass around a struct containing any bytes I want and do anything I want with it. If I want to define FatPointer that contains an opaque pointer (or some equivalent union) and a polymorphic Strategy object of some sort, I can. You can do the same in C, for that matter. Or in assembly. The reason we still come up with new languages is so that you can write code that conforms to certain patterns easi…

No, Turing-completeness does not mean you can "do whatever you want". It means you can compute whatever you want that is computable. If the way you want to compute things is to embed a Rust compiler, yes you can do that, but there are many things that we'd colloquially refer to as "do whatever you want" that apply to the semantics of C++ itself. You cannot, for instance, create a new abstract base class and have a pr…

> You cannot, for instance, create a new abstract base class and have a pre-existing class in someone else's header implement your abstract base class, such that a pointer to that pre-existing class can be dynamic_cast to your class.

Sure you can, for some value of base class and cast. You might not be able to use particular keywords, but data is data and math is math. You might not be able to use the built-in type system to do it.

C and javascript programmers write their own inheritance-based type systems all the time. And anything you can do in C, you can do in C++ if you really want to.

Re: Abstraction without overhead: traits in Rust

#82

Post by geofft »

steveklabnik wrote: post #77
geofft wrote: post #75

Earlier quoted context omitted.

> Just go back to that tutorial with your C hat on and substitute the word "union" for "enum" and I promise it will all make sense. All your intuition about C unions will cross over just fine, and the new Rust rules (they're tagged at runtime and the compiler enforces that you can only ever use fields of a runtype-checked subtype) are straightforward extensions. This is not true. Rust enums allow you to match on whic…

> (That said, if your real complaint is that the official docs on enums are confusing, I'd certainly agree with that.) I'd love more specifics about which docs, if you have some time.

trpl/enums.md is super weird, and also in the wrong order (the book documents enums before structs, and way before tuple structs, whereas enums are IMO easiest explained once you've already explained structs). I was going to send you a PR tomorrow or so. :)

Re: Abstraction without overhead: traits in Rust

#83

Post by brohee »

ajross wrote: post #66
kibwen wrote: post #62

Earlier quoted context omitted.

> it seems like Rust has caught itself up in an internal > rush (among its rock-star language nerd designers) for > Masterpiece Status and sort of forgotten the goal of > creating a practical tool for working programmers This is complete hogwash. Just because you disagree with the chosen terminology doesn't justify attacks on the character of the Rust developers.

Sigh... it's an opinion. I even used "seems". I was around when we all watched C++ go from "exciting new tool we should all use" to "wait, does anyone else understand that new stuff because I don't anymore". This feels exactly the same. I'm no dummy, yet Rust is just confusing as hell sometimes. And you guys frankly don't seem to care (again: note marker "seems" to indicate a personal opinion and not a "character att…

I'm updating one year old Rust code currently, it's pretty obvious a tremendous amount of work has gone toward making it a more usable language. Yet it is not a small one, so some effort to master it is to be expected...

Re: Abstraction without overhead: traits in Rust

#84

Post by samth »

coolsunglasses wrote: post #80
samth wrote: post #79

Earlier quoted context omitted.

Actually, lifetimes are basically the same as regions, going back to FX87. Lifetimes in Rust are more like regions in Tofte & Talpin 94 than those in FX87, but where inter-region pointers are constrained by the lifetime of regions rather than changing the lifetimes of the regions (as required by Rust's goals for regions).

Rust's goals for linear typing and regions changed. Ownership types didn't happen until typestate was abandoned. The current design is quite different from what was being explored before. If they're happy with what they've got, more power to them, but the project's priorities have changed dramatically in the last 2 years. I think it's worth asking why something that started seemingly as a research language backed off…

I didn't claim (and neither did kibwen, who unlike me is a major Rust contributor) that Rust's approaches around memory management didn't change. But your claim that "Lifetimes aren't regions" is false -- lifetimes are squarely in the 30-year research history of region systems.

Re: Abstraction without overhead: traits in Rust

#85

Post by eli_gottlieb »

detrino wrote: post #29
humanrebar wrote: post #27

Earlier quoted context omitted.

C++ is Turing-complete, so you can do whatever you want. What Rust offers is an hierarchy free (i.e., no inheritance) polymorphism mechanism as a core part of the language.

The turing-complete argument makes no sense here.

I think he means that, through templates, the C++ type system is Turing-complete.

Re: Abstraction without overhead: traits in Rust

#86

Post by sixbrx »

ajross wrote: post #35
steveklabnik wrote: post #33

Earlier quoted context omitted.

Well, enums aren't unions, they're tagged unions. And other languages call boxed values by that name too.

Stop it, they're unions. :) Among the target market, people are going to intimately familiar with the use of "enum" and "union" from the C language. Rust's concept of a single object that can store exactly one of several types of sub-objects matches one quite closely, and not the other. Having a runtime tag and affirmative checking doesn't change the nature of the thing. We don't call "cars" something different when…

> regarding "box" vs. "block". Other languages > (C# is the only one that comes to mind off-hand)

F# actually uses box much like Rust does:

    // box an int
    let o = box 1
Examples: http://fsharpforfunandprofit.com/posts/cli-types/

MSDN: https://msdn.microsoft.com/en-us/library/ee340516.aspx

Re: Abstraction without overhead: traits in Rust

#87

Post by steveklabnik »

geofft wrote: post #82
steveklabnik wrote: post #77

Earlier quoted context omitted.

> (That said, if your real complaint is that the official docs on enums are confusing, I'd certainly agree with that.) I'd love more specifics about which docs, if you have some time.

trpl/enums.md is super weird, and also in the wrong order (the book documents enums before structs, and way before tuple structs, whereas enums are IMO easiest explained once you've already explained structs). I was going to send you a PR tomorrow or so. :)

Fair enough. Tomorrow is basically the deadline before 1.0 though, so send it early :)

Re: Abstraction without overhead: traits in Rust

#89

Post by coolsunglasses »

samth wrote: post #84
coolsunglasses wrote: post #80

Earlier quoted context omitted.

Rust's goals for linear typing and regions changed. Ownership types didn't happen until typestate was abandoned. The current design is quite different from what was being explored before. If they're happy with what they've got, more power to them, but the project's priorities have changed dramatically in the last 2 years. I think it's worth asking why something that started seemingly as a research language backed off…

I didn't claim (and neither did kibwen, who unlike me is a major Rust contributor) that Rust's approaches around memory management didn't change. But your claim that "Lifetimes aren't regions" is false -- lifetimes are squarely in the 30-year research history of region systems.

A region calculus[1], such as Tofte described, is not what I see in Rust as it exists today. It could've been so with typestate, if I understood the intent behind typestate correctly.

If what Rust has is understood to be regions, then I need a couple of words for distinguishing the two. Ordinarily, I refer to what Rust/C++ have as "ownership types" and what exists in research as regions/RBMM/RC.

[1]: http://www.researchgate.net/profile/Simon_Helsen/publication... (the defintion provided here is what I understand "regions" to mean, as contrasted with what exists in C++ and Rust)

Re: Abstraction without overhead: traits in Rust

#90

Post by sixbrx »

coolsunglasses wrote: post #68
kibwen wrote: post #63

Earlier quoted context omitted.

> Wish regions hadn't been abandoned, but it seems like > somebody wanted Rust pushed into becoming a product quickly. No idea what you're referring to here. Lifetimes are entirely based on the regions literature, and four frigging years of design iteration is hardly "pushed into becoming a product quickly". :P

Lifetimes aren't regions. 4 years when it is a recapitulation of existing technology and hasn't had time to push anything forward and we already have PLs with similar facilities? That's a product-oriented rather than research-oriented direction whether you think it's too fast or not. For comparison, Haskell dates to the early 90s, based on non-strict FP languages from the 80s. ML itself started in the 70s. Much of wh…

I don't think Rust was ever intended to be primarily a research language. From what I gathered even from early docs (in Graydon's reign), it was intended to implement ideas previously introduced in research languages in a practical systems language. They even made mention of adopting only safe ideas* (and I'm too lazy to look for those quotes). I think they've had to innovate some but that wasn't the primary intent.
Post reply on HN