Live data from Hacker News

A Rust FFI adventure in unsafety

travisf.net

11–20 of 54 posts

Re: A Rust FFI adventure in unsafety

#11

Excellent and detailed post! Up until now I've been focusing on Julia and Swift for projects that can use a new language, as the Rust pain/productivity ratio has looked too high. Perhaps things are changing...correctness is certainly a worthy goal!

I'm studying rust. In the past, I've used C when I wanted or needed to get close to hardware; even short snatches of assembler. I hope to never again have to write a non-trivial C program and make it thread-safe. Rust looks promising. The pain/productivity of rust should be high; it's trying to let you work as low-level as C, while helping you achieve a "single mutator at a time" safety model. I think of Julia and swift as higher-level languages, more domain-specific. Different tools for different problem domains.

Re: A Rust FFI adventure in unsafety

#12
> We wanted a primitive that would guarantee that initialization of the global variables would happen exactly once.

IIRC, At one time, there was a "lazy_static!" that fit this use case? But maybe you can't do that here if what you need is the side-effect of the library call.

Re: A Rust FFI adventure in unsafety

#13
post #5
post #4

Earlier quoted context omitted.

Can you link to the aforementioned books?

I suspect these two: https://doc.rust-lang.org/stable/book/2018-edition/index.htm... http://shop.oreilly.com/product/0636920040385.do

Yes, those are the sacred texts. I do believe the O'reilly book is worth paying money for. It's extremely well written, and I think it's painstakingly crafted pictures of memory layouts and thorough coverage of lifetimes and traits are tremendously helpful.

Re: A Rust FFI adventure in unsafety

#14

> We wanted a primitive that would guarantee that initialization of the global variables would happen exactly once. IIRC, At one time, there was a "lazy_static!" that fit this use case? But maybe you can't do that here if what you need is the side-effect of the library call.

lazy_static is a wrapper around std::sync::Once, mentioned in the post. I'm not sure if it would be a better fit for the OP, as I haven't read their code.

Re: A Rust FFI adventure in unsafety

#15

Excellent and detailed post! Up until now I've been focusing on Julia and Swift for projects that can use a new language, as the Rust pain/productivity ratio has looked too high. Perhaps things are changing...correctness is certainly a worthy goal!

From my dabbling experiences with Rust, I would say that it should mostly be considered for scenarios where a GC is absolutely no go.

If the application deployment scenario can handle typical GC workloads, then using a programming language with such support is more productive.

One example would be modern GUI toolkits.

Re: A Rust FFI adventure in unsafety

#16
post #8

Earlier quoted context omitted.

I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. We're also calling through the FFI to an SGX SDK and a large C++ codebase, and that's been delightfully painless. We're all extremely glad we chucked C++ and Go and switched to Rust. Rust isn't just a safer C++, it's a language that stands on it's own as extremely productive, safe, and fun to write. We c…

> Cargo + RLS are the best ecosystem tools I've seen in any language. In my experience the java profilers and debuggers are still better than anything that's available for rust. RLS is great on a fundamental level (decoupling IDE from compiler), but it still has to catch up in functionality with the total compiler integration that for example eclipse has with ecj.

Yep, Rust still needs to do a lot to catch up with Java and .NET eco-systems.

Re: A Rust FFI adventure in unsafety

#17
post #9

Earlier quoted context omitted.

I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. We're also calling through the FFI to an SGX SDK and a large C++ codebase, and that's been delightfully painless. We're all extremely glad we chucked C++ and Go and switched to Rust. Rust isn't just a safer C++, it's a language that stands on it's own as extremely productive, safe, and fun to write. We c…

When you switched was it a unanimous decision to write rust? And is this a small team where you all have the same opinion? Or did you have to drag any one along? From what I have seen people who aren't motivated to learn rust struggle. I'm curious how that worked out

There was some convincing, we had to sell why we felt Rust was worth rewriting some of our tools in, and that it was ready for primetime. An initial small group of us spiked and wrote integrations for our logging, tracing, and wrote a Rust compiler for our rpc IDL. After that, we kind of got some shocked reactions as to how we were able to move so quickly and that things actually seemed to 'just work'. We also kept evangelizing, giving internal talks, and just generally pushed the snowball until it gained enough momentum that it became clear that Rust was a win.

Re: A Rust FFI adventure in unsafety

#18
post #8

Earlier quoted context omitted.

I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. We're also calling through the FFI to an SGX SDK and a large C++ codebase, and that's been delightfully painless. We're all extremely glad we chucked C++ and Go and switched to Rust. Rust isn't just a safer C++, it's a language that stands on it's own as extremely productive, safe, and fun to write. We c…

> Cargo + RLS are the best ecosystem tools I've seen in any language. In my experience the java profilers and debuggers are still better than anything that's available for rust. RLS is great on a fundamental level (decoupling IDE from compiler), but it still has to catch up in functionality with the total compiler integration that for example eclipse has with ecj.

We don't use Java. Java is old, of course it has plenty of tooling, but it also has a mountain of negatives in it's own right, besides the fact that it's not suitable for systems level work.

Re: A Rust FFI adventure in unsafety

#19
post #5
post #4

Earlier quoted context omitted.

Can you link to the aforementioned books?

I suspect these two: https://doc.rust-lang.org/stable/book/2018-edition/index.htm... http://shop.oreilly.com/product/0636920040385.do

Thank you. Well, now I have to choose whether I prefer the physical copy or the Safari subscription... :D
Post reply on HN