Live data from Hacker News

A Rust FFI adventure in unsafety

travisf.net

31–40 of 54 posts

Re: A Rust FFI adventure in unsafety

#31

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…

Would you have any sort of stats on your productivity with C++ vs. Go vs. Rust?

It's hard to measure productivity, but one thing I'd like to point out about Go is that is has relatively few productivity feature. It's main advantage is that's simple, but with automatic derivation, traits, closures, real enums (sum types), Rust actually provides more high level niceties than Go. We can also encode rules using the richer type system of Rust over Go or C++, things like state changes can be verified at compile time via phantom type for example. Expression based programming coupled with the borrow checker allows us to write expressive code that is also efficient.

I'm not going to claim that we have proof the Rust is more productive than Go or C++. I see some concrete advantages, however, Rust may simply better suited to the work we're doing. We might just enjoy writing it and therefore work faster.

The way I see it is that Rust guides you to better architectures, it offers a lot of very powerful features from FP and PL theory, and it's all engineered to make sense as a language. In that way, I think it's similar to Go in that they're both engineered while C++ has a lot of fossilized layers and has been organically grown for decades now. We have C++ code from half a decade ago that looks nothing like what we are writing now. It's this organic beast that has a lot of baggage. Rust and Go are engineered from the ground up, and with Rust editions I think they will avoid becoming the organic beast that C++ is now.

Re: A Rust FFI adventure in unsafety

#32
post #8

Earlier quoted context omitted.

> 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.

I guess it is a matter of what kind of systems one is developing, given its use in embedded platforms.

Re: A Rust FFI adventure in unsafety

#33

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…

Rust is amazing (but also frustrating), but RLS is, frankly, terrible. It is unreliable, slow and unstable.

Re: A Rust FFI adventure in unsafety

#34
post #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 sw…

This was exactly the case that got me into Rust; I had something that needed to be fast and needed to be callable from a variety of languages & environments (from python, C and Java immediately, and expecting to add swift later) but it also had to do a lot of unicode string handling, and I just _really_ didn't want to do it in C. After making sure that everything I needed was possible, I did it in Rust and it was an absolute pleasure; I haven't looked back.

Re: A Rust FFI adventure in unsafety

#35

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…

Out of curiosity, what are you building and with what company?

Re: A Rust FFI adventure in unsafety

#36
post #6

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…

What do you use as your development environment?

IntelliJ IDEA CE is way better than VS Code, IMHO. Much more reliable in the type inference.

Re: A Rust FFI adventure in unsafety

#37

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…

Rust is amazing (but also frustrating), but RLS is, frankly, terrible. It is unreliable, slow and unstable.

As of now, the Rust IntelliJ plugin combined with CLion provides the absolute best Rust IDE experience (it even gives you a visual debugger that works as it’s supposed to...)

Re: A Rust FFI adventure in unsafety

#39

See, this is why you need the lines above and below the letter I. I thought this was a Rust remake of Final Fantasy 1. So disappointing...

Don't the Final Fantasy games use Roman numerals for numbering anyway?

I guess you're right. Maybe I just have FF1 on the brain. Either that or 3 remakes wasn't enough.

Re: A Rust FFI adventure in unsafety

#40
post #30

See, this is why you need the lines above and below the letter I. I thought this was a Rust remake of Final Fantasy 1. So disappointing...

> the lines above and below the letter Serifs is the word you are looking for. Hmm, from examining the font style in the stylesheet, and playing around it looks like Verdana is preferred, and then it falls back to Geneva, and then some default sans-serif.[1] Verdana has serifs though, and Geneva either doesn't or I don't have Geneva, so that seems an odd choice of preferences and fall backs. 1: The CSS is "font-famil…

Looks like you've outnerded me. Well done.
Post reply on HN