Rustgo: Calling Rust from Go with near-zero overhead (2017)

https://blog.filippo.io/rustgo/

by ingve • 7 years ago

107 37 7 years ago

blog.filippo.io

killercup• 7 years ago

(2017)

jzelinskie• 7 years ago

Filippo also gave a talk at GothamGo on this subject: https://www.youtube.com/watch?v=eymMKjymgGA

hu32• 7 years ago

I'll be upfront: I don't know Rust, and don't feel compelled to do my day-to-day programming in it.

I wonder if this changed. A quick glance over the blog hints me towards a no.

jaChEWAg• 7 years ago

That line pretty much sums up the experience a lot of devs feel towards Rust

rapsey• 7 years ago

Of course generally the ones who “don’t know it”. But then that probably holds true for all languages one does not know.

ludamad2• 7 years ago

General purpose languages are a tough sell these days. Rust is tailored towards a niche and that's OK

disinclination• 7 years ago

I’ve been thinking recently about how the symbol “C” in “C programming language” literally stands for “3”.

We out here like, “I’ve been getting really into this new language, 12,447. I think it might finally be the thing to replace 3 for me.”

Animats3• 7 years ago

I was a big fan of Rust at first. Then they went off into a weirdo approach to functional programming. That sent Rust to the niche in which Haskell lives.

hombre_fatal2• 7 years ago

This is how most devs feel about any language they don't already use. There are even HNers who regularly brag about having never taken Javascript, one of the most ubiquitous languages, seriously enough to build a nontrivial project or to appreciate its upsides.

So it's not as damning as you seem to suggest.

parentheses• 7 years ago

It's a statement that is ~ 2 years old. I recently started learning it and like many things about it. I also haven't learned enough, so any borrow checker annoyance is likely a symptom of not knowing enough.

So far, I like:

- traits (similar to typeclasses)

- support for functional programming

- borrow checker keeping you aware of memory scoping

- it's (apparently) fast and relatively lightweight

hu32• 7 years ago

Rust is great. It's nice to have an efficient way to call Rust code from Go for when you need that extra speed and security.

I was just curious if Filippo's stance changed about the language since he works with cryptography and security at Google. I'm not seeing Rust in his GitHub repo's https://github.com/FiloSottile

FiloSottile• 7 years ago

A nuance I wish I had expressed better in this article is that it's targeting functions that would otherwise be written in assembly: they'd have to be quick (not to undermine the scheduler) and non-recursive (not to blow the stack). For just calling larger Rust functions one can use cgo.

scottlamb• 7 years ago

+1. There's a reason cgo sets up another stack; calling into Rust instead of C doesn't change that.

What are the consequences if you blow the stack in Go [edit: to clarify, I mean if your code in another language that doesn't understand Go's stack copying calling convention blows Go's stack]? Is there a guard page (so SIGSEGV) or does it just corrupt memory?

Animats3• 7 years ago

If you have to reverse-engineer the undocumented Go calling sequence to call Rust, you probably shouldn't be using that for security-critical crypto functions. The next time somebody changes something, there will be trouble.

This is especially an issue in a garbage collected language. If the only reference to something was passed from Go to Rust, will Go's GC marker find it? If it doesn't, everything will work just fine, until someday a garbage collection happens at the wrong moment.

In security critical code, that's probably exploitable if you can force a GC from another thread.

yencabulator2• 7 years ago

If the only reference to something was passed from Go to Rust, will Go's GC marker find it?

No, and rightly so. I would expect https://golang.org/cmd/cgo/#hdr-Passing_pointers to apply just as much here as with CGo (the criteria is "foreign allocator", not CGo).

Animats3• 7 years ago

Which is a problem here, because the OP is calling Rust from Go using the Go calling sequence. So Go's checking doesn't know it's calling non-Go code. There's a defined way to call C from Go, but the OP is not using that interface.

Myrmornis• 7 years ago

I've been finding learning Rust an extremely valuable experience and I really like the language. Also I don't have any experience with replacing assembly code with a higher-level language. But...

If you're looking for a replacement for hand-crafted assembly, don't the strict lifetime-checker and borrow-checker make Rust a non-obvious choice? E.g. they might prevent you from doing certain memory access patterns that you actually explicitly want your assembly to do? (I.e. wouldn't C or C++ be more the thing?) Or do you just make liberal use of unsafe blocks where necessary? Or is it actually fine and appropriate to write {lifetime,borrow}-checker compliant replacements for hand-crafted assembly?

heinrich5991• 7 years ago

Previous discussion: https://news.ycombinator.com/item?id=15017519 (68 comments)

Rustgo: Calling Rust from Go with near-zero overhead (2017)

Related Stories