
Announcing Rust 1.0-alpha2 - steveklabnik
http://blog.rust-lang.org/2015/02/20/Rust-1.0-alpha2.html
======
kibwen
I haven't had much time in the past month to help out with Rust, but I'm
excited at how things are proceeding. Conceiving, proposing, and implementing
I/O reform in the span of a single six-week alpha cycle is very impressive, to
say nothing of the sea of tweaks and refinements that have appeared in the
same period. That said, I see this as basically just a "heads down, working
furiously, nothing-to-see-here" release... six weeks from now is when the real
action starts. :)

~~~
steveklabnik
Not to rain on our parade, but IO reform discussion started in the middle of
last December, so it's been longer than that.

------
doe88
I must say what worry me the most is what happens once 1.0 is shipped in term
of language changes and compatibility with previous versions. Because I've
observed and of course I understand the huge amount of changes the language
has undertaken until now, but I must say I worry it will continue at this pace
right after 1.0.

Currently, I'm on the verge of choosing the language I will choose for an
important project I'm about to start, I have a good knowledge of Rust and I
think it's a great language, but despite all of this I think I will pass on
Rust for this project because I'm not sure I'm ready / be able to keep-up with
this level of changes.

~~~
pcwalton
Rust 1.0 will be stable and will cease making breaking changes.

~~~
alexkcd
Personally, I prefer languages that make small incremental breaking changes,
as it prevents cruft from accumulating over time.

The important thing is to provide a migration path (e.g., begin by marking
something as deprecated). Then provide refactoring tools to help migrate or
interface with legacy code.

I think C++ would have been much better off had it been willing to do this.
Paraphrasing Stroustrup: C++11 has within it a smaller more elegant language
that's trying to break free.

~~~
static_noise
Being able to run old legacy code is one of the most important arguments for
C++. Every new feature is add-on (not "upgrade" and not "migration").

At the fast pace things develop for Rust I hope that the language will have a
good way to handle Rust 2.0 code together with Rust 1.x code. IMHO providing
practical tools for an upgrade path is something that should be thought of
before releasing 1.0.

~~~
alexkcd
Objective-C is a good example of successfully migrating the language forward.
Breaking changes were introduced slowly. Library APIs are marked as deprecated
several releases prior to removal. The compiler warns you of their use.
Automatic reference counting can be turned off for legacy files, but a tool is
provided that will help you convert a class to use ARC.

Code written in ObjC a couple of years ago will likely not run today without
modifications. But overall this has been a net positive for the language. It's
actually become really pleasant to use. And is in part why Apple's platform
has thrived.

I think optimizing for the past is the wrong thing to do. If your language is
successful, then most of the code is yet to be written. So if your choice is
between making future code easy to write, or not breaking legacy code, then
you should err on breaking legacy code and provide deprecation/migration
tools.

~~~
pjmlp
I wouldn't use Objective-C as success for anything, given that it is
unavoidable in the Mac platform.

------
snissn
Awesome, with their announcement that "all major API revisions are finished"
this seems like the turning point where I will finally invest my time into
thoroughly learning the language! I'm really excited!

------
14e3d901150a21d
I was hoping that the prelude would re-export the new io/path modules, but it
looks like old_io and old_path are still exported.

Regardless, great work. Rust seems rather promising.

------
knocte
What's up with the "pure" keyword? Has someone managed to work on this area so
that the default is pure, and the opt-in keyword is "impure" instead?

~~~
comex
Rust doesn't currently enforce pure functions at all; there is no 'pure'
keyword. Here is an old mailing list post related to this decision - note that
because it is 2 years old and Rust has been in a state of constant flux for
most of that time, it may not fully reflect current thinking.

[https://mail.mozilla.org/pipermail/rust-
dev/2013-January/002...](https://mail.mozilla.org/pipermail/rust-
dev/2013-January/002903.html)

------
parley
Steve: Perusing or pursuing the trifecta? =o)

~~~
steveklabnik
I always friggin' do this, it's one of those typos I perpetually make :(

Care to make a PR so you get a commit credit, or should I just fix it? rust-
lang/blog.rust-lang.org is the repo.

~~~
parley
It's fine, go ahead and fix it. And thanks for your hard work on Rust! =o)

~~~
steveklabnik
Done: [https://github.com/rust-lang/blog.rust-
lang.org/pull/28](https://github.com/rust-lang/blog.rust-lang.org/pull/28)

And you're very welcome. I couldn't do it without Mozilla paying my bills,
though I hope to strike out on my own later in the year.

------
IsTom
I tried rust, I tried honestly, but it's just enraging when you can't just
write:

    
    
      let x = ys.filter(|y| self.p(y));
      self.z = x;

------
knocte
I've recently attended a conference where they gave a D talk, and almost
immediately after a Rust talk.

This let me compare these two interesting languages in a quite detailed way.

While Rust seems to be more safe in terms of trying to prevent as much as it
can that you shoot yourself in the foot, it can be understood that the way to
achieve this is maybe too extreme. I've read that programmers new to this
language invariable struggle with lifetime issues that the compiler keeps
arising.

I'm sure this is a good thing. But I'm not sure the ways to fix those issues,
at least in a number of examples I've seen, are pretty. Most of them involved
abusing the "*" and "&" symbols, which put you in a territory in which you
seem to be dealing with pointer arithmetic again like in low-level C,
something which I thought Rust was trying to escape from.

One thing I really liked about D is the string mixins, which could allow for
what has become common these days in F#: type generation at compile time
(which at the end of the day allow you to, for example, parse XML or JSON with
static APIs, hence allowing intellisense/codeCompletion/youNameIt).

I'm really excited about what these kind of high&low (hybrid) level languages
will allow. I hope they get into mainstream soon, and surpass other less
interesting (but trendy) ones like Go.

~~~
pcwalton
> Most of them involved abusing the "∗" and "&" symbols, which put you in a
> territory in which you seem to be dealing with pointer arithmetic again like
> in low-level C, something which I thought Rust was trying to escape from.

First off, Rust doesn't have pointer arithmetic.

Moreover, though, Rust is not trying to "escape from" pointers in C and C++;
it's a manually memory-managed language, not a garbage-collected one. For
Rust's domain (systems programming without automated memory management),
learning about pointers is a necessity. What Rust saves you from is making
dangerous _mistakes_ with memory management.

> One thing I really liked about D is the string mixins, which could allow for
> what has become common these days in F#: type generation at compile time
> (which at the end of the day allow you to, for example, parse XML or JSON
> with static APIs, hence allowing intellisense/codeCompletion/youNameIt).

Rust has macros and compiler plugins, which allow you to do the same thing.

~~~
knocte
>First off, Rust doesn't have pointer arithmetic.

It should have avoided the "*" and "&" symbols then, IMNSHO.

C# does this partially by using the "ref" keyword.

~~~
pcwalton
> It should have avoided the "∗" and "&" symbols then, IMNSHO.

Those operators aren't for pointer arithmetic…

> C# does this partially by using the "ref" keyword.

But C#'s reference parameters have no corresponding dereference operator,
because they aren't first class and are limited to function parameters. As a
result, most programs cannot be written without using the garbage collector in
C#. In Rust, however, references can appear as first-class values, which makes
them much more flexible—enough to supplant a garbage collector when combined
with smart pointers—but requires that you annotate where they are created. `&`
and `*` are well-known operators for this.

~~~
knocte
> Those operators aren't for pointer arithmetic…

That's the point of my suggestion! One looking at them will think they are
pointer arithmetic, which is not pretty for newcomers.

~~~
pcwalton
Those operators aren't for pointer arithmetic in _any_ language I know of,
including Rust, C, C++, or Go. The operators for pointer arithmetic are plus
and minus (technically square brackets too in C)--that's why it's called
pointer arithmetic.

~~~
knocte
Ok sorry, I misused the term "pointer arithmetic" then. I think I was
referring to memory indirection and the like. I find "ref" and "->" less
cryptic than "&" and "*".

~~~
rayiner
You can have pointers and memory indirection without being able to do
arithmetic on pointers.

