Use Rust (instead of C++) to develop some algorithms used in Flutter in a real app used in the *production environment* - Is it mature enough? Will I face troubles? Do you suggest it? Has anyone used it?

You are right, but this is actually part of my point: why can't Apple keep their installation of LLVM in their own toolchain up-to-date enough so that it isn't completely puzzled by relatively recent versions? Rust doesn't use the absolute cutting edge LLVM either.

1 Like

At the moment, the latest Xcode release and the latest Rust release do use the same version. And I'm pretty sure there have been problems in the past caused by Xcode using a newer LLVM than the stable Rust toolchain. The issue is not just that one project is slow and the other is fast. It's that there will always be mismatches as long as they don't upgrade at precisely the same time.

5 Likes

Note also that LLVM 13 was scheduled for release on September 21, 2021 (which was already after the latest Xcode release), but it appears to have been delayed because it hasn't been officially released yet. It seems unreasonable to expect the current version of Xcode to support LLVM 13 before it is even released.

In this case, Rust's beta toolchain is on the cutting edge.

4 Likes

Mm, okay. I recall this not being the norm though? I specifically remember that around a year and a half ago, someone complained that the LLVM packed with Rust is somewhat old and not being updated. Perhaps there was a shift in policy since then, which I missed.

1 Like

Yeah, I think perhaps the divergence between Rust's patched LLVM and the mainline version has decreased over time, allowing Rust to track upstream more easily.

3 Likes

@geeklint Sure. But I think I have to

Anyway, from the suggestions mentioned above, I will firstly write down a normal version, and see by godbolt, whether Rust is already smart enough to vectorize it!

There are also some community crates that enable some SIMD functions on stable.

Could you please hint the names? I find GitHub - rust-lang/portable-simd: The testing ground for the future of portable SIMD in Rust but that requires nightly. And find faster/src/arch at master · AdamNiederer/faster · GitHub (which seems quite interesting), but its arch folder only has x86 and unknown - no arm.

@dcow-uno Thanks for the information! I will have a try first.

I have tried to implement a very simple component in my full algorithm: calculate the local mean and standard deviation given the cumulative sum and cumulative sum of squares of the image.

The compiler does not seem to generate code of NEON automatically, though... Is there anything that I do wrongly?

Code: Compiler Explorer

@dcow-uno Hi, I wonder how you deal with back traces (stack traces) in iOS? Do you use it or not?

The post with more information is here: Anybody using backtrace (capture stack trace) in Android/iOS? Should backtrace be used in production environments (mobile phones)? Seems that iPhone (with ARM) does not support backtrace at all?

Thank you!

Right now I think we are just including debug information in the binary since we aren't concerned with obfuscation or raw performance. The errors rust prints when it panics include filename/line number which has been enough thus far... well and then there's the fact that our rust code has never been incorrect anyway save one spot in our C ffi in where I messed up and tried to store to a nonexistent index in a Vec instead of creating the Vec to be the size I needed first and then writing the value, so your traditional index out of bounds. In other words, our rust code has never crashed or needed anything beyond trivial print "debugging" and some sanity grade functional tests. Knock on wood.

2 Likes

@dcow-uno Thanks! So do you use it in production environment, i.e. already on app store? And do you use Result (such as anyhow's Result) and enable the backtrace feature to see where the result comes from?

Yes I use rust nightly with "unstable" apis and the anyhow crate for error handling in production in an iOS app. Frankly I have never seen our rust code fail in production so I honestly have no idea.

1 Like

Wow you write really robust code - never see an anyhow::Error???

He probably means that it doesn't fail in unexpected ways, i.e. it doesn't panic or has bugs that result in an Err(...) when they shouldn't. Often, an Error is a perfectly valid result of a bug-free program — e.g. if your app does any Internet pinging, it's not wrong not to be able to send an HTTP request successfully when the Wi-Fi is cut off.

1 Like

@H2CO3 Sounds quite reasonable. My question is whether backtrace is used (in anyhow Error) in production environment, because it seems that running production env without stack traces can be very hard to trace bugs, while I find the backtrace seems not that stable.

Wow you write really robust code - never see an anyhow::Error ???

He probably means that it doesn't fail in unexpected ways, i.e. it doesn't panic or has bugs that result in an Err(...) when they shouldn't.

Yes. What I mean is that the rust compiler is so pedantic that it essentially won't let your write code that fails in unexpected ways like you're used to in other languages. This is half the reason to use Rust. Rather than fighting your code at runtime you fight the compiler at compile time. It's a pretty noticeable difference if you ask me. Your code takes longer to write, but at least for us it's pretty much been ship and forget after that.

That's all to say, you should probably be handling errors you encounter in code not sending every Err result to whatever bug tracker you use. Only when you encounter an unexpected error that you can't handle should you need to do anything with it. Perhaps you have a very different application and use case from me where you expect to encounter many more errors you can't handle, and that's fine. I'm just sharing my experience and reiterating that I haven't had a runtime problem with our Rust code literally ever.

2 Likes

Thanks! Indeed mine do have some unexpected errors. One of the reasons is because it uses opencv-rust a lot. OpenCV's matrix is very dynamic, e.g. continuous or not, matrix type, matrix size, etc, are all runtime info. Thus, we have to check at runtime whether the matrix's info is satisfied for a function and that can create unexpected errors.