> Traits are interfaces So why not use "interface" keyword?
It sits between interface and implementation. They're... more an `intermediate`.
Abstraction without overhead: traits in Rust
41–50 of 150 posts
Re: Abstraction without overhead: traits in Rust
#42Earlier quoted context omitted.
This is also how interfaces are implemented in Go.
And typeclasses in Haskell as well.
I don't think that's true. Dictionary-passing (or something equivalent) attaches the table of methods to the functions which take typeclass instances as arguments (with extra, hidden arguments), while Rust's Box attaches the table of methods to the object pointer itself. So you can have a list of Box in Rust, but you can't have a list of Show in Haskell. You have to set up the extra indirection yourself using something like this: https://wiki.haskell.org/Existential_type#Dynamic_dispatch_m....
I'm not an expert in Rust or Haskell, though, so I welcome corrections.
Re: Abstraction without overhead: traits in Rust
#43Earlier quoted context omitted.
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…
I guess we'll have to agree to disagree here. I think what you consider 'pretentious jargon' really depends on what kinds of languages you've used and the way you think about them. I think calling enums unions would have been a very big mistake, as they would mislead C programmers. Even you say that they're 'quite close', but they're not the same thing.
I, uh, don't really follow that logic. A Rust enum isn't even "quite close" to a C enum, yet you used a colliding term. Surely a C programmer who would have been mislead about the fact that a union type is runtime-tagged and checked is going to be very misled that an "enum" has no numeric value and can contain variable state at runtime.
Re: Abstraction without overhead: traits in Rust
#44Earlier 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…
I don't really want to argue about enum vs. union, because as far as I'm concerned they're pretty much equally accurate or inaccurate. Enums in C carry tags, but no data. Unions in C carry data, but no tags. Rust ADTs carry both (or one, or neither). So "enum" or "union" are pretty much equally good/bad names as far as I'm concerned. Consensus was in favor of "enum", so we went with it. Swift did too, so the small amount of emerging consensus as to what to call ADTs in C-like languages is nice.
> Likewise being deliberately difficult with "trait" vs. "interface" (picking Self's jargon instead of the term that literally everyone already knows from decades of OOP) didn't serve you well.
But "trait" is the right term. I would agree with you if Rust traits couldn't have implementations via default methods, but they do, and interfaces usually can't (except in Java 8). Interfaces strongly suggest, well, interface, as opposed to implementation; however, traits mix and match both. You can perfectly well have traits that exist only to provide "mixin"-style implementations.
In earlier versions of Rust, traits were called interfaces (and there were separate constructs to provide implementations of interfaces), but one of the design simplifications was to unify all those concepts into one: the trait.
> Finally, regarding "box" vs. "block". Other languages (C# is the only one that comes to mind off-hand) have used the idea of "boxing" to imply the allocation of space for and copying of pass-by-reference data. That's sort of a different notion than simple heap allocation, so it sort of gets its own jargon I guess. I didn't complain anyway. But with Rust, a "box" really is used to refer to a dynamic heap block in any context.
Sorry, I just have to disagree here. I don't think anything would be simpler if the keyword were "block":
let x: Block = block 3.0;
Re: Abstraction without overhead: traits in Rust
#45Earlier 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.
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 easily.
Re: Abstraction without overhead: traits in Rust
#46Earlier quoted context omitted.
> So why not use "interface" keyword? They aren't really interfaces. They can be like interfaces (just method signatures) or like classes without data (including definitions for some or all methods). Using a name distinct from either "class" or "interface" limits the degree to which incorrect expectations from similar-but-critically-different constructs in other language interfere with understanding of the Rust const…
Traits as defined in scala can actually have state and data.
Do Scala's traits change behavior depending on order of definition?
That scares me tbh.
Re: Abstraction without overhead: traits in Rust
#47Great article. The main bit of new information for me was that while Rust supports dynamic dispatch, its implementation has a noticeable difference from C++. In C++, the vtable pointer is in the object itself. In Rust, it's stored inside what is essentially a "fat pointer." Pointers to traits ("trait objects") are actually two pointers: the pointer to the vtable and the pointer to the actual object. This seems to hav…
It also makes multiple inheritance (which Rust has, through Java-like interfaces) easy to implement, and fast at runtime. The virtual inheritance of C++ is a real mess, by contrast [1]. [1]: http://www.phpcompiler.org/articles/virtualinheritance.html Edit: I don't mean to bash C++ here, BTW; the skinny-pointer approach has a lot of benefits when all you need is single inheritance (and there are early-stage proposals…
I apologise in advance that this may not be most appropriate place to ask this question.
I am looking for a Rust tutorial. It looks like there was one, but it was deprecated in favour of 'the book'. But 'the book' doesn't seem to have a tutorial yet.
Are there any tutorial's running through how to build some small piece of working software.
I found the Golang tutorial, where you build a very basic blog extremely enjoyable. Does Rust have anything similar?
https://golang.org/doc/articles/wiki/
Thanks
Re: Abstraction without overhead: traits in Rust
#48Earlier quoted context omitted.
It also makes multiple inheritance (which Rust has, through Java-like interfaces) easy to implement, and fast at runtime. The virtual inheritance of C++ is a real mess, by contrast [1]. [1]: http://www.phpcompiler.org/articles/virtualinheritance.html Edit: I don't mean to bash C++ here, BTW; the skinny-pointer approach has a lot of benefits when all you need is single inheritance (and there are early-stage proposals…
I apologise in advance that this may not be most appropriate place to ask this question. I am looking for a Rust tutorial. It looks like there was one, but it was deprecated in favour of 'the book'. But 'the book' doesn't seem to have a tutorial yet. Are there any tutorial's running through how to build some small piece of working software. I found the Golang tutorial, where you build a very basic blog extremely enjo…
The book basically has two sets of tutorials: the "Syntax and Semantics" section is a bottom-up tutorial, and the "Learn Rust" section is a project-based, more top-down one. It's true that only one chapter of Learn Rust has landed at the moment. It's basically what I'm doing right now. Should have two or three more chapters over the next few days.
Re: Abstraction without overhead: traits in Rust
#49Earlier quoted context omitted.
The turing-complete argument makes no sense here.
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…
That has nothing to do with Turing-completeness. There are Turing-complete languages which don't even have pointers.
Re: Abstraction without overhead: traits in Rust
#50Earlier quoted context omitted.
It also makes multiple inheritance (which Rust has, through Java-like interfaces) easy to implement, and fast at runtime. The virtual inheritance of C++ is a real mess, by contrast [1]. [1]: http://www.phpcompiler.org/articles/virtualinheritance.html Edit: I don't mean to bash C++ here, BTW; the skinny-pointer approach has a lot of benefits when all you need is single inheritance (and there are early-stage proposals…
I apologise in advance that this may not be most appropriate place to ask this question. I am looking for a Rust tutorial. It looks like there was one, but it was deprecated in favour of 'the book'. But 'the book' doesn't seem to have a tutorial yet. Are there any tutorial's running through how to build some small piece of working software. I found the Golang tutorial, where you build a very basic blog extremely enjo…
[deleted]