Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 0.2 released

mail.mozilla.org

Post reply on HN
Print view View original

41–50 of 97 posts

Re: Rust 0.2 released

#41

Post by Arelius »

rdtsc wrote: post #38
willvarfar wrote: post #37

Earlier quoted context omitted.

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.

I think there is a semantic difference. Each actor has one mail box. So when sending a message to it, the message is sent to the pid (address) of the actor. So the actor become the central abstraction without the need for channels. 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…

Making a strong association between tasks and message boxes like erlang does makes too many assumptions. That'd be an apt choice for many languages. But for Rust, as a systems languages, that seems like a poor choice.

Re: Rust 0.2 released

#42

Post by Arelius »

willvarfar wrote: post #35
Arelius wrote: post #30

Earlier quoted context omitted.

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.

This irks me to bits. You need to be an ambidextrous octopus to get a { out of my (non-US) keyboard.

The problem is many languages are designed on US keyboards. And even engineers who are otherwise mindful of unicode and other internationalization problems, may trivially forget what keys may not be on other keyboards.

I suppose your best bet may be to muck a bit with the key bindings of your particular text editor. IMO, I already swap some keys around to make () and {} more usable.

Re: Rust 0.2 released

#43

Post by masklinn »

willvarfar wrote: post #36
heretohelp wrote: post #23

Earlier quoted context omitted.

Pertinent to what I said? Garbage collection is the biggie. Utterly unacceptable in systems work.

"Systems language" embraces more than kernels and such. Go is a new Erlang; its the Erlang for people who don't like Erlang, perhaps?

> Go is a new Erlang;

It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime).

Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.

Re: Rust 0.2 released

#44

Post by masklinn »

Arelius wrote: post #32
btipling wrote: post #12

So the garbage collection is optional? That's cool.

Sorta... many types have a more strongly enforced ownership style lifetime scope, but depending on the data you are declaring, the collector may come into action automatically. 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.

In previous threads (can't remember if it was here or on reddit), Rust developers noted that Rust currently needs a GC for many things, but part of the Region works is aimed at removing that need (aka unless the efforts fail, you should be able to use Rust 1.0 sans GC)

Re: Rust 0.2 released

#45

Post by rdtsc »

Arelius wrote: post #41
rdtsc wrote: post #38

Earlier quoted context omitted.

I think there is a semantic difference. Each actor has one mail box. So when sending a message to it, the message is sent to the pid (address) of the actor. So the actor become the central abstraction without the need for channels. 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…

Making a strong association between tasks and message boxes like erlang does makes too many assumptions. That'd be an apt choice for many languages. But for Rust, as a systems languages, that seems like a poor choice.

> But for Rust, as a systems languages, that seems like a poor choice.

Yeah I can see that I guess. It is a lower level language so it would be the same as asking for closures or garbage collection in assembler?

> Making a strong association between tasks and message boxes like erlang does makes too many assumptions.

It does, and often having good assumptions is nice. One can argue that at some point unless the system is not C then someone can say it is making "assumptions".

In their documentation they do mention how they are trying to emulate Erlang (they even have supervision trees for tasks) so my point was that they left a critical semantic feature out.

Re: Rust 0.2 released

#47

Post by rdtsc »

jamii wrote: post #39
rdtsc wrote: post #34

> 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…

After a couple of years of writing erlang full-time, tying mailboxes to processes is one of the things that really bugs me. It conflates mutable state, addresses and queues into one construct. Using channels allows multiple writers/readers per queue, passing the channel as a first class value and allows transparent task restarting without needing global address registration per task.

I disagree. I think tying both together produces a new abstraction -- the actor. Not having it that way, offers little more than a thread and a bunch of queues.

Presumably you could still use a queue to provide the semantics you want, even now? Or have another actor that acts as the queue. But I think that use case doesn't warrant decomposing actors into channels and tasks.

Re: Rust 0.2 released

#48

Post by someone13 »

cpeterso wrote: post #27
lemming wrote: post #21

I love the idea of Rust, but... Shorten 'mutable' to 'mut' Seriously? Are we editing with TextEdit in this day and age?

The ret and crust keywords also irk me. In ye old time Unix tradition, the Rust developers favor extreme brevity. :)

Yeah, I found "crust" to be rather counter-intuitive. I think one of the reasons that bugs me is that "ret" and "mut" don't have any intrinsic meaning in English, but my brain insists on reading "crust" as if it were a word.

I'd personally have gone with "rustc".

Re: Rust 0.2 released

#49

Post by digitalzombie »

Why didn't they do GC per process like Erlang instead of GC per thread?

I thought processes and sub processes are cheaper to spawn then threads? That's the reason why Chrome tabs are in per sub processes right? Instead of threads?

Re: Rust 0.2 released

#50

Post by mkup »

digitalzombie wrote: post #49

Why didn't they do GC per process like Erlang instead of GC per thread? I thought processes and sub processes are cheaper to spawn then threads? That's the reason why Chrome tabs are in per sub processes right? Instead of threads?

GC per lightweight thread does not imply stop-the-world approach as in Go.

Also process is heavier entity for OS kernel in comparison to thread (address space, file descriptors are all per-process objects, not per-thread, thread is just a unit of processor time scheduling). Chrome tabs are processes for security reasons. Chrome trades speed for security in this context.

Post reply on HN