111–120 of 186 posts
Can someone please write a Clojury lisp that compiles to Rust without immutability (by default) and concurrency primitives, since thread safety is guaranteed by the rust compiler? I love Clojure, but this would be a completely different beast, a crazed DRAGON probably. PS: I want a Dragon
Earlier quoted context omitted.
The key is that the MutexGuard is responsible for unlocking (and it does so automatically on destruction). That way, you're tying the scope for the &mut reference to the scope in which the lock is actually held.
Similarly, I quite don't understand what in the type signatures precisely tie MutexGuard to the result of access. Like, in the "Disaster averted" example the mutex section, how is it detecting that "error: `guard` does not live long enough"? I see that access returns a borrowed mutable T. But, how does the compiler know that that's borrowed from guard instead of a hypothetical second or third parameter or from some o…
fn access(guard: &'a mut MutexGuard) -> &'a mut T;
EDIT FOR CLARITY: in particular, you're saying that if you take a "sublease" from something you've already borrowed, that sublease is valid for no longer than the original lease. So for example if you borrow a field out of a borrowed structure, the access to the field can last no longer than you had access to the original structure. In this case, we're saying that access to the data lasts no longer than the lock is held.
I'd recommend http://blog.skylight.io/rust-means-never-having-to-close-a-s... if you want to get a bit more of a feel for how this works.
The details about the shorthand are here: https://github.com/rust-lang/rfcs/pull/141
Earlier quoted context omitted.
>I think generics are poorly understood in general Perhaps by programmers (and the designers/maintainers of certain mainstream languages...), but there are some very strong models out there; we've had well-behaved parametric polymorphism à la Hindley-Milner for decades and Haskell's typeclasses are in my opinion a very well-thought-out approach to ad-hoc polymorphism (and which the more ambitious C++0x version of Con…
Concerning std::allocator_traits, it reflects a deeper limitation of the language rather than just a library design flaw. If you had HKT, you could pass std::allocator to a template. You can't do that, you can only pass std::allocator for some concrete T. Equivalently, in Haskell, you can pass IO as a type parameter, so you don't see the same kludges. I definitely agree with the sentiment about subtype polymorphism.
template foo {};
template class F> struct bar { F f; };
bar b;
I haven't investigated it but variadic template template arguments might help there, though.
Earlier quoted context omitted.
"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.
> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Many of the ideas in go were not well understood and had only been demonstrated in research languages prior to go. Its concurrency model and associated primitives, and the automatic interface system were in roughly the same state then as Rust's new ideas are now. That said the ideas in Rust were not as well und…
Earlier quoted context omitted.
> The fact is, these "idioms and best practices" will not be followed perfectly on projects of any reasonable size if they are not enforced by code. Why would you not enforce them with code? Compiler shall not be an obstacle to a man. We tried enforcing things before, many times. Things got abandoned.
Sigh. We build machines to automate the repetitive, to eliminate the daily drudgery and to repeat steps with perfection (that we would repeat with perfection ourselves if only we were as focused as a machone). So why do we keep finding ourselves arguing that a lazy compiler, which offloads the work of a machine on to a dev team, is an acceptable compromise?
For the former group, error checking just gets in their way. Their job is not to make the software perfect, it's only to make it satisfy one person's need, to replace something that previously wasn't computerized with something that was. Oftentimes, it's not even clear what that "something" is - it's pointless to write something that perfectly conforms to the spec if the spec is wrong. So they like languages like Python, Lisp, Ruby, Smalltalk, things that are highly dynamic and let you explore a design space quickly without getting in your way. These languages give you tools to do things; they don't give you tools to prevent you from doing things.
The second group works in larger teams, with larger requirements and greater complexity, and a significant part of their job description is dealing with bugs. If a significant part of the job description is dealing with bugs, it makes sense to use machines to automate checking for them. And so they like languages like Rust, C++, Haskell, Ocaml, occasionally Go or Java.
The two groups do very little work in common (indeed, most of the time they can't stand to work in the opposing culture), but they come together on programming message boards, which don't distinguish between the two roles, and hence we get endless debates.
everything mentioned can be done in C++11 and lthread_cpp http://lthread-cpp.readthedocs.org
Earlier quoted context omitted.
"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.
> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Many of the ideas in go were not well understood and had only been demonstrated in research languages prior to go. Its concurrency model and associated primitives, and the automatic interface system were in roughly the same state then as Rust's new ideas are now. That said the ideas in Rust were not as well und…
Its interface system is an implementation of structural typing, which may be even older.
You could maybe argue that neither had "industrial-strength" implementations, but that seems like a stretch.
Earlier quoted context omitted.
> > (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). > Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. As I said right at the beginning of my post, I'm not trying to compare Rust and Go directly, because I don't think that's meaningful. I'm explaining why these particular features would b…
> I would otherwise be interested in having a discussion about static analysis and hearing why you think it would not solve the problem Stack allocation isn't in the semantics of Go, so that's a pretty weird thing to use a basis of a static analysis. It's also not sound because of interfaces or closures. You would want something more like "fully by-value data with no pointers in it, no interfaces, no closures".
Earlier quoted context omitted.
I'm pretty sure Cyclone used both regions and borrowing in ~2005. But it was a research project and not meant for wide use.
I thought Cyclone only used regions, but I haven't read the paper in a while. (and dates from 2002 IIRC) It certainly had a big influence on Rust, we're fans of the work.