A Rust FFI adventure in unsafety • Hacker News Board

Re: A Rust FFI adventure in unsafety

#51

Post by sgtnasty » Thu, Oct 11, 2018, 1:22 AM UTC

ilovecaching wrote: post #3

Accipitriform wrote: post #2

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'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…

I am learning Rust now, in an attempt to redo some Python scripts that run too slow (using threading). I was going to go with C (worked with it for years back in the 90's), until I stumbled upon Rust.

Rust is so easy to install and get up and running on any platform. But I am getting increasingly frustrated with documentation of many crates I try to use which were so easy in Python. For example serde, log4rs, clap (docs are pretty good).

For example, I can not find any way to change the log level in the log4rs implementation at runtime, or how to configure formatters with the yaml file.

Re: A Rust FFI adventure in unsafety

#52

Post by staticassertion » Thu, Oct 11, 2018, 2:35 AM UTC

pjmlp wrote: post #15

Accipitriform wrote: post #2

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.

GC doesn't factor into my use of rust, really. It's definitely a nice benefit, but not the main motivator.

I use it because it's easy to write code that I can come back to later and understand, and have confidence in.

Re: A Rust FFI adventure in unsafety

#53

Post by blub » Thu, Oct 11, 2018, 5:50 AM UTC

ilovecaching wrote: post #3

Accipitriform wrote: post #2

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'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…

I'm very skeptical that one can transition a team to another language and have everything go perfectly.

To summarize:

* learning curve successfully flattened to a week by... reading two books.

* painlessly interacting with a large C++ code base

* no team member dislikes the change, instead they're feeling energized and this has even brought back some from near-burnout.

* Rust is extremely productive

I can accept that the tooling's good, community's nice and type system's a pleasure to use, sure. But people don't change so easily and such drastic changes in large code bases don't go right by default.

If all of what you said above were true, every C++ codebase would have been switched yesterday.

Re: A Rust FFI adventure in unsafety

#54

Post by Accipitriform » Thu, Oct 11, 2018, 2:13 PM UTC

1bent wrote: post #11

Accipitriform wrote: post #2

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 sw…

> I think of Julia and swift as higher-level languages, more domain-specific. Different tools for different problem domains.

Well...my particular interest in these types of languages is primarily in the realm of soft real-time simulation, specifically various kinematic simulations.

Of the three, only Julia is garbage collected, and (unlike some other GC languages) it's fairly easy to not exercise the collector. I'm encouraged that will continue to be the case, since there's an organization using it for robotics, which is implicitly a hard real time use case.

http://www.juliarobotics.org/

Julia, Swift and Rust are all clearly general purpose languages. Swift is unabashedly general purpose, while Julia and Rust each have a primary niche - math/science and systems, respectively. All three use the excellent LLVM infrastructure.

Aside from determinism (which mainly requires pre-allocating nearly everything), my primary requirements are expressiveness/productivity, readability, and efficient runtime performance.

All three languages produce highly optimized code, and Rust probably has the edge as far as efficiency goes - but it clearly loses on the first two criteria, at least to Julia. If one needs access to machine level functionality in Julia, there's an extremely efficient C FFI, so mixing Rust and Julia (for instance) would be painless if needed.

https://github.com/dyu/ffi-overhead

It's a great time to be a software developer, and things will only get better as languages and tooling continue to improve!