The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d819...) file which is 3.2K lines long and has close to a 100 unsafe calls, isn't that just interacting with wry which has it's own crate you could use instead? I'm not 100% sure, but seems to be basically the same as wry itself but without the cross-platform stuff, is that the purpose of that file?
Together with the author's distaste for Rust, it seems awfully dangerous instead of pulling in a crate made by Rust developers, but I might misunderstand the purpose of the file here.
I believe that is wrapping the Wry crate (and a few other crates) in a C API that can be accessed over FFI (which can then presumably be called directly be Swift code).
Thanks for helping me understand! So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?
Shouldn't this kind of work be upstreamed to the original project, though? It would enable wry to export a libwry.so dynamic library for general use in any language that can FFI with C.
As someone who understand the sentiment, I wouldn't call it distaste for Rust. It feels more as Rust not being the right tool for the job and to be honest I have the same feeling here. Rust is great for a bunch of problem domains, but it doesn't feel to be the best tool for this specific problem domain.
It's always about the choices a programming language makes, it make it good for some use-cases and bad for others and there's nothing wrong with it.
Also as a cautionary tale about panacea programming languages, Java once tried it with great success to be "the one" language to rule them all and we can see that even though it was a popular choice in many domains, slowly other fitting solutions to specific problem domains took over. Proving that there is no such a thing, unfortunately for us, but some languages gets closer than others (Rust being one of them).
The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d819...) file which is 3.2K lines long and has close to a 100 unsafe calls, isn't that just interacting with wry which has it's own crate you could use instead? I'm not 100% sure, but seems to be basically the same as wry itself but without the cross-platform stuff, is that the purpose of that file?
Together with the author's distaste for Rust, it seems awfully dangerous instead of pulling in a crate made by Rust developers, but I might misunderstand the purpose of the file here.
I believe that is wrapping the Wry crate (and a few other crates) in a C API that can be accessed over FFI (which can then presumably be called directly be Swift code).
Thanks for helping me understand! So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?
> So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?
Yep, that sounds about right to me. Although it looks like that file is also wrapping Tao (which is a cross-platform windowing/event loop library).
Shouldn't this kind of work be upstreamed to the original project, though? It would enable wry to export a libwry.so dynamic library for general use in any language that can FFI with C.
> Together with the author's distaste for Rust
As someone who understand the sentiment, I wouldn't call it distaste for Rust. It feels more as Rust not being the right tool for the job and to be honest I have the same feeling here. Rust is great for a bunch of problem domains, but it doesn't feel to be the best tool for this specific problem domain. It's always about the choices a programming language makes, it make it good for some use-cases and bad for others and there's nothing wrong with it. Also as a cautionary tale about panacea programming languages, Java once tried it with great success to be "the one" language to rule them all and we can see that even though it was a popular choice in many domains, slowly other fitting solutions to specific problem domains took over. Proving that there is no such a thing, unfortunately for us, but some languages gets closer than others (Rust being one of them).
A "port" or "a nice Swift API for it"? It seems like the latter in that it requires cargo (the rust build chain) to build.
It uses the Tao and Wry crates the same as Tauri does. So it's a port of Tauri but not of its dependencies
Ah, thanks for the clarification.
Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/
Eh. Dioxus to me is the more interesting project honestly.