[CentralOH] Python and Rust

Tue May 12 17:51:23 CEST 2015

Hi Kurtis,

On Tue, May 12, 2015 at 10:11 AM, Kurtis Mullins <kurtis.mullins at gmail.com>
wrote:

> Hey guys and girls,
>
> Polling for opinions here. I watched the Rust video from PyCon about a
> week ago. I work with a handful of people who commonly attend (and some
> speak) at PyCon. I also work with people who are big "Go" people.
>
> This was really the first time I've come across Rust. It had some cool
> things going for it. I was also surprised to see it backed by Mozilla.
>
> What's the benefits of using Rust over Go? I feel like they were both sort
> of created to solve the same problem. I'm not intending this to be a flame
> war -- I am just genuinely curious how/why Rust is taking off so
> successfully.
>

I'm a big fan of both Rust and Go.  I think it's kind of unfortunate that
the world has sort of pitted them against each other, because they each
have their own strengths and weaknesses and don't, in my opinion, have a
lot of overlap in when you would choose one over the other.

I would choose Rust over Go anywhere using C or C++ was essential:

   - Low-level system programming (kernel, drivers, low-level libraries)
   - System libraries (think an OpenSSL replacement)
   - Any time a garbage collector or runtime is not suitable
   - Situations where memory safety is absolutely essential (again, a
   crypto library comes to mind)

For most applications I personally would choose Go for most things
(especially today with the current level of maturity).  Depending on how
much you like the relative languages would influence that decision for you.

Rust has a much stronger memory safety story.  Its ownership model is novel
and able to guarantee safety at compile time.  It's basically impossible to
write a Rust program that segfaults.  Moreover, due to its immutability
guarantees it's not really possible to end up with concurrency-caused data
races.  Go's is much more memory safe than C, but it still gives you the
ability to shoot yourself in the foot with data races.  Fortunately Go
comes with great tooling to detect these kinds of races and they're pretty
easy to avoid with some experience.

While both Rust and Go can interop rather simply with existing C code, Rust
does so much faster than Go ever could.  This is largely because Go is a
garbage collected language, so data has to be copied when crossing the
barrier into C.  Rust seems to have a little more programmer boilerplate
for this, but fewer memory copies.

Both Rust and Go have very good modern concurrency.  Go's is tightly
integrated with the language, which I think is a huge plus.  Rust has a few
different models that are provided by their standard library.  Rust's seems
to require more boilerplate to use than Go's.

Go is a much, much, much simpler language.  In many ways you can think of
Go as analogous to Python or Ruby and Rust as analogous to C++.  This makes
Go a little less flexible in many ways -- its type system isn't as rich,
for instance -- but it takes vastly less time to begin programming in Go,
become productive with it, and understand other people's Go code.

Go is a lot more mature at this point.  Go 1 was released in 2012, and
there have been 5 stable releases since then.  (Go is on a 6 month release
cycle.)  They have made backwards compatibility guarantees for the lifetime
of Go 1 and there are no plans for Go 2 at this point.  Rust only just
stopped making backward incompatible changes as part of their 1.0 beta a
few weeks ago.  There is much more good third-party Go code out there.

I think Go's standard library is absolutely fantastic.  It is definitely a
"batteries included" standard library.  It is very common for Go programs
to be written using only code from the standard library.  There is a lot of
very good third-party code out there as well.  I don't have as much
experience with Rust's stdlib yet, but I get the feeling that it's not
quite as complete and easy to use as Go's.

The Rust blog has been absolutely on fire lately, highlighting a few
features of the language that really illustrate its power:

   - http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
   -
   http://blog.rust-lang.org/2015/04/17/Enums-match-mutation-and-moves.html
   - http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html
   - http://blog.rust-lang.org/2015/05/11/traits.html

Hope this helps,

Joe

>
> Thanks!
>
>
> On Sun, May 10, 2015 at 2:54 PM, John Santiago <jdsantiagojr at gmail.com>
> wrote:
>
>> Thanks. I have been looking into embedded programming and looks like Rust
>> could possibly replace c/cpp.
>> On May 10, 2015 2:51 PM, "Eric Floehr" <eric at intellovations.com> wrote:
>>
>>> At the last monthly meeting, Raymond mentioned that The Columbus Rust
>>> Society was planning a Rust 1.0 Release party May 15 at Pillar (though the
>>> meetup says no location yet, so it might not be Pillar). The details are
>>> here:
>>>
>>> http://www.meetup.com/columbus-rs/events/222044818/
>>>
>>> If you are interested in hooking your Python code to Rust code instead
>>> of C, there was a talk at PyCon this year by Dan Callahan called "My Python
>>> is a little Rust-y" that talked about how to call Rust functions from
>>> Python:
>>>
>>> https://www.youtube.com/watch?v=3CwJ0MH-4MA
>>>
>>> Cheers,
>>> Eric
>>>
>>>
>>> _______________________________________________
>>> CentralOH mailing list
>>> CentralOH at python.org
>>> https://mail.python.org/mailman/listinfo/centraloh
>>>
>>>
>> _______________________________________________
>> CentralOH mailing list
>> CentralOH at python.org
>> https://mail.python.org/mailman/listinfo/centraloh
>>
>>
>
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> https://mail.python.org/mailman/listinfo/centraloh
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20150512/deb495b1/attachment.html>