Because they are traits [1], not interfaces, and they also have some features from type classes [2]. When you create a class in an OOP language, you have do declare all interfaces it supports, and provide implementations for them (or mark the class as abstract). In Rust's case, you declare the data separately as a struct declaration, and then implement the traits you want in impl declarations. You can also implement…
Ah, I read the Wiki article and my impression of traits was "interfaces with implementation" and as far as I could tell, Rust traits have no implementation, they 'need' impl(emendations) so they seemed more like interferences to me :)
> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I'd add: Do you want to focus on new or experienced users? For example, when implementing systems that will be used 8 hrs/day by its users, we look only at efficiency for experienced users (unless the political situation requires placating the noobs). They will be noobs for a day or maybe a c…
This is the reasoning that is used for Clojure - "Clojure is for experts". It's used to rationalise all sorts of design choices that make the language much harder to get started with than (IMO of course) it should be. If you're implementing a system that users have to use for their job, they'll put up with whatever they have to while they're learning it. If you're implementing a programming language and you want to i…
Agreed. All of those were easier to deal with than Clojure, but that could just be because it is a pain to do anything with the JVM and emacs isn't easy either.
> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I'd add: Do you want to focus on new or experienced users? For example, when implementing systems that will be used 8 hrs/day by its users, we look only at efficiency for experienced users (unless the political situation requires placating the noobs). They will be noobs for a day or maybe a c…
What's the language that takes that to the extreme? I remember it being used for fintech(?) or spreadsheets and I remember seeing one-liners that look like someone just mashed the keyboard. Apparently incredibly efficient once you are an expert in the language.
The APL family of languages that currently have commercial implementations like Dyalog and Q w/ kdb+ database. J and GNU APL are both free & open source. Dyalog is nice though even though a commercial license sets you back a grand per year (basically what most C# users pay for VS). You get a nice interpreter, support, built-in graphics, full .NET interop, full R interop, heck even DDE which is still useful in finance and my own industry. They seem to take documentation really seriously and have pretty interesting conferences. I don't code in APL, but am considering it as their product just seems pretty agile for my needs (personal user productivity). Q is extremely expensive and is the APL derived language that accompanies the kdb+ database used for time-series analysis on stock quotes...etc. It was built by Arthur Whitney and legend has it the entire source code is 5 pages of C (being an APL guy he has it all scrunched up though...doesn't like to scroll). People seem to like it and be willing to pay a fortune.
Ah, maybe it's when they're alias types that that wouldn't work?
Actually I just tried that and it worked also. But I think you're right that this hasn't always been the case because I remember being annoyed about it. Or maybe we're both crazy. You definitely need to specify the type for an interface, but that makes sense.
You're not crazy. I also have vague memories of maps being more obnoxious in Go. :)
The facts are that map literals did change a bit in Go 1.5 (i.e. fairly recently), full literal specification for values could already be elided back then - it was KEYS that required full specification:
https://golang.org/doc/go1.5#map_literals
Curious, is it harder for c++ programmers to learn Rust than dev from higher level devs? Because ive seen Rust has a lot more success recruiting devs from python, js, even php.
Not really, it is mostly a culture thing. There are two main communities in C++, those that embrace safety and take advantage of the language features to improve their productivity, while going down to lower level constructs if performance needs an extra push. Then there are those that are kind of exiled C developers using a C++ compiler, forced to migrate to C++ on their work, trying to use it as C with C++ compiler…
As I've said/posted this elsewhere, the Rust macro package is close to unusable. It makes easy stuff difficult and it doesn't exactly help with difficult stuff. It would be interesting to compare the number of macros defined in the crates corpus divided by total line count and compare that with other languages. I do not think that I am alone in not using it. Yes, I use macros; I just don't program macros. Obviously,…
Macros are being largely re-done, see http://words.steveklabnik.com/an-overview-of-macros-in-rust for an overview. Honestly, I very rarely use macros and have written two in my years of Rust. You almost never need them, or at least, that's my experience.
And even in Clojure, where macros are very easy to use -- I write them very infrequently. They're seductive, but usually a bad idea.
I'm an ergonomics nut and I've been looking to learn Rust. Any chance they're looking for a set of guinea pigs to report their experiences as new users, or are they mostly working on already-known issues?
We are always looking for experience reports. Making a post on internals.rust-lang.org would be great!
Macros are being largely re-done, see http://words.steveklabnik.com/an-overview-of-macros-in-rust for an overview. Honestly, I very rarely use macros and have written two in my years of Rust. You almost never need them, or at least, that's my experience.
I guess it depends on what you work on. Both of my primary Rust projects (a .NET metadata parser & a Game Boy emulator) are heavily dependent on macro usage, and they implement multiple new macros. Both do lots of binary parsing, so I use bitflags, enum_primitive and bitfield all the time. For instance, I use this [1] two-macro monstrosity to parse tagged unions from the CLR metadata. [1] https://github.com/paavohuht…
Because they are traits [1], not interfaces, and they also have some features from type classes [2]. When you create a class in an OOP language, you have do declare all interfaces it supports, and provide implementations for them (or mark the class as abstract). In Rust's case, you declare the data separately as a struct declaration, and then implement the traits you want in impl declarations. You can also implement…
Ah, I read the Wiki article and my impression of traits was "interfaces with implementation" and as far as I could tell, Rust traits have no implementation, they 'need' impl(emendations) so they seemed more like interferences to me :)
You can have default implementations for methods if you'd like.
We are always constantly trying to listen to people and get feedback; for example, it's one of the reasons I pay such close attention to these threads! There's always room for improvement, but iterating in this way is defintely a core value.
Depending on what group you're trying to attract or improve the experience with, you could potentially setup contracts with the level of person you would like to deal with and pay them to implement something in rust while you monitor their progress & with full access to their work and what they're doing.
The issue is, of course, that the more you focus on specific tasks the more your language becomes "designed for" those tasks, and the language becomes less general. The language already went through some of this with Servo - the DOM would be much easier to implement with an object-oriented language, but that wouldn't fit in well with the rest of Rust and would significantly raise complexity.