Le 26/04/2013 23:23, Brian Anderson a écrit :
On 04/25/2013 10:42 PM, james wrote:
On 24/04/2013 23:38, Brian Anderson wrote:
What I am focused on now is the design of a synchronous API for
sending and receiving streams of bytes, along with an implementation
built on an internal
Le 27/04/2013 19:30, Patrick Walton a écrit :
On 4/27/13 4:06 AM, David Bruant wrote:
I believe too this is doomed to happen. Firefox is under a huge struggle
to remove as much as sync IO code as possible as part of the Snappy
effort [1].
This is a completely misleading comparison. Firefox's
Le 22/01/2013 15:55, Dean Thompson a écrit :
(...)
Who is our target audience for Rust? Graydon has said it is
frustrated C++ developers, but how sophisticated and how brave
are we thinking they will be?
Je pense que c'est une question de coût/bénéfice. Compte-tenu du coût
d'apprentissage d'un
Le 22/01/2013 17:16, David Bruant a écrit :
Le 22/01/2013 15:55, Dean Thompson a écrit :
(...)
Who is our target audience for Rust? Graydon has said it is
frustrated C++ developers, but how sophisticated and how brave
are we thinking they will be?
Je pense que c'est une question de coût
Hi,
I'd like to bring a bit more of feedback. I've read Stateful Traits [1]
and I was wondering how Rust intended to solve the issue mentionned in
the paper related to statelessness:
However this simple model suffers from several limitations, in particular
(i) trait reusability is impacted
Le 11/07/2012 03:05, Brian Anderson a écrit :
On 07/10/2012 12:13 PM, David Bruant wrote:
(...)
Tasks do have a memory cost, but it is theoretically quite low. Rust
tasks on linux currently have somewhere around 4K of overhead, and
that's around 3K more than we would like and think
Hi,
Looking at the Rust documentation, I read:
Named functions, like those we've seen so far, may not refer to local
variables decalared outside the function - they do not close over their
environment. For example you couldn't write the following:
let foo = 10;
fn bar() - int {
ret foo;
Le 13/07/2012 21:42, Patrick Walton a écrit :
On 7/13/12 12:38 PM, David Bruant wrote:
I can't help but asking why can't named function close over their
environment?
In the case above, I see no harm in allowing the 'bar' function to
access 'foo'.
Because named functions are always in scope
Le 12/07/2012 01:40, Mic a écrit :
Hello,
Any plans to allow rust to compile to JavaScript like dart
http://www.youtube.com/watch?v=YxogQGnMA9Y .
To the best of my knowledge, Rust compiles down to LLVM and Emscripten
compiles from LLVM to JS, so it seems like the hardest part of the job
is
Le 10/07/2012 01:33, Patrick Walton a écrit :
On 7/9/12 2:44 PM, David Bruant wrote:
As far as I can tell, the visibility control issue is not taken care of.
What it means is that when a trait is composed of other traits, the
instances of these traits have every single method of all the traits
Le 10/07/2012 17:45, Sebastian Sylvan a écrit :
On Tue, Jul 10, 2012 at 4:15 AM, David Bruant bruan...@gmail.com wrote:
Why having both classes and traits? Both are mechanisms to enable code
reuse.
I guess I should restate my question: In which case would I use traits over
classes or classes
A paper [1] describes 2 issues with traits (and a suggests a solution,
but that's not what's bringing me here) : statelessness and lack of
visibility control.
In the proposal, the statelessness is taken care of in an interestingly
elegant manner: implementing the traitface (intraitface? nah,
Le 13/01/2012 19:54, Patrick Walton a écrit :
On 1/13/12 10:39 AM, David Bruant wrote:
It is my understanding that Rust is being designed also for the purpose
of being safer than C/C++ [4]. Tell me if I'm wrong, but if a component
is used as a library, it doesn't make it safer, yet
13 matches
Mail list logo
