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

Lessons from Mixing Rust and Java: Fast, Safe, and Practical

medium.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#31

Post by tialaramex »

pjmlp wrote: post #22
bullen wrote: post #12

I agree that Java + native is the way to go. But does rust really give you an edge over C/C++? Here is how you do JNI with C++: http://move.rupy.se/file/jvm.txt So simple it's ridiculous! Then you can use RegisterNatives to give C++ API to the Java side instead of the stub (Java calls C++ .dll/.so) thing...

Your comment is exactly the reason why while I find Rust a cool language, I would be using C++ instead. That is the systems language most JVM implementations make use of, alongside Java, and what is directly supported by JNI tooling, including on Java IDEs mixed language debugging. And in what concerns Java, native is anyway the synonym for unsafe . However to each their own.

C++ is a perfectly good programming language if you never make mistakes. So the problem is that of course you'll make mistakes, and the people who wrote your compiler make mistakes, and the C++ committee makes mistakes, and the language's inventor makes mistakes, if you work in a team the other team members and the tooling both also have mistakes. Other than these issues, sound choice.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#32

Post by koakuma-chan »

never_inline wrote: post #29
koakuma-chan wrote: post #20

I found mixing Bun and Rust works pretty well. Bun has gotten many cool new things recently which feel great to use and it has a nice FFI API. So I have Next.js apps running in Bun runtime and anything CPU bound is written in Rust and called via FFI.

JS developer use tooling older than 3 years challenge. Level: impossible.

It's not only JS. The tooling was just trash everywhere before Rust started gaining traction. E.g. for Python there is uv now, and I am definitely not going back to freaking pip.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#33

Post by no_wizard »

4hg4ufxhy wrote: post #15
lukax wrote: post #2

Do not write the bindings manually. Just use the amazing uniffi-rs library from Mozilla. https://github.com/mozilla/uniffi-rs You can generate bindings for multiple languages. It supports error handling on both sides and latest versions also support native async integration. I've used it to reuse the same Rust engine in iOS and Android apps and write native UI. https://github.com/koofr/vault

The bindings are inefficient doing excessive cloning. But if performance is not a concern then its fine.

Couldn’t you manually edit after generating so you could thereby optimize the code as needed?

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#34

Post by pjmlp »

tialaramex wrote: post #31
pjmlp wrote: post #22

Earlier quoted context omitted.

Your comment is exactly the reason why while I find Rust a cool language, I would be using C++ instead. That is the systems language most JVM implementations make use of, alongside Java, and what is directly supported by JNI tooling, including on Java IDEs mixed language debugging. And in what concerns Java, native is anyway the synonym for unsafe . However to each their own.

C++ is a perfectly good programming language if you never make mistakes. So the problem is that of course you'll make mistakes, and the people who wrote your compiler make mistakes, and the C++ committee makes mistakes, and the language's inventor makes mistakes, if you work in a team the other team members and the tooling both also have mistakes. Other than these issues, sound choice.

You can bash C++ as much as you feel like, if it makes you happy.

I am well aware of the issues with C++'s flaws, sometimes it is easier to deal with such flaws, than adding a new layer into the C++ sandwich of debugging tools, build toolchain and IDE tooling for a given language runtime, and dragging a whole team for the ride as well.

What about removing LLVM dependency from Rust, switch to Cranelift, so that rustc isn't hindered by C++ mistakes on LLVM?

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#35

Post by tialaramex »

pjmlp wrote: post #34
tialaramex wrote: post #31

Earlier quoted context omitted.

C++ is a perfectly good programming language if you never make mistakes. So the problem is that of course you'll make mistakes, and the people who wrote your compiler make mistakes, and the C++ committee makes mistakes, and the language's inventor makes mistakes, if you work in a team the other team members and the tooling both also have mistakes. Other than these issues, sound choice.

You can bash C++ as much as you feel like, if it makes you happy. I am well aware of the issues with C++'s flaws, sometimes it is easier to deal with such flaws, than adding a new layer into the C++ sandwich of debugging tools, build toolchain and IDE tooling for a given language runtime, and dragging a whole team for the ride as well. What about removing LLVM dependency from Rust, switch to Cranelift, so that rustc…

Sure, or perhaps since LLVM devs like niches so much they might decide to RIIR.

For me the big advantage of Cranelift isn't that it's written in Rust it's that they seem to have invested more into coherent semantics. I do not want to write code which is correct but is miscompiled because the compiler internal semantics are nonsense and that's a small but noticeable problem in LLVM.

You can write contorted (but safe) Rust which LLVM just plainly miscompiles, the rust layer is like "Make local variable A, and local variable B" Ok says LLVM, "and now is the address of A the same as the address of B?" "No", says LLVM those are different, not the same variable so different addresses. OK says the Rust. Now, subtract the smaller from the larger and tell me the number you got. "Zero" triumphantly proclaims LLVM having deduced that we don't need A or B so there's no need to store them anywhere, but forgotten that it promised their addresses aren't the same... Oops.

That example is silly, but it's hard to be sure how many large codebases might tickle equivalent LLVM miscompilation, which is not good.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#36

Post by nilslice »

Others should consider Chicory, enabling JVM apps to run wasm code (compiled from Rust or many other languages) at high speed, securely in-process.

JNI introduces a lot of other challenges and sacrifice in terms of portability, memory and retaining observability and control within the JVM.

Chicory even supports AOT compilation to translate wasm bytecode to JVM bytecode for native performance.

https://github.com/dylibso/chicory

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#37

Post by mrkeen »

pjmlp wrote: post #34
tialaramex wrote: post #31

Earlier quoted context omitted.

C++ is a perfectly good programming language if you never make mistakes. So the problem is that of course you'll make mistakes, and the people who wrote your compiler make mistakes, and the C++ committee makes mistakes, and the language's inventor makes mistakes, if you work in a team the other team members and the tooling both also have mistakes. Other than these issues, sound choice.

You can bash C++ as much as you feel like, if it makes you happy. I am well aware of the issues with C++'s flaws, sometimes it is easier to deal with such flaws, than adding a new layer into the C++ sandwich of debugging tools, build toolchain and IDE tooling for a given language runtime, and dragging a whole team for the ride as well. What about removing LLVM dependency from Rust, switch to Cranelift, so that rustc…

Because those mistakes get fixed on LLVM devs' time, not on parent's.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#38

Post by never_inline »

koakuma-chan wrote: post #32
never_inline wrote: post #29

Earlier quoted context omitted.

JS developer use tooling older than 3 years challenge. Level: impossible.

It's not only JS. The tooling was just trash everywhere before Rust started gaining traction. E.g. for Python there is uv now, and I am definitely not going back to freaking pip.

Me neither. But only because uv is compatible with pip. I am not going to use bun / dinosaur whatever instead of node at this point.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#39

Post by koakuma-chan »

never_inline wrote: post #38
koakuma-chan wrote: post #32

Earlier quoted context omitted.

It's not only JS. The tooling was just trash everywhere before Rust started gaining traction. E.g. for Python there is uv now, and I am definitely not going back to freaking pip.

Me neither. But only because uv is compatible with pip. I am not going to use bun / dinosaur whatever instead of node at this point.

> But only because uv is compatible with pip.

Take this: Bun is compatible with Node.

Re: Lessons from Mixing Rust and Java: Fast, Safe, and Practical

#40

Post by pjmlp »

mrkeen wrote: post #37
pjmlp wrote: post #34

Earlier quoted context omitted.

You can bash C++ as much as you feel like, if it makes you happy. I am well aware of the issues with C++'s flaws, sometimes it is easier to deal with such flaws, than adding a new layer into the C++ sandwich of debugging tools, build toolchain and IDE tooling for a given language runtime, and dragging a whole team for the ride as well. What about removing LLVM dependency from Rust, switch to Cranelift, so that rustc…

Because those mistakes get fixed on LLVM devs' time, not on parent's.

Yeah, but parent clearly enjoys the outcome of all universities and compiler vendors, that despite their mistakes, pump into optimizations passes, and advanced compiler algorithms into LLVM, even though they happen to be written in C++.
Post reply on HN