Rust 0.4 released(mail.mozilla.org)
mail.mozilla.org
Rust 0.4 released
https://mail.mozilla.org/pipermail/rust-dev/2012-October/002489.html
65 comments
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?
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
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
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?
One such discussion in the mailing list: https://mail.mozilla.org/pipermail/rust-dev/2012-July/002094...
An example github issue discussing problems encountered: https://github.com/mozilla/rust/issues/1105
An example github issue discussing problems encountered: https://github.com/mozilla/rust/issues/1105
I asked Graydon about this near the release of 0.3. Here's the exchange:
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.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?
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.
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.
So type of 'a' is A. Type of 'a;b' is B. Type of 'a;' is A.
> 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.
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.
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.
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.
[deleted]
Sure, but I think readability and ease of editing should trump purity here (and I'm an OCaml user).
[deleted]
If you want to use a semi-colon, then use a return statement. ie: return foo;
That only works for the function-level return value, and not something like returning from a let x = match blah { ... } block.
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.
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!
What plans does mozilla have for Rust?
What are the projected applications?
What personal project could be an ideal use case for it?
Thanks!
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.
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 :)
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...
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...
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/ ).
Frequently, yeah, but the Rust developers seem to actually have some idea what makes C/C++ successful, so I think it stands a better chance than Java/C#/Go.
Wasn't D the replacement of C++?
thanks!
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/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...
> 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.
Sure, OS X since 10.4.
http://llvm.org/Users.html
Sure, OS X since 10.4.
http://llvm.org/Users.html
Also, Mesa / Gallium3D.
OS X does not use LLVM JIT.
From the link:
> Mac OS X 10.4: Uses the LLVM JIT for optimizing many parts of the OpenGL pipeline, including emulating vertex/pixel shaders when hardware support is missing, performing texture format conversion before uploading to the GPU, efficiently packing GPU buffers for vertex submission, and many others.
> Mac OS X 10.6: The OpenCL GPGPU implementation is built on Clang and LLVM compiler technology. This requires parsing an extended dialect of C at runtime and JIT compiling it to run on the CPU, GPU, or both at the same time.
http://llvm.org/Users.html
> Mac OS X 10.4: Uses the LLVM JIT for optimizing many parts of the OpenGL pipeline, including emulating vertex/pixel shaders when hardware support is missing, performing texture format conversion before uploading to the GPU, efficiently packing GPU buffers for vertex submission, and many others.
> Mac OS X 10.6: The OpenCL GPGPU implementation is built on Clang and LLVM compiler technology. This requires parsing an extended dialect of C at runtime and JIT compiling it to run on the CPU, GPU, or both at the same time.
http://llvm.org/Users.html
LLVM's JIT isn't a monolithic entity. There are a bunch of different components and feature options. Some paths are mature and well tested, and others are not. As a result, some projects are using it quite successfully, and some projects with different needs have different experiences.
I believe Pure uses LLVM JIT https://code.google.com/p/pure-lang/
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.
A REPL is extremely useful for learning, debugging (instead of using print statements, embed an interpreter to see exactly what is going wrong — IPython's one-line embed() for example), sketching (embed into an incomplete part of your program, try out a few things, when it works paste it to your source), and documentation (IPython's ? and ?? — completion is also part of that).
I think Rust's attractiveness is due to its type system, which does not necessarily need to be statically compiled.
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..., GHCi's name doesn't lie and it's actually an interpreter.
Notice that the first link I posted there is to a working Rust REPL (though it's rather rough at the moment, there's a lot that could be done to improve it).
wonder why ret -> return was decided on. the former is sufficiently clear me thinks, shorter too.
Don't listen to these official Rust developers, the real reason is that they're secretly functional programmers who would rather corrupt you into using Rust's implicit return values rather than the holy return statement.
fn heresy() -> &str { "I am the corruption lurking in your heart" }
For brevity, doesn't type inference work in this case? (I'm not up to speed on the language evolution).
fn heresy() -> { "I am the corruption lurking in your heart" }
fn heresy() -> { "I am the corruption lurking in your heart" }
Graydon (the Rust BDFL) has always been adamant about being explicit about types in function signatures, so no, you can't infer the return type there. I personally agree with this decision, since such an important part of using any API is knowing exactly what to put in and exactly what you're getting out.
However, closures are allowed to have all of their types inferred. This is because closures aren't allowed to exist at the top level of a file (in what's called "item position"), and so you don't really have to worry about them being used by others. The closure equivalent of the heresy example would be:
However, closures are allowed to have all of their types inferred. This is because closures aren't allowed to exist at the top level of a file (in what's called "item position"), and so you don't really have to worry about them being used by others. The closure equivalent of the heresy example would be:
// Note that the braces in this line are optional
let heresy = || { "I am the corruption lurking in your heart" };
// Though you're still allowed to be explicit, if you'd like
let heresy = || -> &str { "I am the corruption lurking in your heart" };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.
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.
> "return" met our 5-characters-max criteria
I'm curious as to how this conclusion was reached.
I'm curious as to how this conclusion was reached.
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.
: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.
Oh boy I can't count. That criteria is a little tongue-in-cheek. Basically the core developers decided saving those extra three characters wasn't worth it. We implicitly return the last expression, so "return" is typically only used for an early exit. Therefore it's more approachable to new users, and pretty rare so it doesn't add much clutter.
The 'r' is the zeroth character of course.
I think you made the right decision about 'return'. btw, if you're also changing 'alt', why 'match' rather than something more familiar to C programmers like 'switch'?
Also, did you consider pythonic 'and' and 'or' keywords? Typing 'or' requires fewer keystrokes than || (and 'and' requires no more than &&). Plus, neither requires any shifting! I know Rust developers are lazy typists. ;)
Also, did you consider pythonic 'and' and 'or' keywords? Typing 'or' requires fewer keystrokes than || (and 'and' requires no more than &&). Plus, neither requires any shifting! I know Rust developers are lazy typists. ;)
It's named after the alternation style used, which is well established in other languages.
Also, more readable. Personally, I think it's sad that Rust (along other systems-oriented languages like D and Go) haven't taken more of the syntax from Python, which I find to be superior to the world of curly braces.
Agreed. Especially since Rust uses a lot of different sigils already (@ , ~, &, ::, <>, || for closures...). Using and/or, hopefully along with significant whitespace would reduce the visual clutter.
Sometimes I'm a little sad about && and || as well (I'm a Python guy myself) but I get that Rust is trying to target C++ programmers first and foremost, and a little bit of familiarity goes a long way towards comforting newcomers. And judging by the number of self-proclaimed Python programmers lurking in in #rust (including at least one quite famous one), it hasn't been a complete turn-off.
Then again, the "C familiarity" rationale would seem to contradict the choice of `match` over `switch`, though I think pattern-matching is a sufficiently big deal to warrant a distinct keyword. It's an interesting comparison to Rust's old `tag` keyword, which was finally changed to `enum` because the easiest way to explain it was "look, they're basically C enums, but better". Personally I think the keyword should have remained `tag`, but you can't win 'em all. :)
Then again, the "C familiarity" rationale would seem to contradict the choice of `match` over `switch`, though I think pattern-matching is a sufficiently big deal to warrant a distinct keyword. It's an interesting comparison to Rust's old `tag` keyword, which was finally changed to `enum` because the easiest way to explain it was "look, they're basically C enums, but better". Personally I think the keyword should have remained `tag`, but you can't win 'em all. :)
Just make sure things stays very consistent and readable, I think that's the most important.
I don't think ret vs return is big deal. Both are understandable and relatively short, or expected. On the contrary, odd unknown, new syntax may sometimes be.
Good job on the new release :)
I don't think ret vs return is big deal. Both are understandable and relatively short, or expected. On the contrary, odd unknown, new syntax may sometimes be.
Good job on the new release :)
IMO, return is pretty standard and most people are familiar with it or get it right the way. Ret requires extra mental parsing at first.
With editor's code completion, it's really no big deal with the extra 3 chars. Alt-/ does the magic in Emacs.
Also people who really don't like the typing can use the implicit return expression.
With editor's code completion, it's really no big deal with the extra 3 chars. Alt-/ does the magic in Emacs.
Also people who really don't like the typing can use the implicit return expression.
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.
Which keywords did you like that were removed?
Removing 'again' to overload the meaning of 'loop' for example.
"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.
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.
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).
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).
for-while-break-continue is such a standard, I still don't see what justifies breaking it. (Do you really have less-than-N-characters rule? :) ) That fact that `continue` doesn't appear often is exactly why it has never been annoying to type.
What if there are three nested loops, two of which contain if-cond-then-continue, wouldn't the new syntax be too ambiguous?
What if there are three nested loops, two of which contain if-cond-then-continue, wouldn't the new syntax be too ambiguous?
I could agree if keywords were replaced by syntax, but I didn't get that impression from the release notes.
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).
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.
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.
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.
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.