Mozilla releases version 0.1 of the Rust programming language
mail.mozilla.org
mail.mozilla.org
That said, it's hard to imagine anything displacing C for me. Almost any systems code I write these days is something I'll eventually want to be able to expose to a high-level language (Lua, Python, Ruby, etc). To do that you need code that can integrate into another language's runtime, no matter what memory management or concurrency model it uses. When you're trying to do that, having lots of rich concepts and semantics in your systems language (closures, concurrency primitives, garbage collection) just gets in the way, because you have to find out how to map between the two. C's lack of features is actually a strength in this regard.
I do really like Rust's expressiveness though. The pattern matching is particularly nice, and that is an example of a features that wouldn't "get in the way" if you're trying to bind to higher-level languages.
Also, just as a gut-level reaction I didn't feel excited about any of the expressiveness that Go offers (compared with my reaction to Rust's pattern matching, which to me is a clear improvement over how you'd express an equivalent thing in C or C++).
Not quite, the Go implementation has runtime optimizations so that the cost for using interfaces/generics is incurred once at first use: http://research.swtch.com/2009/12/go-data-structures-interfa...
Go has no built in answer to generics. Trying to rebuild generics with other language features won't make it better.
> Because the conversion is dynamic, it may be used to implement generic programming similar to templates in C++. This is done by manipulating values of the minimal interface.
I thought they were saying this was their answer to generic programming, but it appears this is not the case. In any case, it was just an example of my general feeling that the type system is more dynamic than I prefer for systems languages.
- The discussion is about an at-least-partially-competing/similar language. Thus, it's relevant.
Let me ask you a question or two: is there anything at all that makes it possible to interface D with Python? I'm aware of PyD [1] but it looks like it only worked with D1.
If I wanted to stick with D and Python, would it be the case that I'd have to (re-)write something like PyD from scratch, or is there a simpler approach?
I particularly like the natives and testing support, but I agree with what you said; I wish there was a way (maybe there is and I just haven't figured it out yet) to do a reverse native thing; that is, create a C wrapper around a rust library (and then yes, use SWIG to generate a python / ruby / etc. binding for the rust library).
The answer, unhelpfully, is that so far the only significant rust program is its own compiler.
There's people who want to experiment with writing new browser stuff in it. Not sure how serious that is, and I bet it's pretty far off before you see Firefox shipping with Rust code.
But my project is a library whose functionality I want to expose to any language that cares to write wrappers for it. Reimplementing libraries in every language is a waste of effort and will have worse performance than sharing a single C library across many languages.
http://www.aminutewithbrendan.com/pages/20101206
"With Rust, what Graydon has been trying to do is focus on safety and also on you could say concurrency -- the actor model which I've spoken about recently - and the two are related in subtle ways."
It may be that Rust is being designed as if that were a goal, but let's not start any rumors here.
Of course, if it turns out to work amazingly well and they can port all their old code (or interface with it) with relative ease, there's no reason not to jump ship from the hellfires of C++ compilation. They've had major issues with that lately, after all.
http://smallcultfollowing.com/babysteps/blog/2011/12/16/impl...
In particular:
1. The compiler can detect when a value is no longer "owned" (referenced) by anything and free it automatically -- without garbage collection. That's really handy for things like closures where the compiler automatically allocated the memory for you in the first place.
2. If an immutable value is modified then a copy usually needs to be made. But if the immutable value is uniquely-referenced then the compiler can reuse the old bit of memory, thereby saving a copy operation. It can do this because it can prove the old memory can no longer be accessed.
3. I think Rust might also use uniqueness when sending values between its tasks. Since it can prove the value will no longer be referenced by the old task the compiler can avoid copying the values while still preserving isolation.
AFAIK Google Groups don't even support threads
https and http links should be treated the same for de-duplication purposes, although this thread has a few more links, and points.
Is an invalid URL. You put the period inside the last </a>. You should toss that out :)
https://mail.mozilla.org/pipermail/rust-dev/2011-December/00...
and here's the source code on GitHub:
I would love to have that in a language (as long as the 'mutable' keyword was something shorter :-).
That's one thing I really like, actually: use of mutable structures should be avoided, making mutable structures harder to use (because they require a pretty long extra keyword) is a good way to drive developers towards immutable equivalents. See it as shifting incentives.
If you want the language to be actually liked by people who develop large systems, it must be designed with its users in mind. 'Nanny' languages tend not to be very popular.
In C++ "reinterpret_cast" is a good example of something that is long and ugly for a reason. But it's also be very rare, probably an order of magnitude or two more rare than mutable in Rust (just a guess).
So what?
> If you want the language to be actually liked by people who develop large systems, it must be designed with its users in mind.
Which does not prevent the language from driving users towards a goal. One of Rust's goal is emphasizing immutable structures, that's #8 on the front page of its website:
> immutable by default, mutability is the special case
mutability is the special case and a special case Rust tries to make people avoid.
> In C++ "reinterpret_cast" is a good example of something that is long and ugly for a reason. But it's also be very rare
And so ought mutable structures be in Rust.
So many languages seem to be aiming at targets that are pretty far away from the major pain points for the normal developer.
Profiling and instrumentation are possible using the standard tools (xperf, Instruments/DTrace, perf/oprofile). Rust works just fine with those.
Not sure what you mean by "round-trip back and forth between compiled code and commented parse trees", but Rust contains a pretty-printer which preserves comments.
* Why was fn foo(bar: int) -> int chosen and not fn foo(bar:int): int? * Why annotations within comments? Annotations aren't comments it smells of C bolt-on. Why not keyword annotations?
fn (x:int) -> fn@(y:int, z:int) -> int
fn foo(bar: fn(baz: int) -> int) -> int
Instead of
fn foo(bar: fn(baz: int) : int) : int
What I want are tools that help manage the complexity of unit testing, built-in where it makes sense. For example, creating mock objects and ensuring they are reflective of what they are mocking is difficult. Imagine if you could take the built-in asserts and the unit-tests for a component and use them (or some tagged subset of them) as a spec. for automatically creating mocks. Imagine if determining unit-test coverage and which tests should be run based on code changes was automatic and trivial. Etc.
Certainly profiling can be performed on any binaries provided you have symbols for them, but is that really the best we can do? I have a hard time believing that adding support for instrumented binaries at the compiler level isn't a good idea.
What I mean by "round-trip between code and parse trees" is the ability to have easy access to parse tree structure either in code or to external tools. So that you can do things like easily build in refactoring support to IDEs, or to more intelligently merge code changes at a higher level than merely lines of text in a file.
Of course, none of these ideas are anywhere near fully baked, they would require research, experimentation, and a lot of hard work. But I'd rather see people pushing the boundaries of programming languages with novel research rather than just throwing yet another mashup of already existing features out into the wilds in hopes it'll survive.
Take a look at rustdoc, for instance:
Why have first-class unit tests when they could be built on top of some other feature? If tests are part of the language, then using a different testing system (say something in the style of QuickCheck) would probably be at a disadvantage; if you have a language that can support expressive testing as a library, then it would be possible to add different styles of testing.
Edit: Actually, I was thinking of a different talk. Or maybe just a random quote I saw somewhere. This talk is still very interesting.
Rust offers better control over memory layout, more predictable resource usage and a fuller concurrency model. If it works out it will be a good replacement for ocaml, especially for systems development.
Edit: Apparently there is http://www.rust-lang.org/
You mean like choosing a name that is easy to search on the internet?
g++ 4.4 or clang++ 3.x
python 2.6 or later
perl 5.0 or later
Guess they expect all platforms to have Perl and Python these days..
Also, you left rustc off the list of languages required to compile rust. :-) It's self-hosted.
Tutorial (probably better at the moment): http://doc.rust-lang.org/doc/tutorial.html
The friendlier language tutorial: http://doc.rust-lang.org/doc/tutorial.html
Lots of people probably don't like rewriting code bases wholesale and new languages take a while to become trusted.
Backwards-compatibility is held extremely dear to the C community, with those few breaking changes being simple (usually) to work around. If you want to break compatibility, you have a better chance calling it a new language.
The current approaches of "leave the things substantiatlly unchanged" and "release a bunch of changes all together" have not exactly been proven "the best".
Bonus points for real world examples.
That's the use case. Rust is intended as a safe language for building a research browser that works in parallel.
I am always amazed that no valid discussion/comparison of those languages and Ada erupt in these threads :( Ada is not as bad as it's painted to be.