Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Rust FFI adventure in unsafety

travisf.net

Post reply on HN
Print view View original

41–50 of 54 posts

Re: A Rust FFI adventure in unsafety

#41

Post by bacon_waffle »

Sawamara wrote: post #19
Sean1708 wrote: post #5

Earlier quoted context omitted.

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

For me, the ebook version on my laptop in Calibre has been great; no regrets buying that, instead of the dead tree version.

It's a nice complement to the open-source Rust book too, which may as well be read in digital form.

Re: A Rust FFI adventure in unsafety

#42

Post by valarauca1 »

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!

The correctness I'd argue is worth it.

My company has been shipping a service in rust for >1 year and its really nice knowing when the tests pass, and the app gets deployed it'll do exactly what it needs to in perpetuity. Once tests pass locally pushing to master doesn't require a second thought, if it ever does it means local tests should be updated.

While there is a non-trivial spinup learning to work in the language, and unlearning bad habits from other languages can be frustrating (especially coming from C). The performance, without losing correctness is wonderful.

Re: A Rust FFI adventure in unsafety

#43

Post by ilovecaching »

pjmlp wrote: post #16
EeThahs2 wrote: 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.

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

Not really, like I said, java isn't really suitable for systems level work, or a good choice for FFI to C/C++. There are also a lot of disadvantages to using Java. Java lacks some of the compile time safety features of Rust. It has high level features like Sum types that Java does not have. The owners of Java have also sued reimplementors as well, which I think should give anyone pause about using it to do business with.

Re: A Rust FFI adventure in unsafety

#44

Post by pjmlp »

ilovecaching wrote: post #43
pjmlp wrote: post #16

Earlier quoted context omitted.

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

Not really, like I said, java isn't really suitable for systems level work, or a good choice for FFI to C/C++. There are also a lot of disadvantages to using Java. Java lacks some of the compile time safety features of Rust. It has high level features like Sum types that Java does not have. The owners of Java have also sued reimplementors as well, which I think should give anyone pause about using it to do business w…

As I mention in another thread, it is a matter of what kind of systems level work you mean, given its successful use in embedded platforms, namely military, office devices, manufacturing automation and IoT.

Kotlin and Scala have Sum types, and Rust still needs to catch up with Scala's type system.

The owners of Java only sue reimplementors that don't respect licenses, like Microsoft and Google.

None of other commercial third parties has had any issue with Java owners.

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...

Naturally I am not advocating for you to use Java instead of Rust, rather that it also has its uses in system work, and it is a valid option in scenarios where having a GC enabled language isn't a problem.

Re: A Rust FFI adventure in unsafety

#45

Post by gameswithgo »

ilovecaching wrote: post #31
mehrdadn wrote: post #28

Earlier quoted context omitted.

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…

It probably depends greatly on what you are doing. There is a lot of work where I would be much more productive in Go because I have yet to really master Rust, as it is a big and complex language while Go is so simple. But I have also made a library where the various meta-programming features in Rust saved me thousands of hours of work and ongoing maintenance compared to what it would have taken to recreate it in Go.

Similarly, the productivity difference will depend on how much run-time performance you need. It might be take longer to make Go code very fast if you need very fast. Having to work around the garbage collector, and avoiding interface {} etc.

Re: A Rust FFI adventure in unsafety

#46

Post by jcelerier »

ilovecaching wrote: post #31
mehrdadn wrote: post #28

Earlier quoted context omitted.

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…

> We have C++ code from half a decade ago that looks nothing like what we are writing now.

well, Rust code from half a decade ago is also somewhat distinct from today's rust.. even basic cases don't compile anymore : http://progopedia.com/language/rust/

Re: A Rust FFI adventure in unsafety

#47

Post by burntsushi »

jcelerier wrote: post #46
ilovecaching wrote: post #31

Earlier quoted context omitted.

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…

> We have C++ code from half a decade ago that looks nothing like what we are writing now. well, Rust code from half a decade ago is also somewhat distinct from today's rust.. even basic cases don't compile anymore : http://progopedia.com/language/rust/

Half a decade ago, Rust 1.0 didn't exist. The language was explicitly unstable.

Re: A Rust FFI adventure in unsafety

#48

Post by imc »

ilovecaching wrote: post #29
imc wrote: post #21

Earlier quoted context omitted.

mind sticking up the relevant sections of your vimrc somewhere so I could take a look? the rust stuff in my vim dates to v. early post 1.0 and would love to link ale + rls up.

Sure, install w0rp/ale using your favorite plugin manager, install rustup and run: rustup component add rls-preview rust-analysis rust-src --toolchain nightly then add this to .vim/ftplugin/rust.vim: let b:ale_linters = {'rust': ['rls','cargo','rustc']} let g:ale_fixers = {'rust': ['rustfmt']} let g:ale_completion_enabled = 1

perfect, thanks!

Re: A Rust FFI adventure in unsafety

#49

Post by dman »

ilovecaching wrote: post #27
protomyth wrote: post #26

Earlier quoted context omitted.

Did you lose any developers during this period?

No, in fact it's been a selling point in our hiring. Rust seems to jive with a wider audience, it has aspects of FP, C++, and the tooling solves a lot of pain points for more seasoned developers and has energized some of our employees who felt burnt out on pushing our older services forward.

What domain are you working in?

Re: A Rust FFI adventure in unsafety

#50

Post by kbenson »

undefined_user4 wrote: post #40
kbenson wrote: post #30

Earlier quoted context omitted.

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

Hmm, what was lost in revising that comment was the sentence noting that I have swrifs on every device I view HN on, so I was wondering what you were viewing it on. It seems odd that it would change that much between devices when explicitly defined with fallbacks, which is why it's an odd config.
Post reply on HN