Thanks Patrick for the great explanation. Where can I find the typical usage examples of the select operation in the pipes module?
I guess what remains is the inference for dynamic calls on polymorphic data structures. How would you implement a binary search tree cleanly, with types for empty, leaf, parent nodes? What is your team's approach to corner cases? Generic syntax must cater for corner cases? Or corner cases should have special syntax? Do more most of the time, or do more sometimes? Heri On 2013/04/08, at 13:25, Patrick Walton <[email protected]> wrote: Apologies for the scattered responses; I'm on my phone. * I suppose we could implement automatic dereferencing in pattern matches, since we do require that types be fully resolved in match contexts, but it seems somewhat strange to me. Does any other language do automatic dereferencing in match or switch statements? There is precedent from D for automatic dereference for the '.' operator, but not switch. I suspect there might be nasty corner cases like: match @Some(3) { x @ Some(_) => { // is type of x @Option or // Option? } ... } I.e. where does the dereference happen? It's observable, as above. * Go requires you to use & and * to pass arguments by reference, just as Rust does. The difference is that Go's compiler chooses whether to allocate on the heap or the stack based on unspecified heuristics. This is a fine choice for Go, but it's contrary to the design goals of Rust. Rust programmers should be able to specify with precision whether data is allocated on the stack or the heap. * We tried to pass parameters by reference automatically based on heuristics in earlier versions of the language. These were called "modes". They made it hard to understand what data was being shared (when mutability is involved, this is not transparent!) and, moreover, interacted very badly with generics. Lesson learned: it's not worth it in a language with explicit memory management. * There is a select operation in the pipes module. * Making errors into a trait would require heap allocation for error types for no reason. The Result type is much more flexible, in any case, since it can store anything, not just a string. * I have a pull request to remove the necessity of "as @Trait". I would expect it to be removed in 0.7. You're right about it being too verbose. * You can use &Trait to avoid heap allocation. Patrick Heri Sim <[email protected]> wrote: > > Hi guys, I am new here. Just found out about this project today, and > read up a lot on its history and purpose. > > > There are 3 gripes I have about Rust, after comparing some good stuff > in Go-lang. http://tour.golang.org > > > 1st, dereferencing should be automatic everywhere. > Running a pattern match on borrowed boxes should NOT require an asterisk (*). > Passing in a stack-local variable to a function or closure (that > requires arguments to be passed by reference), should not require the > ampersand (&) in the caller. Why can't the compiler figure this out? > > In go-lang, all these things are just more invisible, which makes the > learning curve so much easier. I understand people coming from C would > prefer these memory-management signets explicit, but really they have > l > ittle > need to be so verbose in many cases, and should be optional or > by-default instead, so that things just-work. (Just-like how custom > borrow lifetimes are optional, and defaults well in most cases.) > > > 2nd, there is a need for the concurrency mechanism similar to the > concurrent "select" in go-lang. This is used to implement multiple > patterns such as timeouts, and non-blocking channel receive, and many > others. Errors in tasks would also be better handled/supervised this > way. By the way, should rust errors be a trait like in go-lang? > > > 3rd, while generics are great, there is a need for trait types or > dynamic objects to be simpler to use in rust. Dynamic calls through > interfaces in go-lang are simpler, while trading off performance. In > rust, implementing draw_all on a vector of Drawable elements also have > similar performance hit, but with a much uglier implementation > requiring both @ and ~ signets a > nd "as" > syntax, which is confusing and > too verbose. Also there seem to be a requirement for managed boxes in > the shared heap for dynamic calls, which Erlang does not require. As > such, recursion for some problem sets (like polymorphic binary trees) > is not as clean in rust, compared to other languages. How can we > improve this? > > > Otherwise, Rust lang is really awesome. > The documentation and syntax is easy to follow for the basics, but > begin to feel "complex-for-complexity sake" in the advanced/modern > language features. As such, the documentation feels schizophrenic as > the language constructs begin to lose its delightful lean-opinionated > design towards the end. > > Really beginning to like Rust a lot. > > Heri > ------------------------------ > > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
