Rust lightning talk at JavaZone 2012

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Reidar Sollid
Hi,

JavaZone 2012 have accepted my lightning talk on Rust, it is just 10 min so
it is not much time to present Rust

http://javazone.no/incogito10/events/JavaZone%202012/sessions#a8b2bb04-03f2-
4e88-9663-8387692af0e0

I am deffently  doing task, but I need to build up to the tasks.

Any suggestions on what to press in during those 10 min to convince Java
devs that Rust is a great language?

Best regards
Reidar Sollid




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120821/fff6c2f0/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Brian Anderson
On 08/21/2012 10:33 AM, Reidar Sollid wrote:

> Hi,
>
> JavaZone 2012 have accepted my lightning talk on Rust, it is just 10 min
> so it is not much time to present Rust
>
> http://javazone.no/incogito10/events/JavaZone%202012/sessions#a8b2bb04-03f2-4e88-9663-8387692af0e0
>
> I am deffently  doing task, but I need to build up to the tasks.
>
> Any suggestions on what to press in during those 10 min to convince Java
> devs that Rust is a great language?

Hi Reidar,

This is very cool!

I'm not too in-tune with the Java world right now, but here are some
notes comparing Java and Rust.

Two big selling points for a Java programmer are freedom from data races
and control over memory layout, and these are both topics relevant to
introducing Rust tasks.

Java has a complex memory model describing what happens when multiple
threads access shared memory. Rust has no shared memory, no volatile
keyword, no synchronized methods. Synchronization in Rust is almost
always based on message passing instead of locks.

That's not to say that Rust's memory model isn't complex, but it's
complex in entirely different ways. In Rust you have several options on
for where to place objects in memory. If you try you can completely
avoid the garbage collected heap. The Rust division between the GC heap
and the exchange heap is what allows Rust to avoid data races.

Rust and Java share some qualities:

* Safety guarantees - never crash, never write bad memory
* Both allow locals to be declared and assigned in separate statements
while ensuring that they are definitely initialized before use.
* Existential types - Rust traits can be used like Java interfaces by
casting the type to the trait, though this isn't the typical usage
because it involves vtables and is less efficient than using traits to
place bounds on type parameters.

Here are some common Java grips that Rust potentially can do better:

* No data races - there's no complex model describing when variables are
between threads, no volatiles.
* Global GC - Java has notorious stop-the-world GC behavior (though it
is very good). Rust's GC is per-task so when one task is collecting
others continue running in parallel. With care you can in theory write
tasks that never GC.
* Lambda expressions - Rust has a very simple syntax, so Rust code uses
them everywhere, whereas Java needs a lot of ceremony to do function-y
things.

Differences

* Unsafe sublanguage - Rust gives you low level control when you need it
* Control over memory layout - Local heap/echange heap/stack
* Iterators - Rust uses higher-order functions instead of iterator objects
* Expressiveness - Rust code is fairly compact. A determination to avoid
'public static void main' is the biggest influence of Java on Rust.

Good luck with your talk!

Regards,
Brian


Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Graydon Hoare
On 12-08-23 3:48 PM, Brian Anderson wrote:

> Differences
>
> * Unsafe sublanguage - Rust gives you low level control when you need it
> * Control over memory layout - Local heap/echange heap/stack
> * Iterators - Rust uses higher-order functions instead of iterator objects
> * Expressiveness - Rust code is fairly compact. A determination to avoid
> 'public static void main' is the biggest influence of Java on Rust.

*laughs* that's possibly true -- we do tend to view Java (and Ada) as
verbosity high-water-marks to avoid -- but there are a few other
influences I can point out:

   - Our liveness checker (and ex-typestate-system) are in some ways
     similar to the definite assignment analysis in java.

   - Our (creeping-into-existence) reflection layer, our existing
     in-crate metadata, our somewhat draconian restrictions on
     our own grammar, our attribute and doc-comment system and our
     compiler-as-a-library and extension mechanisms in the compiler
     are all at least partly inspired by the remarkable difference in
     tool maturity and power between C++ and Java. We'd like the
     language to be (eventually) as amenable to tooling as Java, or
     as near as can be without requiring a byte-code IR.

   - Rust has unsigned types, local type inference, disjoint unions,
     tuples, a variety of "nicer" type-system things of this sort.

   - We have tried to avoid a number of pain points we see in Java:
     - Ubiquitous heap allocation
     - Ubiquitous locking
     - Virtual-by-default dispatch
     - Finalizers rather than destructors

But really, the _main_ difference is the focus on ahead-of-time, native
compilation to standard executables and libraries, rather than bytecode
and managed runtimes / virtual machines / JITs. This decision influences
a _lot_ of the subsequent design tradeoffs.

Hth, and good luck!

-Graydon

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Sebastian Sylvan
In reply to this post by Brian Anderson
On Thu, Aug 23, 2012 at 3:48 PM, Brian Anderson <banderson at mozilla.com> wrote:

>
> * No data races - there's no complex model describing when variables are
> between threads, no volatiles.
> * Global GC - Java has notorious stop-the-world GC behavior (though it is
> very good). Rust's GC is per-task so when one task is collecting others
> continue running in parallel. With care you can in theory write tasks that
> never GC.
> * Lambda expressions - Rust has a very simple syntax, so Rust code uses
> them everywhere, whereas Java needs a lot of ceremony to do function-y
> things.

Rust doesn't have null pointer crashes. In fact, I'm kinda ambivalent
about calling a language where any reference may blow up "memory
safe". IME the vast majority of runtime crashes in Java/C# are null
pointer exceptions, so eliminating those are not an insigificant
benefit.

--
Sebastian Sylvan

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Jeffery Olson
As a C# developer, I definitely do *agree* with the above statement.
Simultaneously, Option<T> doesn't solve all of our problems.

Putting aside whether this is a troll on Scala devs, considering the following:

http://beust.com/weblog/2012/08/19/a-note-on-null-pointers/

"...but don?t listen to people who tell you that because you are no
longer seeing any null pointer exceptions, your code is safer. It?s
not. You still have to fix your bugs."

Food for thought. But yes, I do enjoy the lack of NREs (as they're
colloquially referred to in .NET land) working w/ Rust.

Cheers,
Jeff

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Daniel Patterson
The difference is that you know where you can get a null pointer, and where you can't. If you wrap everything with Option, then you will be no better off. The hope is that often you can avoid this (i.e., write pure code that cannot go wrong, or isolate and deal with errors), and then you _will_ be better off.


On Aug 23, 2012, at 10:04 PM, Jeffery Olson wrote:

> As a C# developer, I definitely do *agree* with the above statement.
> Simultaneously, Option<T> doesn't solve all of our problems.
>
> Putting aside whether this is a troll on Scala devs, considering the following:
>
> http://beust.com/weblog/2012/08/19/a-note-on-null-pointers/
>
> "...but don?t listen to people who tell you that because you are no
> longer seeing any null pointer exceptions, your code is safer. It?s
> not. You still have to fix your bugs."
>
> Food for thought. But yes, I do enjoy the lack of NREs (as they're
> colloquially referred to in .NET land) working w/ Rust.
>
> Cheers,
> Jeff
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev


Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Graydon Hoare
In reply to this post by Jeffery Olson
On 12-08-23 7:04 PM, Jeffery Olson wrote:

> As a C# developer, I definitely do *agree* with the above statement.
> Simultaneously, Option<T> doesn't solve all of our problems.
>
> Putting aside whether this is a troll on Scala devs, considering the following:
>
> http://beust.com/weblog/2012/08/19/a-note-on-null-pointers/
>
> "...but don?t listen to people who tell you that because you are no
> longer seeing any null pointer exceptions, your code is safer. It?s
> not. You still have to fix your bugs."

Yes and no. I agree that it's not a panacea; you can obviously still
have a malformed value. But static refinement of an X-or-Y type into
independent just-X, just-Y, and X-or-Y types does help you notice (and
eliminate) cases where you mean one and not the other. Any time you
constrain your statically legal state-space, you tend to kill off a big
chunk of bugs.

(Nonexistent state-space, like not-written code, carries no bugs :)

-Graydon


Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Jeffery Olson
> Yes and no. I agree that it's not a panacea;

This was, pretty much, the only point I wanted to advance. Although we
still have void pointers in the form of FFI

And, to be fair, another major plank of the linked post was that
Option-style library APIs aren't ubiquitous even in Scala, and
certainly not in the larger Java Class Library. This is not true for
Rust, where Options<T> (or Result<T, U>)-style APIs exist
idiomatically through the libraries (much to users chagrine, at times,
anecdotally at least if feedback from net::tcp is any indicator :)

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Ziad Hatahet
On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson <olson.jeffery at gmail.com>wrote:

>
> And, to be fair, another major plank of the linked post was that
> Option-style library APIs aren't ubiquitous even in Scala, and
> certainly not in the larger Java Class Library. This is not true for
> Rust, where Options<T> (or Result<T, U>)-style APIs exist
> idiomatically through the libraries ...


I am still new to using a language with an Option type (I come from an
imperative language background,) but wouldn't it be preferable to try to
mitigate the number of calls that return an Option type as opposed to
returning an actual reference as references cannot be null/nil in Rust? Of
course that probably does not apply where an error or failure might happen
(such as IO).

Thanks,

--
Ziad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120824/60805d8e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Nathan
On Fri, Aug 24, 2012 at 10:13 AM, Ziad Hatahet <hatahet at gmail.com> wrote:

> On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson <olson.jeffery at gmail.com>
> wrote:
>>
>>
>> And, to be fair, another major plank of the linked post was that
>> Option-style library APIs aren't ubiquitous even in Scala, and
>> certainly not in the larger Java Class Library. This is not true for
>> Rust, where Options<T> (or Result<T, U>)-style APIs exist
>> idiomatically through the libraries ...
>
>
> I am still new to using a language with an Option type (I come from an
> imperative language background,) but wouldn't it be preferable to try to
> mitigate the number of calls that return an Option type as opposed to
> returning an actual reference as references cannot be null/nil in Rust? Of
> course that probably does not apply where an error or failure might happen
> (such as IO).
>

I believe you will find this just "naturally" happens:

If you're writing code that is intended to produce a value, but you
find there are cases where it cannot, then perhaps option<T> would
make that explicit and type safe for that code and the caller.  There
might be other alternative approaches, but hopefully the type system
forces you to deal with the case.  option<T> is a way to pass the buck
to the caller, *except* it is explicit (unlike everything-may-be-null
languages where it is effectively implicit).

If on the other hand, you're writing code and see that in every case
it has a concrete value, then there's no need for option<T>.  I think
you'll find that it is natural to drop the type from option<T> in this
case to T when writing new code, because it's simply less effort for
the benefit of fewer cases to produce and deal with.

At first it may seem cumbersome if you are *refactoring* an API and
change a T to and option<T>, but if you think about it, in an
everything-may-be-null language where you do *not* have to refactor,
you've just introduced many potential bugs without realizing it.
Going the other way, where you refactor an option<T> to a T, you'll
find that you just end up deleting a bunch of now unused code.  And
what is more rewarding than deleting code?


One last point about runtime errors: I'm not familiar with how rust
handles these, but I believe it would require work and also lead to
poor apis if runtime errors are translated into none options.  This
would be akin to swallowing an exception and returning null in a
language like Java/python/javascript, except in rust the caller would
be forced to deal with that case.


> Thanks,
>
> --
> Ziad
>
>


Nathan


> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Steven Blenkinsop
On Friday, August 24, 2012, Nathan wrote:

> On Fri, Aug 24, 2012 at 10:13 AM, Ziad Hatahet <hatahet at gmail.com<javascript:;>>
> wrote:
> > On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson <olson.jeffery at gmail.com<javascript:;>
> >
> > wrote:
> >>
> >>
> >> And, to be fair, another major plank of the linked post was that
> >> Option-style library APIs aren't ubiquitous even in Scala, and
> >> certainly not in the larger Java Class Library. This is not true for
> >> Rust, where Options<T> (or Result<T, U>)-style APIs exist
> >> idiomatically through the libraries ...
> >
> >
> > I am still new to using a language with an Option type (I come from an
> > imperative language background,) but wouldn't it be preferable to try to
> > mitigate the number of calls that return an Option type as opposed to
> > returning an actual reference as references cannot be null/nil in Rust?
> Of
> > course that probably does not apply where an error or failure might
> happen
> > (such as IO).
> >
>
> I believe you will find this just "naturally" happens:
>
> If you're writing code that is intended to produce a value, but you
> find there are cases where it cannot, then perhaps option<T> would
> make that explicit and type safe for that code and the caller.  There
> might be other alternative approaches, but hopefully the type system
> forces you to deal with the case.  option<T> is a way to pass the buck
> to the caller, *except* it is explicit (unlike everything-may-be-null
> languages where it is effectively implicit).
>
> If on the other hand, you're writing code and see that in every case
> it has a concrete value, then there's no need for option<T>.  I think
> you'll find that it is natural to drop the type from option<T> in this
> case to T when writing new code, because it's simply less effort for
> the benefit of fewer cases to produce and deal with.
>
> At first it may seem cumbersome if you are *refactoring* an API and
> change a T to and option<T>, but if you think about it, in an
> everything-may-be-null language where you do *not* have to refactor,
> you've just introduced many potential bugs without realizing it.
> Going the other way, where you refactor an option<T> to a T, you'll
> find that you just end up deleting a bunch of now unused code.  And
> what is more rewarding than deleting code?
>
>
> One last point about runtime errors: I'm not familiar with how rust
> handles these, but I believe it would require work and also lead to
> poor apis if runtime errors are translated into none options.  This
> would be akin to swallowing an exception and returning null in a
> language like Java/python/javascript, except in rust the caller would
> be forced to deal with that case.
>

That's what a `result` is for.
 http://dl.rust-lang.org/doc/core/result.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120824/9ff3beb2/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Rust lightning talk at JavaZone 2012

Reidar Sollid
In reply to this post by Brian Anderson
Hi Brian,

Sorry for top-posting.

Thanks a lot for great input !

Best regards
Reidar


On 8/24/12 12:48 AM, "Brian Anderson" <banderson at mozilla.com> wrote:

>On 08/21/2012 10:33 AM, Reidar Sollid wrote:
>> Hi,
>>
>> JavaZone 2012 have accepted my lightning talk on Rust, it is just 10 min
>> so it is not much time to present Rust
>>
>>
>>http://javazone.no/incogito10/events/JavaZone%202012/sessions#a8b2bb04-03
>>f2-4e88-9663-8387692af0e0
>>
>> I am deffently  doing task, but I need to build up to the tasks.
>>
>> Any suggestions on what to press in during those 10 min to convince Java
>> devs that Rust is a great language?
>
>Hi Reidar,
>
>This is very cool!
>
>I'm not too in-tune with the Java world right now, but here are some
>notes comparing Java and Rust.
>
>Two big selling points for a Java programmer are freedom from data races
>and control over memory layout, and these are both topics relevant to
>introducing Rust tasks.
>
>Java has a complex memory model describing what happens when multiple
>threads access shared memory. Rust has no shared memory, no volatile
>keyword, no synchronized methods. Synchronization in Rust is almost
>always based on message passing instead of locks.
>
>That's not to say that Rust's memory model isn't complex, but it's
>complex in entirely different ways. In Rust you have several options on
>for where to place objects in memory. If you try you can completely
>avoid the garbage collected heap. The Rust division between the GC heap
>and the exchange heap is what allows Rust to avoid data races.
>
>Rust and Java share some qualities:
>
>* Safety guarantees - never crash, never write bad memory
>* Both allow locals to be declared and assigned in separate statements
>while ensuring that they are definitely initialized before use.
>* Existential types - Rust traits can be used like Java interfaces by
>casting the type to the trait, though this isn't the typical usage
>because it involves vtables and is less efficient than using traits to
>place bounds on type parameters.
>
>Here are some common Java grips that Rust potentially can do better:
>
>* No data races - there's no complex model describing when variables are
>between threads, no volatiles.
>* Global GC - Java has notorious stop-the-world GC behavior (though it
>is very good). Rust's GC is per-task so when one task is collecting
>others continue running in parallel. With care you can in theory write
>tasks that never GC.
>* Lambda expressions - Rust has a very simple syntax, so Rust code uses
>them everywhere, whereas Java needs a lot of ceremony to do function-y
>things.
>
>Differences
>
>* Unsafe sublanguage - Rust gives you low level control when you need it
>* Control over memory layout - Local heap/echange heap/stack
>* Iterators - Rust uses higher-order functions instead of iterator objects
>* Expressiveness - Rust code is fairly compact. A determination to avoid
>'public static void main' is the biggest influence of Java on Rust.
>
>Good luck with your talk!
>
>Regards,
>Brian
>
>_______________________________________________
>Rust-dev mailing list
>Rust-dev at mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev