From: ng0 <contact.ng0@cryptolab.net>
To: guix-devel@gnu.org
Subject: the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam]
Date: Sat, 1 Apr 2017 07:58:41 +0000 [thread overview]
Message-ID: <20170401075841.242czleuqvibqmjf@abyayala> (raw)
tor is seriously considering to switch to rust. I have my own open
bugs / roadmap points which depend on our rust-build-system working.
tor will not switch immediately, but it shows the importance of having a
working rust-build-system. Firefox will switch at some point.
Danny, could you list what's left for completion? Is it just circular
dependencies? I'm about to publish my project page within the next few
days. I hope you don't mind if I list you as a go-to person for getting
involved in upstream (Guix) to fix up the rust-build-system.
If you do mind, please let me know. I will not publish your email
address, I'll rather point to a git commit.
----- Forwarded message from Sebastian Hahn -----
From: Sebastian Hahn
To: tor-dev@lists.torproject.org
Subject: [tor-dev] Tor in a safer language: Network team update from Amsterdam
Hi there tor-dev,
as an update to those who didn't have the chance to meet with us in
Amsterdam or those who haven't followed the efforts to rely on C less,
here's what happened at the "let's not fight about Go versus Rust, but
talk about how to migrate Tor to a safer language" session and what
happened after.
Notes from session:
We didn't fight about Rust or Go or modern C++. Instead, we focused on
identifying goals for migrating Tor to a memory-safe language, and how
to get there. With that frame of reference, Rust emerged as a extremely
strong candidate for the incremental improvement style that we
considered necessary. We were strongly advised to not use cgo, by people
who have used it extensively.
As there are clearly a lot of unknowns with this endeavor, and a lot
that we will learn/come up against along the way, we feel that Rust is a
compelling option to start with, with the caveat that we will first
experiment, learn from the experience, and then build on what we learn.
You can also check out the session notes on the wiki (submitted, but not
posted yet).[1]
The real fun part started after the session. We got together to actually
make a plan for an experiment and to give Rust a serious chance. We
quickly got a few trivial things working like statically linking Rust
into Tor, integrating with the build system to call out to cargo for the
Rust build, and using Tor's allocator from Rust.
We're planning to write up a blog post summarizing our experiences so
far while hopefully poking the Rust developers to prioritize the missing
features so we can stop using nightly Rust soon (~months, instead of
years).
We want to have a patch merged into tor soon so you can all play with
your dev setup to help identify any challenges. We want to stress that
this is an optional experiment for now, we would love feedback but
nobody is paid to work on this and nobody is expected to spend more
time than they have sitting around.
We have committed to reviewing any patch that includes any Rust code to
provide feedback, get experience to develop a style, and actually make
use of this experiment. This means we're not ready to take on big
patches that add lots of tricky stuff quite now, we want to take it slow
and learn from this.
We would like to do a session at the next dev meeting to give updates on
this effort, but in the meantime, if team members would like to start
learning Rust and helping us identify/implement small and well-isolated
areas to begin migration, or new pieces of functionality that we can
build immediately in Rust, that would be really great.
So, for a TLDR:
What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small)
initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly
interdependent)
What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use
(to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing
Cheers
Alex, Chelsea, Sebastian
[1]: Will be visible here https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
----- End forwarded message -----
next reply other threads:[~2017-04-01 7:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-01 7:58 ng0 [this message]
2017-04-01 18:58 ` the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam] Leo Famulari
2017-04-01 22:22 ` Ludovic Courtès
2017-12-08 10:04 ` ng0
2017-04-02 13:02 ` ng0
2017-04-02 13:05 ` ng0
2017-04-02 22:35 ` Danny Milosavljevic
2017-12-07 20:59 ` ng0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170401075841.242czleuqvibqmjf@abyayala \
--to=contact.ng0@cryptolab.net \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).