Rust 0.4 released(mail.mozilla.org) |
Rust 0.4 released(mail.mozilla.org) |
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...
Sure, OS X since 10.4.
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).
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.
An example github issue discussing problems encountered: https://github.com/mozilla/rust/issues/1105
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.So type of 'a' is A. Type of 'a;b' is B. Type of 'a;' is A.
What plans does mozilla have for Rust?
What are the projected applications?
What personal project could be an ideal use case for it?
Thanks!
fn heresy() -> &str { "I am the corruption lurking in your heart" }
fn heresy() -> { "I am the corruption lurking in your heart" }
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.
I'm curious as to how this conclusion was reached.
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. ;)
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 :)
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.
> 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.
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.
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).
What if there are three nested loops, two of which contain if-cond-then-continue, wouldn't the new syntax be too ambiguous?
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.
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.
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...
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" };: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.
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. :)