
Rust Priorities after 1.0 - doublextremevil
http://internals.rust-lang.org/t/priorities-after-1-0/1901
======
kibwen
I think one thing that we need to emphasize is that Rust 1.0 does _not_
indicate that we think the language is "complete". It is merely the result of
recognition that _getting_ to that "complete" state can, as of very soon, be
done in a stable and backwards-compatible fashion. I expect the post-1.0
releases to see a flurry of activity as we flesh out deficiencies in existing
features and add new features to address pain points, but over time the rate
of feature growth will slow. Rust has no intention of becoming a ball-of-mud
programming language.

~~~
mook
Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of
the FAQs, so:

How long do you (the Rust community) expect Rust to remain backwards-
compatible? That is, once 1.0 ships, on what sort of approximate timescale
would significant effort be made to ensure code that worked with the initial
release (assuming no experimental features / libraries in use) would keep
working? On the order of months, years, decades?

I'm interested in writing some random things in Rust, but very much not
interested in _re_writing Rust code in newer Rust. This probably means it's
still too early for me, if the standard library is expected to expand soon
after 1.0. But given e.g. the prevalence of Python 2 versus Python 3, it seems
like there's quite a lot of people who think similarly.

Background: I used to write Firefox extensions and things like that. Stopped
being active around Firefox 4, when they declared that they are fine with
breaking backwards API compatibility (and, IIRC around that time or soon
after, put in arbitrary checks to force recompilation). This was just before
the short releases started.

~~~
Manishearth
> How long do you (the Rust community) expect Rust to remain backwards-
> compatible?

The hope is for all of 1.*. I forget what the plan is for 2.0, but I think we
want to keep things the same (mostly).

In practice there will be minor breakages due to unavoidable bugfixes.

Expanding the stdlib will never break your code. All changes now are being
made with backcompat in mind; older code should never have to update.

~~~
mook
> The hope is for all of 1. _. I forget what the plan is for 2.0, but I think
> we want to keep things the same (mostly).

Right, but how long is that 1._? 2.0 is a good time to have (hopefully small)
backwards compatibility breaks, so having a rough idea of an order of
magnitude of the timespan would be helpful.

> Expanding the stdlib will never break your code. But having it obsolete the
> non-standard libraries (from e.g. crates.io) will. Code is, unfortunately,
> not static; things suffer from bitrot, as the toolchain etc. changes.

------
Animats
From the proposals: _" Perhaps the biggest is the lack of "privacy" or
"unsafety" hygiene (meaning that it's not possible to define macros that have
privileged access over normal code). This prevents macros from being used to
define abstraction barriers."_

That may be a misfeature. One would like to reduce the need for unsafe code,
not make it easier to write unsafe code. Unless you're talking to hardware or
another language, you should not need unsafe code. If you do, the language has
a problem. I'd suggest identifying each use of unsafe code in a large system
and then looking at why it was necessary.

It's important to keep Rust from going off into template la-la land, as C++
did. C++ generics are starting out with roughly the complexity level it took
C++ two decades to achieve. Try to keep the metaprogramming fanatics from
driving the language design, please. That doesn't end well.

~~~
taliesinb
> Unless you're talking to hardware or another language, you should not need
> unsafe code.

... or if you're implementing safe abstractions on top of data structures or
synchronization protocols that the type system cannot automatically infer to
be safe.

Of course that is going to be a smallish subset of Rust programmers that gets
smaller with time as the standard library fills out, but an important one!

For those who aren't as familiar with Rust, the std::sync [0] module can be a
fun way to cut your teeth.

For example, here's the implementation of Mutex.lock [1]:

    
    
       pub fn lock(&self) -> LockResult<MutexGuard<T>> {
            unsafe { self.inner.lock.lock() }
            MutexGuard::new(&*self.inner, &self.data)
        }
    

Note that the self argument is immutable: "&self" instead of "&mut self". This
may seem odd: doesn't locking a mutex _require_ a change to its innards? Which
is why you should not be surprised to see the unsafe, which allows us to bend
the immutability of &self in order to acquire the lock.

In fact, how could it be otherwise? Rust prevents there ever being more than
one &mut to something, so if the signature of Mutex::lock was "&mut self",
there could only ever be one usable ref to the Mutex! That would be pointless,
of course -- multiple threads need to have references to the mutex.

We're still safe, though, because the "mut-aliasing" that Rust normally
prevents via the borrow checker at compile time is being replaced with a run-
time mechanism that achieves the same thing via the Mutex and the MutexGuard
[2].

[0] [http://doc.rust-lang.org/std/sync/index.html](http://doc.rust-
lang.org/std/sync/index.html)

[1] [http://doc.rust-
lang.org/src/std/sync/mutex.rs.html#196-211](http://doc.rust-
lang.org/src/std/sync/mutex.rs.html#196-211)

[2] Well, strictly speaking a RwLock is a closer runtime approximation to the
borrow checker's rules, because it allows multiple simultaneous readers:
[http://doc.rust-lang.org/std/sync/struct.RwLock.html](http://doc.rust-
lang.org/std/sync/struct.RwLock.html)

~~~
kibwen
Rust's own Aaron Turon put this nicely in a recent talk at Stanford. A data
race requires all of the following: aliasing, mutation, and a lack of
synchronization. Rust's usual ownership rules already make aliasing exclusive
with mutation, so out of the box you're safe. But when simultaneous aliasing
and mutation is exactly what you want, as in a mutex, it's safe to subvert the
type system as long as you make sure to uphold the synchronization aspect on
your own (which Rust nicely helps with by leveraging ownership on the
synchronization mechanism itself).

[https://www.youtube.com/watch?v=O5vzLKg7y-k&t=31m00s](https://www.youtube.com/watch?v=O5vzLKg7y-k&t=31m00s)

~~~
Animats
I was at that talk.

In a sense, what you need there is not "unsafe", but "atomic", declaring that
the contained operation is atomic. That's less general than "unsafe", and
atomicity of code is checkable.

------
LVB
I really wish better Windows support was available now. Solid cross-platform
support has allowed me to move some Python code to go. My attempts to do the
same with Rust have been failures, on multiple occasions, but as recently as
their 1.0 beta and nightlies (both 32/64 bit were tried).

After giving it a few hours with the IRC channel riding shotgun and
hello_world.rs still crashing on Windows, I've again hit snooze of Rust. A
pity too... I am quite re-interested after seeing some Rust demos/discussion
at PyCon.

~~~
unethical_ban
"cargo new helloworld ; cargo run" doesn't work for you in Windows?

I did some REALLY REALLY MINOR code in Windows before doing it on Ubuntu, and
I had no issues dependent on OS.

~~~
kibwen
I'm guessing that the parent poster was trying to do a "hello world"
equivalent of calling Rust from Python (as per the Pycon presentation), which
would definitely cause grief on Windows if Python isn't compiled with the same
toolchain that Rust is.

~~~
sinistersnare
I just gave a presentation on Rust + Python at a local meetup, and I have been
constrained to windows only for the past few months.

Have had 0 issues, and I have no idea what the fuss with windows is about. 0
ICEs nowadays, and it works like a champ speedwise (obviously)

Compared to Ruby, Rust is basically C#, windows wise. In the past I have
gotten ICEs and shit, but nowadays its perfect.

------
rck
Does "ARM support" include bare-metal arm at all? I know there are several
projects that move in that direction, but it's not obvious to me how mature
they are relative to the rest of Rust (granting that everything in the
ecosystem is in an early state)...

~~~
kibwen
Rust exists to support Servo, and Servo's most important platform may very
well be Android. I expect that Rust will see a lot of interest by hobbyists
who hack the compiler to work with various fringe platforms, but in terms of
official support I wouldn't expect Mozilla and Samsung to contribute anything
beyond what's required for Android.

~~~
shmerl
I hope Servo will be important for non Android mobile Linux as well.

~~~
sinistersnare
Rust builds for straight up ARM, see [https://zinc.rs/](https://zinc.rs/)

Now we only need to dependencies for Servo to move along and it could work. I
would imagine this would be a lot of work for the OpenGL implementation they
use.

~~~
shmerl
I should try building Rust with Mer SDK. Would be useful for Nemo, Sailfish
and Plasma Active. Weren't Samsung also working on Servo? Did they consider it
for Tizen as well?

------
amelius
I wonder if Rust would support something like the following. Say, I have a
mmapped file, and in this file I'd like to store data-structures such as maps,
sets, lists, etc. Basically, they are the same data-structures as one would
use on the heap. Because the mmapped file is offsetted at a different point in
memory every time it is opened, the actual pointers used to access these data-
structures will be different every time. But the pointers _inside_ the data-
structures will be the same every time the file is mmapped. So, this requires
some special pointer arithmetic (and perhaps a special type system). It would
definitely be a very interesting and useful feature!

------
hanlec
After using Go for a couple of pet projects in the last couple of months, I
came out bored. Many people seem to be quite excited about Rust. I'm setting
up my (new) Emacs end for Rust.

Any cool projects I can take a look at?

~~~
andrewchambers
The problem with rust is that it has been around for nearly as long as Go, yet
is nowhere near stable or production ready in nearly every aspect.

Go has been ready for years.

~~~
oldmanjay
of course, if you're interested in rust's memory safety, performance, low-
level control, and expressive type system, then in a very real way, go isn't
ready at all.

it does have some marquee names behind it, though. I suppose if you squint,
that can make up the difference.

~~~
andrewchambers
Go performance is going to converge on C performance with new optimization's
being written after go 1.5.

Any gains from rusts expressive type system are lost by all the memory
lifetime annotations imo.

I still think rust is probably going to be the best language for embedded
software like router firmware, as they need to be fast, low overhead and
secure.

~~~
seanmcdirmid
As an upper performance bound for a GC language, I don't think Go will be able
to surpass C# (which has stack allocation in the form of structs, ahead of
time compilation, and many other goodies). Rust, on the other hand, has more
potential as a non GC language, though at the end of the day it might be hard
to tell given equivalent applications.

~~~
andrewchambers
The upper performance for garbage collected languages (and rust) is
potentially higher than C. The reasons are non aliased pointers allow more
aggressive optimization, and batched garbage collection plus memory compaction
can perform better than regular mallocs.

Rust still has these advantages though, time will tell. Does rust have a way
to avoid bounds checks on arrays? I suppose that requires unsafe annotations.

~~~
kibwen
Rust essentially never wastes cycles on bounds checking thanks to the design
of its iterators. The Servo team tells me that bounds checking has never shown
up in any performance profiles.

~~~
higherpurpose
I wonder if after Mozilla writes Servo in Rust 1.x and Google sees how fast
Servo is, even compared to its own JS engine, it will also consider writing a
new JS engine in Rust 2.x (I assume, by then), as I doubt they'd use Go for
that. Same for the whole browsers. Due to the safety features of Rust over C++
we might see both Firefox and Chrome be rewritten in Rust over the next 5
years.

~~~
Ded7xSEoPKYNsDd
Servo isn't a JS engine, it does make use of Firefox' SpiderMonkey, written in
C++.

------
da4c30ff
I wish I could use 'type' as a variable name or as a field on a struct. It's
one of the most used identifier names and the inability to use it is
frustrating.

~~~
heinrich5991
You could sidestep it like Python does, adding an underscore after variables
that are named the same as keywords (e.g. `type_`).

------
aidenn0
I'm glad specialization is listed as a Top Priority; it's something that I've
wanted in Rust for about 2 years nos.

------
thuffy
LOL, the new Godwin's Law: Edward Snowden.

(See my valid but then NSA downvoted answer to the question below regarding GO
vs. Rust that no one else could answer and were forced to make jokes about --
if you are wondering what I mean.)

Sorry rust thread. :(

(now kicked off the front page)

------
choward
For a language that was written by Mozilla, I find it very annoying that they
steal my browser's built-in ctrl+f functionality that I'm perfectly fine with
using. Also, my vimium plugin doesn't work. This is the first time I've
encountered something like this. This better not become a thing.

~~~
kibwen
The forum software has nothing to do with either Rust or Mozilla. It's
Discourse ( [http://www.discourse.org/](http://www.discourse.org/) ), and
personally I agree that it's kind of a pain. :)

~~~
mkesper
Please use something different. Something utterly broken like this (keyboard
navigation?) casts a bad light on a project that's - at least mentally -
connected to Mozilla.

