

New Rust runtime turned on. What next? - usea
https://mail.mozilla.org/pipermail/rust-dev/2013-August/005158.html

======
pshc
Excerpt from Graydon's (BDFL) reply:

    
    
      > Despite all these caveats I have a very strong sense that writing the
      > runtime in Rust will go a long way to validate Rust in the domains it's
      > aiming for: concurrent and systems programming. Even in the task
      > scheduler, where there's quite a bit of unsafe code, the shared-nothing
      > nature of unique types forces you to consciously break the type system
      > to share memory, and that seems to go a long way to making parallel
      > programming easier to reason about.
    
      Yes, even just reading it seems much clearer since the mutability, 
      lifetime and ownership of each value and reference is spelled out, not 
      just "some Foo* that you have to remember special validity rules about". 
      It's noticeably easier to reason about. Really interesting!
    

When Rust matures (and this dogfooding-via-self-bootstrap is going to
accelerate its maturation) it's going to be seriously revolutionary for, for
example, modern multi-core video game development. Really excited.

~~~
krichman
I, too, think Rust is going to be revolutionary in the video game industry.
Were I a game programmer I would start learning now. In two years at least 51%
of all new video game code will be in Rust.

~~~
usea
I think you may be overestimating the pace of change. C++ is quite entrenched
for industrial-strength game projects. The network effect is strong, the
tooling is mature, and the projects are largely driven by C++ experts. Even if
we see Rust 1.0 by the end of the year, it will take a lot of time for that
kind of change to occur in the industry, if it ever does.

I think you're much more likely to see 51% of new game code written in C# for
Unity. I think the median game budget is shrinking. More and more games are
being made as small projects by small teams. Steam greenlight, kickstarter,
humble bundle, and other avenues are enabling curation and funding of smaller
games. Unity is far more suited for this kind of development than C++. If you
look at smaller studios' job listings, a lot of them prefer experience with
Unity. The trend is in full swing at this point.

I have no sources to site for the above information. Take it with a grain of
salt.

~~~
jzelinskie
In addition to your point, I'd like to stress that it is the game engines that
are C++. Many engines provide a higher level interface for developers actually
make games. You probably won't hook the game developers on Rust. If you want
to pitch Rust to the engine guys, you're going to be battling against their
toolchains that have been developed for decades and have some of the best
static analysis tools under the sun. Not to mention, you'll also be battling
against the traction of their current codebase, which they'll probably
hesitant to rewrite in a new language. From a business perspective, I don't
think management in some of the larger companies would let that decision fly,
either.

~~~
pcwalton
This is a specific instance of a general argument that applies to all new
languages: there is an existing infrastructure and people won't want to
switch. Yet new languages are arriving at a pace faster than ever on the
server side, despite massive investment in server stacks for existing
languages.

If Rust succeeds as a language suitable for games and gains traction there
(and that is of course an if), I think the truth will be in the middle: there
will be a huge amount of code still written in C++, and that will continue to
be maintained and work. But new code might be written in Rust. Rust is
designed to integrate well with C and C++ code, so mixed projects are quite
feasible: in fact, both rustc (because of LLVM) and Servo (because of
SpiderMonkey) are such mixed projects.

~~~
jzelinskie
Eventually something will indeed replace C++ for gaming. You can look at the
emergence of all the new server side languages in two ways: either one will
"come out on top" as something akin to what C/C++ is now or there will be much
more specialization in what we now call "systems programming". If the future
is the latter, engines might always be done in C/C++ simply because it gives
them the ability to easily make bindings to the majority of languages (ie
Rust). I believe this will be the middle ground of which you speak. It really
would've been cooler if there was more incentive to build languages specially
for games, especially since the domain has some interesting demands such as
the close coordination with GPUs and memory allocation in general.

~~~
kibwen

      > engines might always be done in C/C++ simply because it 
      > gives them the ability to easily make bindings to the 
      > majority of languages
    

Just like C++, it will be possible to expose a C-compatible interface to Rust
code that will allow any language that can call into C to call into a library
written in Rust. See [http://brson.github.io/2013/03/10/embedding-rust-in-
ruby/](http://brson.github.io/2013/03/10/embedding-rust-in-ruby/) for a rather
dated proof-of-concept, or
[http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust...](http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c.html)
for something more recent.

~~~
jzelinskie
Didn't realize Rust had support for this. At the end of your recent example,
it pretty much says doing so sacrifices the runtime entirely. I know Go
doesn't support calling from C for reasons similar to this. Where does further
development on this functionality sit on the priorities list for Rust?

~~~
pcwalton
You don't actually have to sacrifice the runtime entirely anymore; since the
runtime is written in Rust you can just start it manually if you want. Making
this smoother is a priority. (Brian mentions this in the email, regarding
#[start].)

~~~
jzelinskie
That's very cool. I definitely need to check out things out. Thanks everyone
for the interesting discussion.

------
Dn_Ab
I haven't written anything in Rust yet but one of its most interesting aspects
is its support for linear types. I expect that will share the same kind of
perspective enriching attribute of learning logic, array or functional
paradigms. While it's certainly not the first language to support
substructural types, it looks the only one with a decent chance of developing
a meaningful ecosystem.

 _The linear logic of J.-Y. Girard suggests a new type system for functional
languages, one which supports operations that ``change the world ''. Values
belonging to a linear type must be used exactly once: like the world, they
cannot be duplicated or destroyed. Such values require no reference counting
or garbage collection, and safely admit destructive array update_

[http://homepages.inf.ed.ac.uk/wadler/topics/linear-
logic.htm...](http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.html)

An interesting bit of trivia about linear types is they are in some sense the
closest thing to programming a quantum computer this side of qubits (where no
cloning dictates qubit variables can only be used once in a function term).

~~~
oconnor0
I believe Clean also uses linear types.

------
roryokane
Here’s a properly formatted version of the link:
[https://gist.github.com/roryokane/6189765](https://gist.github.com/roryokane/6189765)

(The original message is in Markdown; I just put it in a Gist where it would
be rendered as such.)

------
dkhenry
I am no language designer, but I wonder why use libuv and have to worry about
implementing a scheduler and all the other components of a run time loop in
your language when the kernel will do this for you. I think it would make more
sense to provide a better interface to existing kernel structures then
leverage a third party library and then re implement kernel functions around
it ( I am mainly thinking about the paragraph about the current scheduler
implementation and how basic it is )

~~~
srisa
What if someone wants to write a kernel with Rust? This might be a very naive
question taking into account my ignorance of language and kernel design.

~~~
marijn
Look at
[https://github.com/pcwalton/zero.rs](https://github.com/pcwalton/zero.rs) .
It's not very far yet, but it proves that it is viable to run Rust without a
runtime.

~~~
kibwen
I actually don't think we even need zero.rs anymore. Its purpose was to
provide noop implementations for all the "lang items" that the compiler
expects to find in the stdlib. However, post-0.7 the compiler no longer
requires a lang item to be provided unless you actually use a feature that
requires it.

For an example, see the code at [https://github.com/doublec/rust-from-c-
example](https://github.com/doublec/rust-from-c-example) , which is fully
runtimeless.

~~~
dbaupp
zero.rs (or something like it) is still required, because there's certain lang
items that are required/useful (e.g. #[start], destructors, failure, vector
bounds checks).

(e.g. [https://github.com/huonw/rust-
malloc/blob/master/zero.rs](https://github.com/huonw/rust-
malloc/blob/master/zero.rs))

------
pkulak
> it does implement TCP and UDP on both IPv4 and IPv6

I thought this sort of thing was usually handled by the OS. Can you even get
raw sockets on most systems? Or by "implemented TCP", do they mean they can
give you back a Unix TCP/UDP socket?

~~~
pcwalton
By "implement" it means "integrated into the scheduler".

------
andrewflnr
I really wish I had space in my TODO list to start a project in Rust. I don't
think there's another dev tool I'm more excited about.

~~~
tyleregeto
I'm feeling the same way, Rust looks fantastic. There are a few things in the
language I'm not huge fan of, I don't like overly subtle things in a language.
For example, some of the functionality around semi colons seem like they will
be a common source of stupid programmer bugs that are difficult to track down.
Perhaps the compiler will catch that stuff.

Go kinda ruined other languages for me with multiple return values, its
something I miss when working in every other language now. And reading through
the docs I keep hoping I would stumble across that, though that would create a
lot of problems when interfacing with C. Type inference is a huge win,
standard libraries looks solid, love the potential around marking variables as
mutable, and any language that has no null values makes me happy.

Overall, I wish I had more time too.

~~~
pitterpatter
Multiple return values is possible with n-tuples.

    
    
      fn addsub(a: int, b: int) -> (int, int) {
          (a + b, a - b)
      }
    
      ...
    
      let (a, b) = addsub(32, 44);

~~~
kibwen
Indeed, the behavior described here is just a consequence of allowing pattern-
matching when assigning variables. Say you wanted to do the Python trick of
swapping two values:

    
    
        let a = 1;
        let b = 9;
        let (b, a) = (a, b);
        printf!("a: %i, b: %i", a, b);  // a: 9, b: 1
    

...or say you just wanted to grab a single item out of a tuple:

    
    
        let x = (1, 2);
        let (_, y) = x;  // the underscore is the pattern for "ignore this"
        printf!("y: %i", y);  // y: 2

~~~
copx
Just for comparison:

    
    
      b, a = a, b 
    

is actually valid code in Lua (and works as expected).

Grabbing only one value looks like this

    
    
      _, y = returnsTwoValues() -- grab only the second 
    
      y = returnsTwoValues() -- grab only the first

~~~
jfarmer
This works similarly in Ruby:

    
    
        a,_ = two_values()
        _,b = two_values()

------
masklinn
> tasks are now migrated across threads by the scheduler, whereas in the old
> scheduler a single task was always run in the same thread.

Is that done by having a single task queue with multiple schedulers, or
through work-stealing by schedulers with no ready tasks in their queue?

Would this open the possibility of configuring schedulers (including
individually)? E.g. ensuring a given task stays pinned on a specific
scheduler, and said scheduler accepts no more task, that kind of things?

~~~
smosher
> Would this open the possibility of configuring schedulers ...

I've been assured that it's the plan. I have no idea how much of it works
right now though. I've only done one build with the new rt and it doesn't
involve tasks.

~~~
masklinn
> I've been assured that it's the plan.

Excellent [twirls mustache]

> I have no idea how much of it works right now though.

Yeah I don't expect it to work at this point, but knowing it's one of the end-
goals is good.

------
batgaijin
So they are still using libuv after the rewrite?

~~~
pcwalton
Yes (as the Windows IOCP support is invaluable). But we will probably need to
add threading support to it.

~~~
fzzzy
What do you mean add threading support? Last time I used libev (I thought
libuv was just libev plus Windows) it allowed creating multiple loops for use
in multiple threads just fine. Do you mean adding the ability to move file
descriptors across threads into another loop?

~~~
kaeso
As a sidenote, libuv is not using libev anymore

[https://github.com/joyent/libuv/issues/485](https://github.com/joyent/libuv/issues/485)

~~~
fzzzy
Interesting, thanks!

------
btipling
I tried to give Rust a try to build some stuff but my project required HTTP
and there's no easy SSL solution in place right now. Hope it comes along. I
don't have time to contribute much otherwise I would.

~~~
kibwen
To quote Brian Anderson (the OP), one of the next steps in the I/O rewrite is
"Implementing a new HTTP client on top of rt::io, possibly using Chris
Morgan's HTTP code, for use in Servo". So hopefully within the year we'll see
the beginnings of a robust HTTP lib that's worthy of a Mozilla-brand browser
engine.

~~~
chrismorgan
Note that that is HTTP; SSL will be likely to come quite a bit further down
the track.

