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

61–70 of 97 posts

Re: Rust 0.2 released

#61

Post by willvarfar »

Arelius wrote: post #59
willvarfar wrote: post #57

Earlier quoted context omitted.

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.

but that was the very point of comparing Python and Haskell.

FWIW the Haskell crowd were super-defensive and claimed that Haskell is super-readable (by them).

Now in that article I talk about 'curly bracket' languages in general, meaning those that use symbols (words) to denote blocks rather than indent. And I don't like reading them because of that.

Re: Rust 0.2 released

#62

Post by jk4930 »

batista wrote: post #54
jk4930 wrote: post #22

Earlier quoted context omitted.

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…

They want a language that's safe, concurrent, blabla, and good for system programming? Then they should take a look at Ada 2012. But I guess they just want to build something themselves.

They could even make use of Ada's real time capabilities. It was a pleasure when I ran QNX (2005) and everything responded to my actions on spot, even their browser (Voyager). Today I run FF and after a while and with several tabs open it takes (many) seconds until this beast shows some reaction.

BTW I don't use Ada but mostly Haskell since 2001.

Re: Rust 0.2 released

#63

Post by jamii »

willvarfar wrote: post #60
masklinn wrote: post #43

Earlier quoted context omitted.

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

Erlang disallows shared memory in favour of per-process gc. Whether or not this is a good tradeoff in general is debatable but it is what makes the gc acceptable in soft-realtime environments. Go makes a different set of tradeoffs (shared mutable memory, whole process gc, no hot code reloading) which place it in a different niche to erlang.

Re: Rust 0.2 released

#64

Post by masklinn »

willvarfar wrote: post #60
masklinn wrote: post #43

Earlier quoted context omitted.

> 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 you confusing concurrency with parallelism?

No.

> Wrong. Concurrency is not some accidental bolt-on in Erlang

You might want to read my comment correctly and avoid injecting things which are not in it. I did not say concurrency was "bolted on", I said it was not a primary goal of Erlang's design, it was merely one of the tool deployed to reach the over-arching goal of reliability.

> I was replying to the parent saying that GC is utterly incompatible with a systems language.

Can't say I've ever seen Erlang called a systems language. But in any case Erlang's design and VM structure does make it suitable for soft real-time (per-process shared-nothing[0] heaps independently GC'd with configurable initial heaps, allowing such things as never GC'ing a process at all). Go still's no Erlang.

[0] aside from reference counted big binaries

Re: Rust 0.2 released

#65

Post by obtu »

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 syntax could be made much better by focusing on usability and readability. It seems unimportant at first, but I know people get turned off functional languages because of this, and people go so far as to maintain alternate syntaxes and toolchains for Erlang, OCaml, JavaScript. Take a page from one of the “executable pseudocode” languages and their very clean syntaxes.

Re: Rust 0.2 released

#66

Post by obtu »

akavlie wrote: post #17
heretohelp wrote: post #15

Earlier quoted context omitted.

It makes fewer compromises than Go. It'd be more appropriate for concurrent, high performance systems projects, whereas Go is a way to rapid-dev high(er) performance networked services.

What sorts of compromises does Go make (that Rust does not)?

No parametric polymorphism, which means plenty of casts, runtime checks, and annotations. This sacrifices performance, compile-time guarantees, and programmer productivity for a simpler and slightly faster compiler.

Re: Rust 0.2 released

#67

Post by obtu »

jk4930 wrote: post #62
batista wrote: post #54

Earlier quoted context omitted.

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…

They want a language that's safe, concurrent, blabla, and good for system programming? Then they should take a look at Ada 2012. But I guess they just want to build something themselves. They could even make use of Ada's real time capabilities. It was a pleasure when I ran QNX (2005) and everything responded to my actions on spot, even their browser (Voyager). Today I run FF and after a while and with several tabs op…

Today's web isn't the 2005 web. Go to a geocities archive with both browsers and the results will be much closer. Faculty pages also work, they're almost always free of dynamic bloat.

Re: Rust 0.2 released

#68

Post by obtu »

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?

The costs of threads vs processes are identical if you're prepared to put some stuff in virtual memory (except on Windows, and I don't know if that has improved). Processes default to full isolation, threads are the reverse, but Rust has enough compile-time guarantees that it can do its own isolation for most purposes. I imagine they could go back and forth on this one without breaking source compatibility.

Re: Rust 0.2 released

#69

Post by JulianMorrison »

batista wrote: post #54
jk4930 wrote: post #22

Earlier quoted context omitted.

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…

Ada is good because of useful typing (such as the ability to say "apples and oranges are both represented as signed 32 bit integers, the allowable range for apples is 0..5, and you can't mix them"), strong control over data representation, standardized extensions for on-the-metal programming and hard real time, built in synchronous message passing concurrency, and just generally being an awesome language. It's also good because of SPARK Ada, which is an ultra-safe Ada subset plus annotations and supports extensive static checking.

None of this require buying into marketing hype.

It's bad because the language is large and some parts feel out of date, the memory management is more complicated than it ought to be, and compilers are thin on the ground and often expensive. Targeting C at a new machine is much easier than Ada, and this is probably the main reason why it lost.

Re: Rust 0.2 released

#70

Post by obtu »

nimrody wrote: post #53
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...

Rust actually has multiple heaps with their own lifetime characteristics so that they can avoid GC in many cases, and that the only GCed areas are per-thread.
Post reply on HN