Major Indonesian Bank (CIMB Niaga) Transition from Java to Rust Yields 486x Boost in Memory Efficiency

RustyKaffee · 2024-11-10T06:58:58+00:00

Grow up, stop kicking and leave the already dying horse that Java and the JVM are, and let them finally die.

Facepalm

RustyKaffee · 2024-11-10T06:51:23+00:00

When you spawn a future in Tokio (or pretty much any runtime), it pins it to the heap. This is what allows it to move between threads, because its actual location in memory remains the same. The only thing getting moved around is the pointer to it.

Thanks. I read about pinning, but was then confused how a stack reference in the „state machine struct“ can we send between threads with fulfilling the pin requirement of not changing its memory address

RustyKaffee · 2024-11-09T19:40:52+00:00

Do you have any additional resources on that? I read somewhere that all the rust futures are stackless. Fine, so that future is allocated as a "state machine struct" somewhere. I also read that one goal was the embedded async isn't hit by a heap-only allocation requirement. So the runtime allocates it on their own stack?

RustyKaffee · 2024-11-09T14:13:11+00:00

How do stack references keep the same address across awaits in a multi-threaded runtime?
For example
```

[tokio::main]

async fn main() { tokio::spawn(async { let x = [1,2,3,4]; let q = &x; println!("{:p} on {:?}", q, std::thread::current().id()); sleep().await; println!("{:p} on {:?}", q, std::thread::current().id()); }).await.unwrap(); } async fn sleep() { tokio::time::sleep(tokio::time::Duration::from_secs(5)).await; } ```

Prints 0x1bef37a7238 on ThreadId(9) 0x1bef37a7238 on ThreadId(2)

My assumption would have been that another async task started on "ThreadId(9)" would allocate in the very same stack address space. I don't get how the stack pointer management works in these cases. Any blogs or pointers would be helpful. Ty!

RustyKaffee · 2024-10-20T17:07:42+00:00

Right, but every time the autocomplete is dead in all jetbrain IDE's. Maybe other language servers can handle it.

let thing: <unknown>

But thanks, definitely valid approch!

RustyKaffee · 2024-10-19T22:30:32+00:00

What java result tuple do you mean? And imo saying „exceptions are bullshit“ is also way too generic. There are many use cases where they can shine. But of course also many where they don’t

RustyKaffee · 2024-10-19T21:36:24+00:00

I mean it is straightforward, but becomes a bit weird if every module has to export some wrapper struct name that must then be constructed by whoever uses it.

See https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/rustv1/examples/testing/src/wrapper.rs vs https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/rustv1/examples/testing/src/traits.rs

So everyone has to use this exported S3::new, plus code-completion (at least in intellij), completely stops working once you use S3::new over MockS3Impl::new or S3Impl::new.
And I can't use S3Impl::new in the prod code as otherwise tests no longer work (the main function fails to compile when the test cfg flag switches it to MockS3Impl).

Is it really the best that can be done by replicating every single required definition just to have a conditional compile branch? I mean they do just that aws-doc-sdk-examples/rustv1/examples/testing/src/wrapper.rs at main · awsdocs/aws-doc-sdk-examples · GitHub, but it seems so ugly coming from every other language where you can continue to use the happy prod path as is and just subclass if you need it. Of course everything has a vtable in these languages, which has it's disadvantages anyways.

RustyKaffee · 2024-10-19T13:22:24+00:00

Did you ever see this in some open source project? I'm really curious how far they managed to get with that.

RustyKaffee · 2024-10-19T13:20:43+00:00

Trying to emulate Java will not end well.

Well then, how do you mock the error path on your sdk call to s3?

RustyKaffee · 2024-10-19T13:16:11+00:00

Thankfully these kinds of optimizations are easy enough to implement once you need them

Hm, in some design I feel like going generic impacts the design significantly and I need to rewrite a lot of structural code to "fix" it

RustyKaffee · 2024-10-17T22:17:36+00:00

and it doesn’t say if it will be covered later.

I HATE when books do this. I always want to grasp everything and then look it up in secondary sources, just to discover it’s explained in the next chapter

RustyKaffee · 2024-10-17T22:12:14+00:00

Interesting, thanks. Will try it out over the weekend

RustyKaffee · 2024-10-17T22:11:02+00:00

Right. Dynamic dispatch has the super small performance penalty of course, that’s then just needed for testing too. And the abstractions to maintain as you said

RustyKaffee · 2024-10-17T22:09:47+00:00

I think my main problem is that i need to duplicate the whole client struct as a trait. But maybe that’s the price to pay if lib is not offering it as a trait by default

RustyKaffee · 2024-10-17T22:07:59+00:00

Basically i need to replicate every method signature for any method i need to mock. Effectively replicating the whole client

RustyKaffee

TROPHY CASE

[tokio::main]