

Rust 0.3 released - eslaught
https://github.com/mozilla/rust/blob/release-0.3/RELEASES.txt

======
sbmassey
Rust is the most promising up-and-coming programming language, in my opinion.

Finally a programming language with decent syntax that does RAII, and
understands the need to restrict garbage collection!

Thanks!

~~~
qznc
Why not D?

~~~
gecko
Because, faced with the fact that C++ makes an octopus by nailing extra legs
onto a dog, D decided the right thing to do was to staple-gun them onto a
cheetah instead.

D, at the end of the day, is C++ with cleaner _syntax_. Yes, you've gotten rid
of headers and some of the syntactic ambiguities, but things that were mutable
are still mutable, templates are still templates, hard-to-solve threading
problems are just as hard to solve, etc. Indeed, I'd argue this is one of the
reasons why C++ coders generally like D: it's the same damn thing with the
most painful dumbth removed.

Rust, on the other hand, focuses on having different _semantics_ from C++, in
order to make certain problems much easier to solve. The big one is
immutability, which makes code easier to reason about, and vastly simplifies
multithreaded code compared to its D or C++ counterparts. But there are other
major semantic differences, such as region pointers, the lack of nulls, and
more, that really solve the _semantic_ issues that crop up in C++ programs.

I know people who like D, and are highly productive in it, but Rust is solving
a very different problem in a very different way.

~~~
WalterBright
D has extensive support for transitive data immutability, and function purity.
(This is quite unlike C++.)

------
eslaught
Detailed release notes:

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

Download tarballs/docs/etc:

<http://www.rust-lang.org/>

~~~
kibwen
I also recommend the development roadmap:

[https://github.com/mozilla/rust/wiki/Note-development-
roadma...](https://github.com/mozilla/rust/wiki/Note-development-roadmap)

------
sandGorgon
Can Rust retarget GTK or QT ? Actually, the important question is whether it
is meant to.

Will it ever be intended to replace application languages like Vala, Mono
(used to write Tomboy, Banshee, etc.) or will it be restricted to system level
stuff.

If yes, will there ever be scripting support (like Ocaml
<https://ocaml.janestreet.com/?q=node/80>)

edit: Rust has a nice decentralized package manager as well called Cargo
[https://github.com/mozilla/rust/wiki/Doc-using-cargo-to-
mana...](https://github.com/mozilla/rust/wiki/Doc-using-cargo-to-manage-
packages) ) Pretty nice.

~~~
pcwalton
Yes, Rust is intended to play nicely with GTK and Qt. For one, browser engines
need to interface to the platform-native toolkits.

Scripting support would be cool. To me, Rust isn't necessarily the best
language to write small one-off scripts in; I personally prefer dynamically
typed languages (or whole-program type-inferred languages) for that. But if
you want to write scripts in Rust, I'd certainly review any pull requests to
make it easier :)

~~~
sandGorgon
I'm more interested in an alternative to write desktop apps in, rather than
small one off scripts.

I'm interested in this from a vision point of view. What are going to be your
first "written-using-Rust" apps ? Firefox is gargantuan, so it cant be your
first. Ergo, the question about platform toolkit compatibility. If you build
that one first, you will start spawning an ecosystem almost instantly... if
you want.

Mono, Vala, etc. have nice apps that people love. I am wondering on how can
you bridge the gap between javascript/Qtscript and Rust to make it easier to
build apps in.

~~~
zokier
>What are going to be your first "written-using-Rust" apps ?

Rust compiler is written in rust, so that would be the first "written-using-
Rust" app. Additionally afaik the work on rust-based web-browser (engine) has
began, so that would be second (major) project for rust.

~~~
erickt
I have been working on a web framework stack: <http://github.com/erickt/mre>

~~~
heretohelp
The elasticsearch thing makes it so niche and impractical though :\

------
zem
i love that they're thinking of syntax sugar right in the early stages. a lot
of the "language semantics are all that matters" crowd scoff at sugar, but i
think they underestimate how much syntax contributes to the pleasantness of
using the language.

~~~
cpeterso
Interesting. I like many of Rust's language concepts (and I have contributed
some small fixes to the Rust runtime), but (to _my_ eyes :) the syntax is
snowballing into a hybrid of C++ and APL.

~~~
pcwalton
What in particular do you not like? To me the proposed stuff on the roadmap
fixes the problems I see (changing "::" to ".", camel case for type names,
"alt" -> "match", => after pattern matches, #debug to debug!, removing
argument modes -- no guarantees that we implement these of course, they need
consensus), but I'm curious as to what your thoughts are.

~~~
jpd
Instead of angled_brackets<> they should probably try to go with D's style of
templates[1], which uses an operater !, to signify its use.

Also, I personally believe that camel case for type names would be a net loss;
the underscore separates the words nicely, and I think it's pretty clear from
the syntax what is and is not a type name (in my extremely limited
experience).

[1]. <http://dlang.org/templates-revisited.html>

~~~
lobster_johnson
What I like about camelcase is that it confers the same kind of visual
classification to types as to certain other things.

Back in the day, I used ObjectPascal, where we used camelcase for everything:
function names, variables, types. Borland set an early precedent by prefixing
many class types with the letter T, thus to visually distinguish them from
other things: So you had TWindow, TButton, etc. This system makes sense when
you see it in practice:

    
    
        function GetParent(Window: TWindow): TWindow;
        begin
          ...
    

While a bit crude, I feel the same kind of visual differentiation is needed
for a language like Rust.

Ruby has some syntactic oddities I like precisely because they provide visual
classification: "@" for instance variables and "@@" for class variables:

    
    
        class User
          @@max_name_length = 32
    
          def initialize(name)
            raise "Error" if name.length > @@max_name_length
            @name = name
          end
        end
    

The current "old-style" Rust code quickly becomes a uniform sea of lowercase
to me, as does Stroustrup-style C++. It gets worse due to a quirk of mine to
name things verbosely. So instead of variables like "u" to represent a user, I
spell out "user". With all lowercase it gets odd:

    
    
        fn save(user: user) {
          ...
        }
    

While Rust have types and variables living in separate namespaces, all-
lowercase names introduces the possibility of ambiguity and possibly makes
some things impossible in the future, I think; consider:

    
    
        let foo = user.new();
    

It looks like a method call "new()" on an instance "user". But what if you
could call methods on types? With the discussion about the "::" operator
becoming ".", such a distinction would become impossible without introducing a
new operator. With camelcase it becomes obvious what's what:

    
    
        let foo = User.new();

------
lbotos
Does anyone know the origin of the name? I did a quick look on
wikipedia/github/project site but couldn't find anything conclusive.

~~~
eholk
I heard that Rust was meant to capture the spirit of the language. It was
meant not to have a lot of knew ideas (although, as it turns out, language
design always leads to new ideas). We have a sort of informal rule to not
include research that's less than 10 years old, so we can build off of ideas
that have had a chance to prove themselves. We're bending that rule a bit now,
of course. The idea was that Rust would codify and provide language support
for patterns that have worked well in making large software like Firefox fast
and safe.

------
brson
And the release announcement:

[https://mail.mozilla.org/pipermail/rust-
dev/2012-July/002087...](https://mail.mozilla.org/pipermail/rust-
dev/2012-July/002087.html)

------
vitno
Not only is rust a pretty awesome language, the Rust devs are amazingly
helpful on the IRC channel.

------
switch33
Two of the newest programming languages that I think have potential are Io and
Rust. Io is a mash up of languages with speed similar to lua and has a list
like syntax of lisp.

I wonder if anyone can explain why they have not tried to incorporate some of
lisp's syntax as it is more efficient for linked lists I think. And I thought
part of the reason for Rust's development was for very fast/efficient
concurrency that is properly garbage collected.

~~~
igouy
>>Io is a mash up of languages with speed similar to lua...

Please provide some examples that show _Io speed similar to Lua_.

------
btipling
Looking forward to 1.0. The #rust IRC channel on irc.mozilla.org is full of
activity.

------
tallowen
What are Mozilla's plans for integrating rust into Firefox? Is this a mostly
theoretical constraint or is there a plan to have this implemented?

~~~
kibwen
Rust is being used to implement an experimental new browser engine with a
focus on concurrency in order to better take advantage of highly-parallel and
power-limited hardware. It's known as Servo,[1] and it's still strictly in
research mode; there are no concrete plans to integrate anything into Firefox
as of yet. Even if there were, Rust itself won't be at 1.0 until sometime next
year, and it would be quite a while beyond that before Servo had any semblance
of feature parity with Gecko.

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

~~~
agumonkey
Still can't build it (llvm fails somewhere) but reading the source code is
interesting, very concise.

~~~
pcwalton
Please file an issue regarding the build problem if you get the time on our
issue tracker: <https://github.com/mozilla/rust/issues>

We're trying to iron out all of these issues.

------
nimrody
Has Mozilla given up on Typestate? I see no mention of it in the release
notes.

~~~
kibwen
(Note: not a Rust dev, I just hang out in the IRC channel)

Typestate's still there for the time being, but it may not be for much longer.
The problem is that it's not being _used_ anywhere in the compiler, so it's
not getting exercised nor is it providing any constructive design feedback.
Last year there was an attempt to begin using typestate throughout the
compiler and standard library, but it proved so clunky to use in practice that
nobody had any patience to deal with it. So now there are two camps among the
developers: those who consider the (quite large) subsystem to be a useless
maintenance albatross, and those who would still like the idea of typestate
but who acknowledge that it's not usable in its current form. Rust's BDFL
appears to be slowly migrating from the latter camp to the former, so
typestate may not be around for much longer.

Either way, making the whole thing work would require more effort than anyone
has time for at the moment. Of course, this doesn't mean that it can't be
removed now and then reintroduced in some future version of Rust.

Actually, wait, I remember asking Graydon (the Rust lead) about this. I was
saving this for the 0.3 release discussion, so now's the perfect time:

    
    
      me:      so what were the reasons that nobody ever used typestate? was it just too cumbersome?
      graydon: combination of incomplete and wound up not often able to benefit from much code-path-distance between site of check and site of constraint-enforcement.
      graydon: I'm still unconvinced that could not be overcome
      graydon: but the result is that using it has effectively caused all callers to do checks just before they call, which isn't much of a win
      me:      graydon: was typestate the whole reason you started rust in the first place? I'd be really interested to read a retrospective :)
      graydon: no, I started rust because I was sick of hacking in C++ and wanted something with a saner compilation model, grammar, safety properties, concurrency properties ...
      graydon: I'd used lots of other languages and kept not being able to use them in an industrial setting, because they failed to be similar-enough to C++ in important ways, usually.
      graydon: typestate was just a property that hermes had that I liked because it looked like a way to statically optimize DBC, which I like in languages that have it
      graydon: (sather, eiffel, some of the C# derivatives)
      graydon: I tend to program over-defensively when left to my own devices. make copies of every datum to be local. make everything const. run a lot of internal consistency self-checks. etc. etc.
      graydon: (the one habit I hadn't picked up yet, which I'm still trying to, is adequate unit testing and fuzzing ... sigh)
      me:      graydon: so are you confident yet that even if someone was forcing you to write rust, you would't be sick of it? :)
      graydon: my experiences writing rust so far have been pretty positive. it has a number of the parts I like in other languages. the grammar is simpler, the compilation model is better, it's AOT and static, it has algebraic types, clear integer types, is eager and reasonably fast, doesn't force OO style...
      graydon: and crucially: doesn't need to allocate / GC like crazy, so can close that residual gap on inner loops without having to hit the FFI
      graydon: there are still odd bits we need to whittle down
      graydon: oh also the safe references are lovely. and getting better.

~~~
obtu
Reformatted:

me: so what were the reasons that nobody ever used typestate? was it just too
cumbersome?

graydon: combination of incomplete and wound up not often able to benefit from
much code-path-distance between site of check and site of constraint-
enforcement.

graydon: I'm still unconvinced that could not be overcome

graydon: but the result is that using it has effectively caused all callers to
do checks just before they call, which isn't much of a win

me: graydon: was typestate the whole reason you started rust in the first
place? I'd be really interested to read a retrospective :)

graydon: no, I started rust because I was sick of hacking in C++ and wanted
something with a saner compilation model, grammar, safety properties,
concurrency properties ...

graydon: I'd used lots of other languages and kept not being able to use them
in an industrial setting, because they failed to be similar-enough to C++ in
important ways, usually.

graydon: typestate was just a property that hermes had that I liked because it
looked like a way to statically optimize DBC, which I like in languages that
have it

graydon: (sather, eiffel, some of the C# derivatives)

graydon: I tend to program over-defensively when left to my own devices. make
copies of every datum to be local. make everything const. run a lot of
internal consistency self-checks. etc. etc.

graydon: (the one habit I hadn't picked up yet, which I'm still trying to, is
adequate unit testing and fuzzing ... sigh)

me: graydon: so are you confident yet that even if someone was forcing you to
write rust, you would't be sick of it? :)

graydon: my experiences writing rust so far have been pretty positive. it has
a number of the parts I like in other languages. the grammar is simpler, the
compilation model is better, it's AOT and static, it has algebraic types,
clear integer types, is eager and reasonably fast, doesn't force OO style...

graydon: and crucially: doesn't need to allocate / GC like crazy, so can close
that residual gap on inner loops without having to hit the FFI

graydon: there are still odd bits we need to whittle down

graydon: oh also the safe references are lovely. and getting better.

------
stewbrew
What problem does rust solve other languages (D, SML, OCaml, C++11, Objective
C, vala, go etc.) did not -- apart from helping with the NIH syndrome? Does
Mozilla actually use a language that still is a moving target with respect to
its language specification for some substantial work (or what is the real-
world status of that upcoming rendering engine which seems to be the reason
why rust was called into life)?

~~~
pjmlp
I guess it is the need to explore new ideas, even if the language dies, some
of its ideas might be picked up by mainstream languages.

~~~
asadotzler
It's precisely not the need to explore a lot of new ideas. Rust is taking
tried and true paths to something new :-)

~~~
kibwen
Ah, but I think it's important to distinguish between ideas that are new in
research and ideas that are new in industry. God knows that pattern matching
isn't a particularly new concept, but I sure hadn't heard of it before Rust;
see also the popularization of list comprehensions due to Python via Haskell.
So I think what the grandparent is implying is that even if Rust doesn't end
up as a world-shattering language, it still has the opportunity to expose
programmers to "new" ideas, even if, in academia's opinion, those ideas aren't
so new at all. :)

~~~
pjmlp
Exactly, for example, now thanks to the FP concepts that have been added to
.NET in the last versions, I am able to do cool FP stuff while coding boring
enterprise applications in C#, without having to ask permission about it.

Or make use of F# for Windows scripting, using as excuse to the boss that it
is part of Visual Studio.

------
fzzzy
Yay! Congrats guys!

------
gwillen
Just in time to use it for ICFP!

