

Rust 0.4 released - kumarshantanu
https://mail.mozilla.org/pipermail/rust-dev/2012-October/002489.html

======
kibwen
The note regarding "preliminary JIT support" buried at the end is one of my
favorite new features (and it's a tough call, since there's so damn many new
features), since it makes stuff like this possible:

<https://github.com/bleibig/rust-repl>

I hear that LLVM's JIT support is rather untested, I'd be interested to learn
if there are any other major projects besides Rust making use of it.

In general, if you haven't checked out Rust yet I'd still recommend waiting
until the implementation of traits is finished off (scheduled as a high
priority[1] for 0.5, which is tentatively scheduled for sometime around year's
end).

[1] <https://github.com/mozilla/rust/wiki/Note-0.5-priorities>

EDIT: Oh, and here's a direct link to the detailed release notes rather than
the summary presented in the OP:

[https://github.com/mozilla/rust/wiki/Doc-detailed-release-
no...](https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes)

~~~
cpeterso
What is the use case for a Rust JIT? A REPL or runtime eval()? I though the
static compilation of Rust code was one of it selling points.

~~~
duaneb
I think Rust's attractiveness is due to its type system, which does not
necessarily need to be statically compiled.

~~~
masklinn
Conversedly, you can have compilation and a REPL, Clojure has a repl yet is
always compiled (repl instructions are compiled to JVM bytecode using the
usual compilation toolset, then that bytecode is loaded and executed).
According to
[http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci...](http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-
compiled.html), GHCi's name doesn't lie and it's actually an interpreter.

------
mej10
So what needs to be done in Rust? It seems like a pretty interesting language,
and I have some free time coming up. What kinds of things would people like to
see?

~~~
kibwen
Help would definitely be appreciated, there's a whole lot to do. See the issue
tracker on Github[1] for a starting point. Filter by the "E-easy" tag if you
just want to dip your toes. The "A-an-interesting-project" tag is where it
gets, er, interesting; those issues represent projects that don't necessarily
have a high-enough priority to block 1.0, but that everyone would love to see
and that a single motivated, skilled contributor could conceivably produce.

And if you ever need any help, check out the mailing list[2] or #rust on
irc.mozilla.org (most active during Californian working hours).

[1] <https://github.com/mozilla/rust/issues>

[2] <https://mail.mozilla.org/listinfo/rust-dev>

------
Jare
My impression is that their push to remove keywords is hurting the readability
of Rust code. They also seem undecided about the keyword length issue. In any
case, it's really interesting to witness the evolution of the language.

~~~
pcwalton
Which keywords did you like that were removed?

~~~
Jare
Removing 'again' to overload the meaning of 'loop' for example.

~~~
pcwalton
"continue" is very long (out of place with the rest of the keywords), "again"
was quite unpopular ("next" is out in a systems language due to linked lists),
and the construct isn't used very often anyway (just a handful of places).

A lot of people like languages with small sets of keywords (for example,
Python, Lua, or Go). It helps you keep the whole language in your head. We
wanted to replicate that.

~~~
Jare
I understand, and I can only imagine all the debates about naming, which
programmers seem to love.

My point is just that by multiplexing a keyword, you shift the cost from one-
time in-head knowledge of two keywords, to having to look at the context every
time the keyword appears.

My personal preference is to reduce the cost of reading code above everything
else (which is what turned me off the otherwise wonderful to write
CoffeeScript, for example).

------
felixmar
Now that the language syntax is mostly stabilized, i am hoping that more focus
will go to the standard library. Currently it seems rather ad hoc and not
always consistent (which is understandable because of all the language
changes).

~~~
kibwen
Absolutely, the standard libraries are sorely desperate for some TLC. If
anyone fancies themselves a connoisseur of batteries-included libraries in the
vein of Python and Go, even just stubbing out a nice API without any code
would go a long way towards directing the community development effort.

~~~
nickik
Sounds intressting. Data Structure libs are one of the best cases to show of
how cool and polymorthy your language can be.

I dont know if that exists allready but I think I am going to implment a
persisten vector (like clojure vector) in rust and see if it interacts nice
with other libs.

I have done with other languages, would give a lot of inside into rust.

~~~
erickt
That sounds great. We do have a basic package management system
(<https://github.com/mozilla/cargo-central>), so it'll be easy to get anything
you write into the community.

------
dochtman
IIRC, typestate was one of the big things in the initial
releases/presentations of Rust. Is there an overview/discussion/ideas on why
it ended up being removed?

~~~
doublec
One such discussion in the mailing list:
[https://mail.mozilla.org/pipermail/rust-
dev/2012-July/002094...](https://mail.mozilla.org/pipermail/rust-
dev/2012-July/002094.html)

An example github issue discussing problems encountered:
<https://github.com/mozilla/rust/issues/1105>

------
gbaygon
I cannot seem to grasp the scope of this language, so please if any of you
fellow gentlemen could enlighten me, i would like to know:

What plans does mozilla have for Rust?

What are the projected applications?

What personal project could be an ideal use case for it?

Thanks!

~~~
wmf
It's basically a replacement for C/C++, but safer, with more functional
flavor, and better support for parallel programming. If used properly, Rust
should be faster than Java or Go because it can create non-garbage-collected
objects. Mozilla is writing a parallel browser called Servo in Rust.

~~~
zura
When a company declares some language X as a replacement for C/C++, X actually
becomes replacement, or to be more precise, attracts engineers from some other
language L, but C/C++ stays in place :)

~~~
wladimir
If they can make a safer, more secure and less verbose C/C++, without giving
up on what makes C/C++ a good choice for some projects (low-level control and
performance), I'm sure some people will switch (I know I will). It's just that
no one succeeded in this before.

It's just too easy to shoot yourself in the foot with the current C/C++.
Combined with developers overestimating themselves and a lack of static
checking by compilers, this results in all kinds of hard-to-debug and hard-to-
find issues. A language that guarantees no dangling NULL pointers, no buffer
overflows and safe concurrency/parallelism is a great promise, at least.

Hopefully it gains enough critical mass. We'll see where this goes...

~~~
jk4930
Look at Ada (Ada 2012 came out this year). Safer and more secure, not less
verbose though. You can do real-time, parallel, distributed, reliable stuff
with it. Try the OSS GNAT compiler (comes with your gcc or look at
<http://libre.adacore.com/> ).

------
ww520
One thing I don't understand is the rational behind the decision that the
returning expression in a block has to have the semicolon omitted. Why can't
we just say the last statement of a block is the returning expression of the
block, regardless of semicolon?

~~~
masklinn
Because — as in Erlang — the semicolon is a _separator_ , and the expression's
value does not go through it? So the type of `a` is A, but the type of `a;` is
Unit.

~~~
ww520
You meant semicolon is used as a _binary operator_ , joining the statements
into one long expression. Since it's an operator, its behavior can be defined
to however make sense. Why not just say in the absence of the right operand,
return the result of the left operand? Just like || (or) can return the result
of left or right operand.

So type of 'a' is A. Type of 'a;b' is B. Type of 'a;' is A.

~~~
masklinn
> You meant semicolon is used as a binary operator

Not necessarily no, I don't know how it works precisely in Rust but in Erlang
it is _not_ an operator, it's exactly what I wrote: a separator.

~~~
ww520
Ok, I see. I guess it's like the comma in other languages delimiting the terms
in a list expression, (a, b, c), where the last term is returned as the result
of the expression. But what's the difference between a separator and an
operator? Both of them define certain semantic. In the Erlang case, the
semicolon evaluates two operands and returns the right term, just like a
binary operator.

What I'm trying to say is there is no one right way to define an
operator/separator behavior. It's entirely upto the language design. One can
define the missing last term to be omitted completely. E.g. (a , b , c , )
could return c. And { s1 ; s2 ; s3 ; } could return s3.

Edit: Ok, I didn't know Erlang. Apparently semicolon is same as the OR
operator in the case statement, not as a sequencing operator like comma.

------
ternaryoperator
I'd like to know how Rust is better/different than Vala. Not the usual feature
comparisons, I can look them up myself and have done. But rather if anyone's
done programming in both and can compare the experience.

------
leeoniya
wonder why ret -> return was decided on. the former is sufficiently clear me
thinks, shorter too.

~~~
erickt
We like brevity in our keywords, but we felt that "ret" was taking things a
little too far. "return" met our 5-characters-max criteria, so we switched.

edit: Ho ho ho, I can't count. And we don't really have a 5-character-max
criteria, but we do prefer shorter keywords.

~~~
lmkg
> _"return" met our 5-characters-max criteria_

I'm curious as to how this conclusion was reached.

~~~
freditup
Well, the actual keyword is retum. It turns out that most humans can't tell
the difference between an r and an n next to each other, or the letter m, so
they just decided to go with the quicker to type 'm' instead or 'rn' You've
just been reading it wrong.

:D Honestly, I think either ret or return is fine, but I'd match other
keywords. So if you're using pub and priv instead of public and private, I'd
use ret instead of return as well.

