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

51–60 of 97 posts

Re: Rust 0.2 released

#51

Post by Arelius »

rdtsc wrote: post #45
Arelius wrote: post #41

Earlier quoted context omitted.

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

Even if a system is C you can say it is making assumptions. The point is to make as few as practical.

I think they are trying to learn from Erlang, not replicate it completely. The key point is that the missing feature can be pretty trivially made up for by libraries and convention. Which again, seems like an apt choice for a systems language.

Re: Rust 0.2 released

#53

Post by nimrody »

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?

Erlang's style per-process garbage collection requires (or at least favors) passing messages by value between processes.

Both Go and Rust - being relatively low level - prefer passing pointers (references) rather than the data itself. This requires a shared GC heap.

No free lunch...

Re: Rust 0.2 released

#54

Post by batista »

jk4930 wrote: post #22
neilc wrote: post #9

Earlier quoted context omitted.

Its singular goal is to be an awesome language for writing next-generation browser engines. Well, per the FAQ: ( https://github.com/mozilla/rust/wiki/Doc-project-FAQ ) What is this project's goal, in one sentence? To design and implement a safe, concurrent, practical, static systems language.

Then they should use Ada. If it's good enough for high integrity applications in space, transportation, or banking, then it's certainly good enough for browsers. ;)

You know, there are some things that --to me-- absolutely identify a newcomer to this programming/computer thing.

One is the belief that it would be to good to write everything in assembly (from OSs to browsers to games) so that it would be faster. See they heard that assembly is faster and lower-level, so "the more the merrier, right"?

Another (that you don't get much nowadays, but there was a time in the early 90's that was very common) was this fascination with Ada. Mostly because of all the marketing and BS articles at the time. The reasoning here was "well, if they use that for missiles and F16s, it must be the best, right?"

Re: Rust 0.2 released

#55

Post by zokier »

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?

Firstly, while I'm not very familiar with Erlang or its runtime, afaik Erlang processes are not actual OS processes.

Secondly threads were originally created as a cheaper alternative because spawning processes was too expensive (on Windows). The original reason for Chrome using processes was that processes gives you memory protection. But I don't know how much it really helped them in the end, because they quickly noticed that using one process per tab doesn't scale. Thus Chrome (at least originally) limited the maximum number of processes to ten.

Re: Rust 0.2 released

#56

Post by damien »

akavlie wrote: post #13

Rust seems very similar to Go. Anyone looked at/played with both enough to offer some wisdom on the pros/cons of each language?

From the language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ

Go adopted semantics (safety and memory model) that are quite unsatisfactory.

    Shared mutable state.
    Global GC.
    Null pointers.
    No RAII or destructors.
    No type-parametric user code.

Re: Rust 0.2 released

#57

Post by willvarfar »

Arelius wrote: post #42
willvarfar wrote: post #35

Earlier quoted context omitted.

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.

continuing this tangent, I'm not a fan of closing blocks either; I much prefer indentation http://williamedwardscoder.tumblr.com/post/18319031919/progr...

Re: Rust 0.2 released

#58

Post by willvarfar »

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…

I meant that I'm all for Rust providing the mailboxes abstraction too but not for channels to go away.

Re: Rust 0.2 released

#59

Post by Arelius »

willvarfar wrote: post #57
Arelius wrote: post #42

Earlier quoted context omitted.

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.

continuing this tangent, I'm not a fan of closing blocks either; I much prefer indentation http://williamedwardscoder.tumblr.com/post/18319031919/progr...

Yeah, Significant whitespace is why I won't code in Python anymore. Also, the linked article's comparison of Haskell and Python on readability is an awfully poor comparison, Haskell has notoriously terse syntax, In comparison to Python, which is nearly designed with the sole purpose of having good looking syntax.

Re: Rust 0.2 released

#60

Post by willvarfar »

masklinn wrote: post #43
willvarfar wrote: post #36

Earlier quoted context omitted.

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

Are you confusing concurrency with parallelism?

> Erlang's primary goal has always been reliability. Not concurrency

Wrong. Concurrency is not some accidental bolt-on in Erlang: http://www.erlang.org/course/history.html

Now I picked out Erlang because it has ... garbage collection. I was replying to the parent saying that GC is utterly incompatible with a systems language.

Go and Rust are the new Erlangs in that they are the go-to language for system services above kernel level.

Post reply on HN