> Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. Developers can integrate any frontend framework that compiles to HTML, JavaScript, and CSS for building their user experience while leveraging languages such as Rust, Swift, and Kotlin for backend logic when needed.
Miguel de Icaza is kind of a legend, I know him most from his work on Mono and Gnome. Whatever he works on today will likely be part of a stack you work on in a few years (at least that's my experience).
Related, for everyone interested into Godot + Swift, check out https://github.com/johnsusek/SwiftGodotBuilder I think Swift might soon be a crazy ergonomic language to make Godot games.
respect to icaza for his contributions (tho I was on the KDE side of the gnome/kde desktop "wars"), but has the "Whatever he works on today will likely be part of a stack you work on in a few years" been true for a long time?
After successfully getting Xamarin acquired by Microsoft, apparently he got disappointed how everything turned out, especially the decisions that lead to the Xamarin.Forms to MAUI rewrite, MonoDevelop being killed, or what is left of Mono/Xamarin.
Nowadays he is full into Apple and Swift ecosystem, doing apps, and contributing to Godot on Apple, making it Swift first with goodies for doing iPadOS based game development.
Unity engine , the most popular game engine based on mono. Also gnome software like glib , cairo , harfbuzz prolly used as foundation by all OSes, gui toolkit, programming language or browser on the market.
It's likely you do use Mono or a successor. The modern dotnet framework is a descendent of Mono and is used in a variety of websites, games, and other applications.
To anybody with experience, how's Swift? Especially outside MacOS/iOS programming. Let's say I want to use it standalone for doing some systems programming, how's the standard lib? I'd like to not rely on apple specific frameworks like uikit
One of the biggest issues I ran into years ago was debugging outside of macOS was a nightmare. Even now, debugging is a terrible experience on a non-trivial project. I am not really sure if it the size of the projects I've worked on, interop with objc, compiler configs, project configs, or what, but it has always been a bad experience. I used it on/off for a project on Linux and the debugger didn't work at all. This was so long ago I am sure that has changed but at least so far in my experience, lldb will stop working at some point. I've worked on large Obj-C and C++ codebases and never ran into any of the problems I've run into with swift in this area.
Apple really needs to decouple swift debug and profiling tools from Xcode. I've been using vscode for swift work but hate having to switch back to Xcode for the tools.
As a language, I really like it. It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
The standard library is pretty good but the extended ecosystem is not as strong outside of Apple platforms, though that is improving.
If the ecosystem improved, like this project here, it would probably be my go to language. Failing that it’s usually rust , Python, C# and C++ for me.
UI libraries outside of Apple frameworks is about as weak as all those other languages if you don’t have Qt bindings. Qt does have Swift bindings officially in the works though so that could change.
> It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
Rust can be just as ergonomic. It takes some minor boilerplate of course, since you're resorting to coding patterns that are somewhat unidiomatic - but not nearly as much as the likes of C# or Java.
Could be better, think .NET Core 1.1 timeframe when Microsoft finally decided to make it cross-platform.
You get the bare bones standard library, some of it still WIP, and naturally most libraries were written expecting an Apple platform.
Windows workgroup was announced yesterday, and Linux support is mostly for macOS/iOS devs deploying some server code, because naturally OS X Server is no more.
Not quite systems programming but this might give you some insight. Swift is memory efficient, and runs stable backend services. I've seen benchmarks showing that it's slightly more performant than typescript but twice as memory efficient (but not as efficient when it comes to memory management compared to Rust, C, and C++).
The other point I've seen is that its string library is slow and very accurate.
Besides that, the C-interop means you have quite a bit of flexibility in leveraging existing libraries.
>The other point I've seen is that its string library is slow and very accurate.
Swift strings default to operating on grapheme clusters, which is relatively slow. But you can always choose to work with the underlying UTF-8 representation or with unicode scalars, which is fast.
The only situation where UTF-8 incurs overhead is if the String comes from some old Objective-C API that gives you a UTF-16 encoded String.
Being only slightly more performant than an interpreted GC-only language is hard to believe (even though typescript is just a spec and you probably meant slightly more performant than v8).
It's lovely, not “always has been” but since, say, 5.10.
// I'm an originally Pascal and assembly dev (learned most Internet dev langs along the way) who hated what people did with Java (until last 5 years), failed to like Ruby, liked Clojure, disliked go, did like Nim, but really found Swift to be fresh air for data shapes and flow. And the tooling experience with git repo to iCloud build to testflight is worth every penny of the annual dev fee.
About 5-6 years ago, I worked a fair bit on an iOS app, primarily in swift (there were some obj-c and C++ bits). Until then, 90% of what I had written was either C++ or python on Linux, and I had never worked on a mobile app and had barely used MacOS (or iOS for that matter, I've always had android phones). From that experience I had an unexpectedly favorable impression of the swift language. I thought the ergonomics of the typing system and error handling compared quite favorably to C++, with better performance and safety compared to python. I didn't really like the Apple frameworks though, it felt like they were always making new ones and the documentation was surprisingly poor. Nor did I really gel with XCode (which is virtually a requisite for iOS development) or MacOS itself. But I actually liked swift enough that I give it a try outside of ios for a few test apps. Unfortunately, at the time swift outside iOS wasn't really mature and there wasn't much of an ecosystem. Not sure how much that has changed, but these days I'd probably reach for rust instead.
I tried using it on Windows, but it failed to compile as soon as I used file IO. The error was non-descriptive and had no matches online. I couldn't figure it out so I tried it without file IO, but as others have said the compiler is odd, the errors are odd, and in general doesn't feel like the tooling is nearly as good as most other popular languages
It’s a lovely language but the compiler has got to be the most unreliable I’ve ever seen.
It crashes semi-frequently. And it will sometimes try to run analyses that are way beyond O(n). So you can have perfectly valid code that it can’t compile, until you simplify or reduce the size of some function.
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).
Swift is a great language for app development, and many app developers already know and use it on iOS, macOS, and Android and want to use it for more platforms too.
Swift users aren’t choosing between Rust and Swift. They’re looking to use Swift more. I think that’s why this is valuable - it doesn’t need to be centered around why one wouldn’t use Rust.
I don’t distrust rust, I think it is great for some things. But I write code to enjoy myself and swift hits the spot between safety and satisfaction for me.
Have built a cross alternative tailscale gui client based on tauri, the rust and ffi to cgo tailscale feel a little tough, I was wondering it will save a lot time to me if the tauri had been written in go.
Seems Miguel’s velox point a new idea, leveraging the wry and use ffi to go, and rewrite some tooling.
I hope I will have the spare time and energy to give a try…
I asked the author about whether this could be ported to support Android/Linux/Windows and he was optimistic it would not be much trouble. So I plan to look into that.
What I’d like to determine first is if I can use this for brownfield development: on Apple platforms I’d like to stick to native SwiftUI and use Velox only for some views inside of a SwiftUI host application. And then on other platforms it can be fully Velox.
I can’t find any info on people doing this with Tauri. Expo recently added this about a month ago for React Native but I’d prefer to use Swift everywhere. I appreciate any info.
I have always felt like Swift is the king of application development. The syntax and ergonomics really lend itself to UIs and the like. It's a shame that the Swift compiler is on the slow side.
The best way I've found to mitigate the compiler speed issue is to factor my application workspace into different sub-projects, so that the sub-projects don't get built every time I make a change. It makes a huge difference and, honestly, it's something I should have been doing anyway, just for good architectural layering.
I understood the point of Tauri is to write the apps with Typescript and web tech and to NOT have to write Rust or even know Rust. So why would it need to be ported to Swift when the point of Rust in Tauri just so the devs themselves or the wider community can write the base and plugins and stuff in Rust and the apps the general dev writes with it are written in TS?
I looked at Tauri like an Electron alternative that in the future will run with Servo under the hood.
He specifically says he likes Rust, just not for GUI app development. He also puts that on himself rather than blaming the language.
Which is not a hot take by any means, even in the rust community. A lot of UI based app paradigms don’t map easily to rust, outside of immediate mode UIs.
For the uninitiated:
> Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. Developers can integrate any frontend framework that compiles to HTML, JavaScript, and CSS for building their user experience while leveraging languages such as Rust, Swift, and Kotlin for backend logic when needed.
https://v2.tauri.app/start/
Miguel de Icaza is kind of a legend, I know him most from his work on Mono and Gnome. Whatever he works on today will likely be part of a stack you work on in a few years (at least that's my experience).
Also, let's not forget he's the one who brought Swift to the Godot engine https://github.com/migueldeicaza/SwiftGodot
Related, for everyone interested into Godot + Swift, check out https://github.com/johnsusek/SwiftGodotBuilder I think Swift might soon be a crazy ergonomic language to make Godot games.
respect to icaza for his contributions (tho I was on the KDE side of the gnome/kde desktop "wars"), but has the "Whatever he works on today will likely be part of a stack you work on in a few years" been true for a long time?
i'm rather unfamiliar with his work post-mono.
After successfully getting Xamarin acquired by Microsoft, apparently he got disappointed how everything turned out, especially the decisions that lead to the Xamarin.Forms to MAUI rewrite, MonoDevelop being killed, or what is left of Mono/Xamarin.
Nowadays he is full into Apple and Swift ecosystem, doing apps, and contributing to Godot on Apple, making it Swift first with goodies for doing iPadOS based game development.
4 replies →
He also wrote (or at least started) midnight commander!
Thank you. I've used mc since my slackware days and still use it. I never new Miguel wrote it
He was also a shill for Microsoft back when they were trying to destroy Linux.
The way he was handled was another loss for the Year of Desktop Linux, but who cares, lets use Proton and call it "Linux" gaming.
"What Killed the Linux Desktop"
https://tirania.org/blog/archive/2012/Aug-29.html
"How I ended up with Mac"
https://tirania.org/blog/archive/2013/Mar-05.html
If I don’t use Mono or Gnome, what else from him is part of my stack today?
Unity engine , the most popular game engine based on mono. Also gnome software like glib , cairo , harfbuzz prolly used as foundation by all OSes, gui toolkit, programming language or browser on the market.
4 replies →
It's likely you do use Mono or a successor. The modern dotnet framework is a descendent of Mono and is used in a variety of websites, games, and other applications.
3 replies →
To anybody with experience, how's Swift? Especially outside MacOS/iOS programming. Let's say I want to use it standalone for doing some systems programming, how's the standard lib? I'd like to not rely on apple specific frameworks like uikit
One of the biggest issues I ran into years ago was debugging outside of macOS was a nightmare. Even now, debugging is a terrible experience on a non-trivial project. I am not really sure if it the size of the projects I've worked on, interop with objc, compiler configs, project configs, or what, but it has always been a bad experience. I used it on/off for a project on Linux and the debugger didn't work at all. This was so long ago I am sure that has changed but at least so far in my experience, lldb will stop working at some point. I've worked on large Obj-C and C++ codebases and never ran into any of the problems I've run into with swift in this area.
Apple really needs to decouple swift debug and profiling tools from Xcode. I've been using vscode for swift work but hate having to switch back to Xcode for the tools.
Swift is pretty good.
As a language, I really like it. It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
The standard library is pretty good but the extended ecosystem is not as strong outside of Apple platforms, though that is improving.
If the ecosystem improved, like this project here, it would probably be my go to language. Failing that it’s usually rust , Python, C# and C++ for me.
UI libraries outside of Apple frameworks is about as weak as all those other languages if you don’t have Qt bindings. Qt does have Swift bindings officially in the works though so that could change.
> It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
Rust can be just as ergonomic. It takes some minor boilerplate of course, since you're resorting to coding patterns that are somewhat unidiomatic - but not nearly as much as the likes of C# or Java.
4 replies →
Could be better, think .NET Core 1.1 timeframe when Microsoft finally decided to make it cross-platform.
You get the bare bones standard library, some of it still WIP, and naturally most libraries were written expecting an Apple platform.
Windows workgroup was announced yesterday, and Linux support is mostly for macOS/iOS devs deploying some server code, because naturally OS X Server is no more.
Not quite systems programming but this might give you some insight. Swift is memory efficient, and runs stable backend services. I've seen benchmarks showing that it's slightly more performant than typescript but twice as memory efficient (but not as efficient when it comes to memory management compared to Rust, C, and C++).
The other point I've seen is that its string library is slow and very accurate.
Besides that, the C-interop means you have quite a bit of flexibility in leveraging existing libraries.
>The other point I've seen is that its string library is slow and very accurate.
Swift strings default to operating on grapheme clusters, which is relatively slow. But you can always choose to work with the underlying UTF-8 representation or with unicode scalars, which is fast.
The only situation where UTF-8 incurs overhead is if the String comes from some old Objective-C API that gives you a UTF-16 encoded String.
2 replies →
Being only slightly more performant than an interpreted GC-only language is hard to believe (even though typescript is just a spec and you probably meant slightly more performant than v8).
1 reply →
For web server benchmarks, it’s far behind typescript. Async has further degraded performance competitiveness
It also has C++ interop btw
Swift "feels" like C#. A lot of systems programming is done in C#.
Depending on your goals, it's worth giving C# a test-drive given Swift's similarity to C#.
Traditionally I would say it feels more like Ada, Modula-2, Object Pascal.
And if making reference counting part of the picture, Cedar, Modula-2+,...
Finally catching up with what we already had in the 1990's and lost, in a couple of decades split between C, C++ and VM based languages.
2 replies →
Here's what I wrote on this subject back in September. Nothing has changed so far as I can see.
https://news.ycombinator.com/item?id=45417366
Oh noes! Will someone ever figure out how to open a file on windows? I do t think we have the technology.
It's lovely, not “always has been” but since, say, 5.10.
// I'm an originally Pascal and assembly dev (learned most Internet dev langs along the way) who hated what people did with Java (until last 5 years), failed to like Ruby, liked Clojure, disliked go, did like Nim, but really found Swift to be fresh air for data shapes and flow. And the tooling experience with git repo to iCloud build to testflight is worth every penny of the annual dev fee.
About 5-6 years ago, I worked a fair bit on an iOS app, primarily in swift (there were some obj-c and C++ bits). Until then, 90% of what I had written was either C++ or python on Linux, and I had never worked on a mobile app and had barely used MacOS (or iOS for that matter, I've always had android phones). From that experience I had an unexpectedly favorable impression of the swift language. I thought the ergonomics of the typing system and error handling compared quite favorably to C++, with better performance and safety compared to python. I didn't really like the Apple frameworks though, it felt like they were always making new ones and the documentation was surprisingly poor. Nor did I really gel with XCode (which is virtually a requisite for iOS development) or MacOS itself. But I actually liked swift enough that I give it a try outside of ios for a few test apps. Unfortunately, at the time swift outside iOS wasn't really mature and there wasn't much of an ecosystem. Not sure how much that has changed, but these days I'd probably reach for rust instead.
I tried using it on Windows, but it failed to compile as soon as I used file IO. The error was non-descriptive and had no matches online. I couldn't figure it out so I tried it without file IO, but as others have said the compiler is odd, the errors are odd, and in general doesn't feel like the tooling is nearly as good as most other popular languages
Quite enjoyable. Some compiler errors are a pain.
What an understatement :)
It’s a lovely language but the compiler has got to be the most unreliable I’ve ever seen.
It crashes semi-frequently. And it will sometimes try to run analyses that are way beyond O(n). So you can have perfectly valid code that it can’t compile, until you simplify or reduce the size of some function.
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.
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?
1 reply →
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).
Swift is a great language for app development, and many app developers already know and use it on iOS, macOS, and Android and want to use it for more platforms too.
Swift users aren’t choosing between Rust and Swift. They’re looking to use Swift more. I think that’s why this is valuable - it doesn’t need to be centered around why one wouldn’t use Rust.
I don’t distrust rust, I think it is great for some things. But I write code to enjoy myself and swift hits the spot between safety and satisfaction for me.
Your satisfaction might be different, enjoy it!
Have built a cross alternative tailscale gui client based on tauri, the rust and ffi to cgo tailscale feel a little tough, I was wondering it will save a lot time to me if the tauri had been written in go.
Seems Miguel’s velox point a new idea, leveraging the wry and use ffi to go, and rewrite some tooling.
I hope I will have the spare time and energy to give a try…
Just in case you missed it and are interested in a go alternative https://wails.io/
I asked the author about whether this could be ported to support Android/Linux/Windows and he was optimistic it would not be much trouble. So I plan to look into that.
What I’d like to determine first is if I can use this for brownfield development: on Apple platforms I’d like to stick to native SwiftUI and use Velox only for some views inside of a SwiftUI host application. And then on other platforms it can be fully Velox.
I can’t find any info on people doing this with Tauri. Expo recently added this about a month ago for React Native but I’d prefer to use Swift everywhere. I appreciate any info.
I have always felt like Swift is the king of application development. The syntax and ergonomics really lend itself to UIs and the like. It's a shame that the Swift compiler is on the slow side.
Swift really does hit a sweet spot.
The best way I've found to mitigate the compiler speed issue is to factor my application workspace into different sub-projects, so that the sub-projects don't get built every time I make a change. It makes a huge difference and, honestly, it's something I should have been doing anyway, just for good architectural layering.
This recent project looks interesting for improving build times without having to abandon SPM: https://xccache.trinhngocthuyen.com which is a UI for managing https://github.com/trinhngocthuyen/xccache
I understood the point of Tauri is to write the apps with Typescript and web tech and to NOT have to write Rust or even know Rust. So why would it need to be ported to Swift when the point of Rust in Tauri just so the devs themselves or the wider community can write the base and plugins and stuff in Rust and the apps the general dev writes with it are written in TS?
I looked at Tauri like an Electron alternative that in the future will run with Servo under the hood.
Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/
Eh. Dioxus to me is the more interesting project honestly.
Could it feasibly be wrapped or ported to Swift?
It doesn't tick the “I dislike Rust” box which is apparently the main motivation for this project.
He specifically says he likes Rust, just not for GUI app development. He also puts that on himself rather than blaming the language.
Which is not a hot take by any means, even in the rust community. A lot of UI based app paradigms don’t map easily to rust, outside of immediate mode UIs.
11 replies →