Rustgo: Calling Rust from Go with near-zero overhead (2017)
blog.filippo.io
blog.filippo.io
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?
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.
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).
If the local variable is the last reference to the thing, https://golang.org/pkg/runtime/#KeepAlive makes sure the Go side doesn't drop it before the call is complete.
I wonder if this changed. A quick glance over the blog hints me towards a no.
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
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
I do agree that there a few cases where Julia in theory could do what you wanted, but it's a bit awkward to get the guarantee from the compiler that it will do so (e.g. SIMD this thing, constexpr this thing..). I do hope this situation improves.
So it's not as damning as you seem to suggest.
But yes, rust is definitely pretty cool, and I'm annoyed that I finally "understand" the language on my nth attempt at learning it, and still haven't found a good use case for it.
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.”
C was just intended to be third in that very specific lineage, and I wouldn't be surprised to find it wasn't really third and just making the claim with its name.
Not to mention several more advanced than C, Go, or even Rust... (Lisp, for one, Smalltalk for another)
I encourage people to try writing run of the mill blocking code with Rust instead of diving immediately into futures and thread pools and streams just as if you were writing run of the mill Python.
It's generally 1:1 equivalent to the code I would've written in another language.
It's a general purpose programming language where most of the learning curve is in more advanced topics like concurrency, streams, and how to multiplex over thread pools. You can ignore them at the start, just like you can in Python.
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?