Rust 0.9 released
mail.mozilla.org
mail.mozilla.org
I just tried it. Only got an error message about a missing GCC component. Seriously, a ~90MB download and that still does not include all the GCC dependencies?
We still have to somehow manually setup a version of MinGW compatible with this particular build? Who is in charge of the Windows port? A Linux user who cross-compiles from an Arch box? No way a Windows user would think that Windows package is acceptable.
I mean, I am not paying anything for it so it is not that I think I have the right to demand better packages but you are losing out on a massive amount of feedback from the Windows world by only offering such downloads.
You are largely limiting yourself to determined people who are already familiar with MinGW-based C/C++ development on Windows (that is a small subset of Windows devs). What about people coming from - say C#? You expect them to fiddle with a MinGW setup just to build "Hello World"?
Sorry, but for me this experiment with Rust ended just like the 0.8 one. Downloaded Windows installer, ran Windows installer, tried to compile Hello World, got error message about missing components, uninstall, delete.
> Wasn't this release supposed to finally offer a Windows
> package which works out-of-the-box?
> Who is in charge of the Windows port?
To clarify, the goal is to be using the native Windows toolchain by 1.0, if at all feasible. Servo has to work on Windows, after all.
It's a very mature toolchain, and has better modern (C++11) support than the version of G++ on my Linux box.
Please keep in mind that I'm not comparing writing C++ programs with MinGW vs. VC++. Rust just needs a linker for some tasks, which should be lightweight.
It may strictly be a larger download than MinGW, but it's certainly less painful and confusing. Sure, Rust may just need a linker, but MinGW is anything but lightweight.
If someone can point me to a list of outstanding issues/requirements and a contact person it'd be much appreciated. Note, I've already found this https://github.com/mozilla/rust/issues/8996 and this https://github.com/mozilla/rust/issues/1237.
I'm assuming the workflow notes at https://github.com/mozilla/rust/wiki/Notes are up to date?
https://mail.mozilla.org/listinfo/rust-dev
HN comments and IRC chats tend to get lost in the shuffle without always attracting the attention of the devs.
When people download an exe installer on Windows, they generally expect it to install something that works out of the box.
Please note that I am not saying it should be expected that there is a one-click (or double- as it were) solution for Windows at this point, I am just saying that people might ge t that impression from the download link on the front page, and the fact that it is an exe installer.
Perhaps if you put it in a zip -- I am sure the people who can find and follow the notes for installing the rest of what is required can handle zip.
[edit] You do need to install gcc in your MinGW, though.
Nope.
>I just tried it. Only got an error message about a missing GCC component. Seriously, a ~90MB download and that still does not include all the GCC dependencies?
Seriously, an early adopter that can't handle GCC dependencies?
>Who is in charge of the Windows port?
YOU are, it's open to the community.
Also, Windows support is definitely a priority: every single proposed patch is tested on Windows (as well as Linux, OSX and one of the BSDs, and soon, Android), and any failures cause a rejection.
I agree.
>Poor Windows support will hurt the adoption of Rust.
I agree again.
Where I disagree is that there's any serious hurry for "it just works" Windows support to exist now, when the language is in flux, the core team has tons of other priorities (like, finalizing the design and creating stuff), and we're several releases away from 1.0.
Where I disagree is that people that try to early adopt a compiler and toolchain at pre-beta stage, have a right to whine about it and demand stuff, or even get to blame developers ("who is responsible for the Windows port?").
Where I disagree with is with entitlement.
>* It shouldn't be up to some vague "community" to seamlessly support Windows. That's something that the core Rust developers should work to offer.*
That's what I disagree with.
The core team has schedules, finite time and priorities. And could even be way over their head with some stuff, like finalising some language semantics.
That some other developers are saddled with a non-UNIX/POSIX OS, doesn't mean the core team must automatically bend over and prioritize them over other stuff. Even if it "hurt Rust adoption".
You know what will hurt Rust adoption more? Spending resources to port a half-finished compiler to various systems, instead of getting it done first.
[NOTE: In no way do I speak FOR the core team or are affiliated with it (other than playing with Rust since 0.3 days as a user). I just wanted to respond to this particular attitude].
1. The (yet-ongoing) removal of managed pointers, leaving us with one fewer pointer type. Final tally of built-in pointer types: unique pointers, mutable references, and immutable references.
2. The dead code detection pass (https://github.com/mozilla/rust/pull/10477), contributed by a student of the University of Virginia's Rust-based systems programming class (http://rust-class.org/pages/using-rust-for-an-undergraduate-...).
3. The `Any` trait, giving us on-demand dynamic typing (https://github.com/mozilla/rust/pull/9967).
4. The clean abstraction of green threads and native threads out into their own libraries (https://mail.mozilla.org/pipermail/rust-dev/2013-December/00...) such that any library that makes use of the stdlib will work regardless of which strategy the user selects.
We're not quite in the home stretch yet, but there are very few hard blockers left on 1.0. Here's the list that I can think of:
1. Dynamically-sized types (http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-...)
2. The extension of rvalue lifetimes (http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...)
3. Struct single (note that's single) inheritance (http://smallcultfollowing.com/babysteps/blog/2013/10/24/sing...)
4. Niceties and sugar to support custom smart pointer types to complete the excision of managed pointers
As far as I know, the devs are still aiming for a 1.0 release in 2014. The 1.0 release will not necessarily mean that the language is done evolving or ready for production use, but it will mean that the developers will begin honoring language-level and library-level backwards compatibility. I would expect at least two more unstable point releases (i.e. 0.10 and 0.11) before a 1.0 release occurs.
Now, some of the syntax for using them might still change. That's yet to be decided. But it wouldn't be Rust without unique pointers.
E.g. the following is almost exactly identical to `~T`
#[unsafe_no_drop_flag]
struct Uniq<T> { priv ptr: *mut T }
impl<T> Uniq<T> {
fn new(value: T) -> Uniq<T> {
unsafe {
let ptr = malloc(size_of::<T>()) as *mut T;
if ptr.is_null() { fail!("malloc failed"); }
move_val_init(&mut *ptr, value);
Uniq { ptr: ptr }
}
}
fn borrow<'a>(&'a self) -> &'a T {
unsafe {&*self.ptr}
}
fn borrow_mut<'a>(&'a mut self) -> &'a mut T {
unsafe {&mut *self.ptr}
}
fn move(mut self) -> T {
unsafe {
let v = ptr::read_ptr(self.ptr as *T);
free(self.ptr);
self.ptr = 0;
v
}
}
}
#[unsafe_destructor]
impl<T> Drop for Uniq<T> {
fn drop(&mut self) {
unsafe {
// this will free the pointer and run the
// destructor of the inner type
replace(self, transmute(0)).move();
}
}
}It's actually not too bad. The biggest problem with the docs currently is that it's a patched-together set of things people have written at random over the last few years. Mozilla has taken some concrete steps to address this, it'll be much better overall soon.
TL;DR: you don't need them as much as you may think, so don't let that scare you away!
Some languages prefer inheritance to express is-a relationships and composition to express has-a relationships. Some languages try to shoe horn is-a into being equivalent to has-a, but they usually have trouble expressing non-structural subtyping.
For the lack of a horseshoe, EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();
(...)
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
The good news is that's an extremely constrained sort of inheritance, very unlike traditional OO in that it doesn't have base classes--it's just a special extension to the trait (typeclass) system that allows you to require that structs begin with a certain set of fields. In fact, I don't even call it inheritance these days--I prefer the name "structural constraints".
[edit, on #rust it was explained to me that its only for pointers to structs, but thats fine by me]
Although with the right language support, it is useless, composition can stand for it (demo: Self)
Say I have an early-generated state tracker for a whole bunch of events propagating in an event loop somewhere, that I want discarded when all the events finish. They are all separate tasks in different threads, so I either need to have some job that just checks if they all finish to clean up, or pass around shared data structures. How would you do that in Rust?
For the example you mentioned, you could have the parent object of those tasks responsible for cleanup of the shared object (e.g. each thread's destructor calls a finish function on the parent object). This is just one possible implementation. I don't encounter this as much because I prefer a shared-nothing approach where possible.
edit:typo
[0] http://static.rust-lang.org/doc/master/extra/arc/struct.Arc.... [1] http://static.rust-lang.org/doc/master/extra/arc/struct.RWAr...
http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...
You might be interested in http://words.steveklabnik.com/rust-is-surprisingly-expressiv... , which is sort of about this.
And because Steve seems reluctant to plug his own book, here's Rust for Rubyists, which is an introduction to Rust geared towards users of higher-level programming languages: http://www.rustforrubyists.com/
From the FAQ on the front page:
Do I have to know Ruby?
Really, I love alliteration: the only thing the 'for Rubyists' really means is that I assume you don't know about pointers, concurrency, or similar things. That's okay, you've never had to think about them before! I explain this stuff in extra depth. If you program in another dynamically typed language, you'll be just fine. If you program in another systems language, you'll be more than fine.
At this stage though, the library support for higher level functions is lacking – mostly due to relative youth of the language. At this stage, you won't find much support for UI code and there's a relatively small number of libraries supporting HTTP servers and services.
You could write bindings for these things yourself (and they'll certainly be written over time) but you won't find it out-of-the-box right now.
However once you've satisfied the compiler, your program often runs perfectly first time (modulo logic bugs, which a compiler can help with (like warning about dead stores, and mutable variables that aren't mutated... which rustc does) but can't detect or fix in general). This is in stark contrast to C/C++ etc where a program normally needs a liberal application of gdb and valgrind to be safe.
Hence: I'd say it's harder to write code but easier to write correct code in Rust.
Will Rust be able to help me write super-efficient web programs, than run blazingly fast and dont gobble-up RAM?
Besides, how painful/easy is string manipulation in Rust?
String manipulation in Rust is currently lacking while we work on the API. We also strictly enforce that all strings are UTF-8, so while this gives us great confidence that we're future-proof it adds a whole lot of difficulty in implementing a fast and correct means to work with strings.
Also, where can I read about the general direction the string manipulation API is going to take?
There's no real documents concerning the future of the string API, right now people are just implementing things as they need them.
If you have a bit more time to spend it's fun, though -- I spent a lot of time in the IRC channel. The people in #rust are really helpful and will answer all your pointer questions.
I'm wondering why they chose NFKC (compatibility composed from) instead of NFC (canonically composed form).
`ª` would become `a`, losing its super type. `ᵤ` becomes `u`, losing its sub type? `Ⓐ` becomes `A`, losing its circle type. As for multi-codepoint mappings, `¼` would become three tokens `1⁄4`, where `⁄` (U+2044) doesn't map to `/` (U+002F).
[1] http://static.rust-lang.org/doc/0.9/rust.html#input-format
The issue 2253 does mention address it, but all the comments mention the issue of NFC/NFKC normalization specifically for filesystem lookup and for program identifiers, but not for the lexing stage. That issue is obviously the best place to continue any conversation about it.
Making a safe programming language that doesn't require GC or a runtime (while allowing allocation) has literally never been done before in industry. It has taken time to get something usable. The current overall design seems pretty workable now, as evidenced by all the projects people are starting to write, so I think it's basically just a matter of finishing off rough edges at this point.
Kinda curious on the do N.times -> for foo in range(0, N) changes. I thought I remember a recent post from you about that. Any reason for the switch? (I ask as someone thats used ruby too much myself and is currently switching cold turkey to plain old C while rust gets a bit more mature)
More seriously, look at the release rate. It's pretty frequent. There's clearly heaps of work going on. It's not a moribund project.
There are some plans related to simplifying how vectors and trait objects ("dynamically sized types" or DST) interact but I don't understand them well enough to be able to explain. :)
http://www.reddit.com/r/rust/comments/1le6vu/i_wrote_a_proto...
As for user-defined operators, if you mean something like Haskell's custom infix operators then no, I don't believe there are any plans for those.
Do the Rust designers actively oppose having them, or just not have any concrete plans to add them?
- It's not necessarily obvious what is an infix operator
- Precedence and associativity
I think Haskell has solved the first one: with all non-alphanumeric symbols in expressions being infix operators, and likewise for alphanumeric functions written with backticks.
But precedence and associativity is not obvious, since that is something that you can customize. I think that user-defined infix operators with some severe limits on choosing precedence and associativity is a good compromise (many use backticks on functions in Haskell, and that has a default precedence).
I think a current version should still be similar, although I haven't had a chance to take a look at the code for 0.9. I also notice that I forgot to update that with the double-dispatch approach.