4 ms·

This seems a very interesting addition to the Rust ecosystem. I wonder how much traction it will get, though. Some days ago there was an HN thread about Rust,

by j1elo 4y ago

This seems a very interesting addition to the Rust ecosystem. I wonder how much traction it will get, though. Some days ago there was an HN thread about Rust, conversing about the steep learning curve of Rust. The conclusion frequently is that maybe Rust is great for financial systems, kernels, rendering engines, media processors, etc... but just not necessarily the best tool for the job when there is no pressing need to avoid GC, and/or to squeeze the maximum performance while at the same time maintaining memory correctness. Which, on the other hand, tends to be the immense majority of application development out there... So Tauri seems to me has a similar issue than the Qt Framework (built on and for C++): its adoption as an Electron alternative might not be as much as it deserves, because of the difficult to learn programming language that is behind it. Thoughts? EDIT: I know Tauri is just a WebView component, but programming in Rust still seems to be an important part of developing apps with it (it is even prominently featured in the 100 seconds video of the entry)

flohofwoe 4y ago
Tauri is "just" a system webview wrapper. It's an interesting alternative to Electron for some applications because the installer is much smaller, but it also has downsides compared to Electron (the system web view will be updated independently and may unexpectedly break the application). As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
- brabel 4y ago
  There's a communication channel between the Rust code and the JS running in the browser. It's possible to move as much functionality to Rust as you want... It's even possible to compile Rust to WASM to use that in the "frontend" though that from my experience is very cumbersome due to the Rust bindings for the Web API being pretty terrible.
- Humphrey 4y ago
  > As far as I understand, applications are not written in Rust but in HTML/CSS/JS. Frontend UI yes. But enables you to use rust for your background worker (Electron apps use node for the background worker)
anoopelias 4y ago
For electron based apps, most part of the codebase runs on the chrominum front-end - written in JavaScript / HTML. Usually only some critical code runs on the node backend. As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself. From that sense I feel this is a good tradeoff.
- j1elo 4y ago
  Well I agree that it is already a good tradeoff, being able to offload the most intensive tasks to Rust, which is really performant. However my perspective is that of a C++ developer already, so I like Rust as a "better C++"... it's just that I'm not sure others will see it with such kind eyes :-) On a tangent, I've been forced to learn and use Swift the last couple weeks, and to my surprise it has been a delight! If it had a more cross-platform spirit, I think I might have found a new favorite of mine for general application development.
- the_duke 4y ago
  > the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem That's a decision the developer has to take, but I'd rather see it as the opposite: the sensible approach is to run just the UI related things in Javascript, and run almost all of your business logic in Rust.
  - crabbygrabby 4y ago
    That's how I use it too, mostly because I personally find JavaScript and typescript frameworks harder to use than rust. Managing data in js is hard for me without static typing. Everyone will have different comfort levels but I agree, business logic in rust, front end in js is a great separation.
crabbygrabby 4y ago
You can use tauri without concerning yourself with rust at all. You can use typescript or JavaScript. Optionally if you want too you can write backend stuff that needs to go fast in safe or unsafe rust. It's kinda dreamy if you need to access drivers, or other things that are very uncomfortable to do in js. When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language. People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.
BiteCode_dev 4y ago
You can sidecar any exe. E.g: side car a python fast api service that mimic a website api you call from ajax in the JS.
e63f67dd-065b 4y ago
This is a known downside: rust forces you to write correct code, and will refuse to compile until you prove to it that you don’t have data races, all errors are handled, etc. If it’s a one time script, I still whip out the trusty Perl one-liner, because correctness doesn’t matter. I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen. Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.
- j1elo 4y ago
  > rust forces you to write correct code And to that extent, due to the lack of GC, you need to provide it (and keep in your head) with lots of extra information that wouldn't be needed with other languages. I find that Rust is too strict because it assumes concurrent multithreaded code by default. Which wouldn't be needed for most desktop apps. Why no circular refs or having a mut ref and a ref at the same time, in my simple single-threaded To-Do list Tauri app?
  - tene 4y ago
    I disagree, and I'd be fascinated to hear more of your perspective here. I love Rust precisely because I can keep extra information out of my head. When I express something with the type system, I can stop tracking it mentally, and just rely on the compiler to keep track of it for me. With dynamic languages, I have to track far more mental state. "Mutable xor shared" does not have anything to do with concurrency or threads. Here's one example in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a6d5af0b8995603154e448e0fd4a167d https://play.rust-lang.org/?version=stable&mode=debug&editio... If this were permitted, then this example would have use-after-free whenever myvec reallocates its storage. No concurrency needed. I'm not sure what you have in mind for circular references, but I don't know of any complications with circular references that have anything to do with concurrency.

by j1elo 4y ago

flohofwoe 4y ago

Tauri is "just" a system webview wrapper. It's an interesting alternative to Electron for some applications because the installer is much smaller, but it also has downsides compared to Electron (the system web view will be updated independently and may unexpectedly break the application). As far as I understand, applications are not written in Rust but in HTML/CSS/JS.

brabel 4y ago
There's a communication channel between the Rust code and the JS running in the browser. It's possible to move as much functionality to Rust as you want... It's even possible to compile Rust to WASM to use that in the "frontend" though that from my experience is very cumbersome due to the Rust bindings for the Web API being pretty terrible.
Humphrey 4y ago
> As far as I understand, applications are not written in Rust but in HTML/CSS/JS. Frontend UI yes. But enables you to use rust for your background worker (Electron apps use node for the background worker)

anoopelias 4y ago

For electron based apps, most part of the codebase runs on the chrominum front-end - written in JavaScript / HTML. Usually only some critical code runs on the node backend. As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself. From that sense I feel this is a good tradeoff.

j1elo 4y ago
Well I agree that it is already a good tradeoff, being able to offload the most intensive tasks to Rust, which is really performant. However my perspective is that of a C++ developer already, so I like Rust as a "better C++"... it's just that I'm not sure others will see it with such kind eyes :-) On a tangent, I've been forced to learn and use Swift the last couple weeks, and to my surprise it has been a delight! If it had a more cross-platform spirit, I think I might have found a new favorite of mine for general application development.
the_duke 4y ago
> the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem That's a decision the developer has to take, but I'd rather see it as the opposite: the sensible approach is to run just the UI related things in Javascript, and run almost all of your business logic in Rust.
- crabbygrabby 4y ago
  That's how I use it too, mostly because I personally find JavaScript and typescript frameworks harder to use than rust. Managing data in js is hard for me without static typing. Everyone will have different comfort levels but I agree, business logic in rust, front end in js is a great separation.

crabbygrabby 4y ago

You can use tauri without concerning yourself with rust at all. You can use typescript or JavaScript. Optionally if you want too you can write backend stuff that needs to go fast in safe or unsafe rust. It's kinda dreamy if you need to access drivers, or other things that are very uncomfortable to do in js. When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language. People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.

BiteCode_dev 4y ago

You can sidecar any exe. E.g: side car a python fast api service that mimic a website api you call from ajax in the JS.

e63f67dd-065b 4y ago

This is a known downside: rust forces you to write correct code, and will refuse to compile until you prove to it that you don’t have data races, all errors are handled, etc. If it’s a one time script, I still whip out the trusty Perl one-liner, because correctness doesn’t matter. I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen. Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.

j1elo 4y ago
> rust forces you to write correct code And to that extent, due to the lack of GC, you need to provide it (and keep in your head) with lots of extra information that wouldn't be needed with other languages. I find that Rust is too strict because it assumes concurrent multithreaded code by default. Which wouldn't be needed for most desktop apps. Why no circular refs or having a mut ref and a ref at the same time, in my simple single-threaded To-Do list Tauri app?
- tene 4y ago
  I disagree, and I'd be fascinated to hear more of your perspective here. I love Rust precisely because I can keep extra information out of my head. When I express something with the type system, I can stop tracking it mentally, and just rely on the compiler to keep track of it for me. With dynamic languages, I have to track far more mental state. "Mutable xor shared" does not have anything to do with concurrency or threads. Here's one example in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a6d5af0b8995603154e448e0fd4a167d https://play.rust-lang.org/?version=stable&mode=debug&editio... If this were permitted, then this example would have use-after-free whenever myvec reallocates its storage. No concurrency needed. I'm not sure what you have in mind for circular references, but I don't know of any complications with circular references that have anything to do with concurrency.