31–40 of 97 posts
I don't have a lot of experience with systems programming but want to play around with Rust. Would the best route be to learn C then move onto the untread waters of Rust? I'm just looking for some guidance, this seems really cool to learn.
So the garbage collection is optional? That's cool.
Basically, Rust makes it easy to avoid the collector by clear ownership rules, but still provides a collector for the cases where that just won't do.
I don't have a lot of experience with systems programming but want to play around with Rust. Would the best route be to learn C then move onto the untread waters of Rust? I'm just looking for some guidance, this seems really cool to learn.
let port = comm::port::();
let chan = comm::chan::(port);
task::spawn {||
let result = some_expensive_computation();
comm::send(chan, result);
}
some_other_expensive_computation();
let result = comm::recv(port);
Earlier quoted context omitted.
Is it worse than shorting "integer" to "int" or "begin scope" to "{"?
I think your first point is valid, but Punctuation has other advantages, the symmetry between {} and the distinctness of the symbols (Taller than most, for instance) provide other advantages for the later.
Earlier quoted context omitted.
What sorts of compromises does Go make (that Rust does not)?
Pertinent to what I said? Garbage collection is the biggie. Utterly unacceptable in systems work.
Go is a new Erlang; its the Erlang for people who don't like Erlang, perhaps?
> Now that we have spawned a child task, it would be nice if we could communicate with it. This is done by creating a port with an associated channel. let port = comm::port:: (); let chan = comm::chan:: (port); task::spawn {|| let result = some_expensive_computation(); comm::send(chan, result); } some_other_expensive_computation(); let result = comm::recv(port); Why not let the task have a mailbox and send messages t…
One can be built on the other, and it being built by the platform rather than the coder would be a big plus. Lets hope mailbox abstraction turn up in the next release.
> Now that we have spawned a child task, it would be nice if we could communicate with it. This is done by creating a port with an associated channel. let port = comm::port:: (); let chan = comm::chan:: (port); task::spawn {|| let result = some_expensive_computation(); comm::send(chan, result); } some_other_expensive_computation(); let result = comm::recv(port); Why not let the task have a mailbox and send messages t…
Well ideally you want both? One can be built on the other, and it being built by the platform rather than the coder would be a big plus. Lets hope mailbox abstraction turn up in the next release.
To emulate that with channels it is like saying you have one default channel created for each task. Instead of sending a message to the task, it is sent to a channel and instead of just a simple receive, the task has to has a reference to the same channel.
Another way of thinking about it, it is like having a graph of components and one model emphasizes the nodes (actors) and the other emphasizes the edge (channels) as the central abstraction.
> Now that we have spawned a child task, it would be nice if we could communicate with it. This is done by creating a port with an associated channel. let port = comm::port:: (); let chan = comm::chan:: (port); task::spawn {|| let result = some_expensive_computation(); comm::send(chan, result); } some_other_expensive_computation(); let result = comm::recv(port); Why not let the task have a mailbox and send messages t…
> Now that we have spawned a child task, it would be nice if we could communicate with it. This is done by creating a port with an associated channel. let port = comm::port:: (); let chan = comm::chan:: (port); task::spawn {|| let result = some_expensive_computation(); comm::send(chan, result); } some_other_expensive_computation(); let result = comm::recv(port); Why not let the task have a mailbox and send messages t…