Swift seems like one of the biggest opportunities for the Linux application development world. It seems to pair nicely with Zig in a few ways.
In general, Swift complements systems languages pretty well from a feature perspective. It means that systems languages are for systems programming, and Swift is for applications. And Swift does scripting well too.
- Swift and Zig are a really good fit for Linux contexts.
- They are good with each other in terms of feature coverage.
- Swift should get good interoperability from Zig, maybe Rust too
- It should also be worked on in a serious and dependable way, by a group other than Zig and/or Swift - a group who is interested in piecing all these things together, that also intends to sustain their work for a while.
- Part of this effort is to make Swift seriously interoperable with Zig on Linux, as well as make Swift very interoperable with a serious native Linux GUI tool like Qt or GTK, or maybe Iced if that pairing is not too strange of an abstraction or too far away from native performance and code translation.
Dethroning C and C++
Under this premise that indeed C and C++ need to be replaced with safer alternatives, it really makes sense to fill in applications development with safe alternatives as well. Many would be nice, but there needs to be a concerted group effort to build up one languages interoperability and presence for applications development (be it Swift or perhaps Nim).
Of course safety is not the only reason, and the prospects of using languages that have the right features, compilation, and ergonomics makes a lot of sense in general.
It's just that safety is really that straw that brakes the camels' back. You just want to make sure that if you're upgrading something like this anyway, it is very important to do it right. This means not only changing simply the safety by itself, but taking the opportune moment to bring in languages that have all kinds of [the right] advantages.
The Logic of Swift
If Rust is weird, and its weirdness is justified in order to accomplish what it accomplishes, then it becomes needlessly weird for applications development, which could just as well use garbage collection of some kind, while using a language that is readable and attractive to applications developers, as well as being only just barely shy of having systems level performance. This is Swift.
Swift basically nearly has the range of C++, which itself should have never succeeded as a systems language anyway.
My general take is that systems languages should be basic, while the conveniences of applications languages should mean that they have a greater range of purposes. In this way, more basic systems languages then have the ability to be implemented at will, when the efficiency especially calls for them. (This is another reason Zig is logical to pursue . . . Because Rust is not necessarily a quick stand-in language.)
If Rust is a systems language, then why is Rust trying to replace applications development, when you could just use another method for safety when going to a higher layer than systems programming.
Swift is so logical. It needs to make a strong presence on Linux for safe applications development. And integrate with existing C and C++ applications, and toolkits like GTK and Qt - perhaps Iced if it makes sense.
It is just as imperative for Linux to have this, as kernel safety is imperative.
The Logic of Zig
The rationale for Zig is very straight forward. It is to fill the void of C and C++ project augmentation, where re-writing in Rust might be an eventual goal, but it is not feasible in the short term, or perhaps ever.
It is not always imperative to use Rust, and Zig is a very straight forward means to accomplishing a critical niche of modernization above the systems level as well.
Zig is very concise in its straight relatability of the low-level system. It does a better job than C and Rust - and it has created a platform mobility that also rivals other languages. This is critical to a system having full language capabilities, and it should provide a fallback in those cases, over C being the only fallback in those cases.
One of the biggest reasons that Zig has a certain kind of potential is because of its kind of portability and independence from other dependencies: very key as I see it.
Modern Linux Native
If you want people to develop for a platform, then you create tools that will facilitate that kind of development. Swift is made for the exact space that Linux is lacking in - a modern applications language.
Swift's learning curve and performance profile make it great for people looking to get into applications development
Swift is ready ready ready, but it desperately needs a GUI for Linux.
Swift needs to become a first class citizen with GTK or Qt, or even Iced. This is either through these respective projects, or by a different group of people who see the value of it, and can put a significant effort into a lasting, group commitment.
SwiftUI is NOT IT for Linux per se. Swift needs something like basically Qt, if not exactly Qt compatibility, or GTK - and in a big way. Swift needs to have performance GUI in mind.
SwiftUI is made for trimmed down simplicity, which is not the same as a solid foundation for Linux application development. Iced is made specifically for Rust, and I don't know if it would work well with Swift. But if there's nothing wrong with it in particular, then maybe it's actually a good choice to work towards maturing, while also maturing Iced.
Zig also needs to be a part of this GUI equation, especially if it involves using GTK or Qt. Because Zig integrates with C and C++, then making Zig a part of GTK and/or Qt makes a lot of sense.
If these GUI tools slowly merge into stable Zig code, and Zig has good interop with Swift, then they would be fantastic with Swift's memory safety, to create modern applications on Linux.
Swift Does Scripting For Real
Apparently:
- These systems languages are 15% - 30% faster than Swift
- Swift is 200% - 400% faster than Python
And Swift does scripting surprisingly well. It is not a drop-in replacement for Python. However, the thing that makes Python slow is not something that can be fixed with a replacement. And the thing that makes Python slow is the thing that makes it very easy to run. In other words, nothing will replace Python without having the same problems.
But considering this, Swift does about as good a job as one could imagine for what it is technologically, compared to Python. It is very easy to create and run scripts with Swift. The build times are cited as an issue.
I assume Swift also has good Python and Lua interop as well.
Swift and Zig
In a way, Zig seems almost like a follow-up to Rust adoption by Linux. I don't necessarily mean for kernel development, but then again, why not eventually.
Zig is important, because it represents an alternative to completely re-writing stuff, as with Rust. This is a good thing with Rust. But it is bad to make it the only alternative.
And Zig has the features that make it a language worth aspiring towards widely, specifically because of this reason.
I could even see ten years down the line, somebody creating a modular borrow checker for Zig to use. Now, that might be ridiculous, because as with Rust, the language might have to be built to do things "the borrow checker way", not necessarily just "the Rust way". (meaning that you could not just tack on a random borrow checker onto a language like Zig) But I wouldn't be surprised if that turned out to be possible in some way.
In any case Zig has increased safety measures over C and C++ - just not specifically a borrow checker.
Especially with Zig's efforts towards simplicity, and detailed transparency, and heightened manual safety, Swift seems like the perfect match with Zig almost like a pairing of languages - in order to achieve modern coverage of features on a system that wants developers to join and be enthusiastic about development.
Whereas Zig is very very manual and low-level for everything, Swift really fills the remaining void of applications development with automatic memory safety etc. And both languages can be comprehended by developers, and by people reading the code.
It would be great to see people trying to achieve interop between Swift and Zig in compilation and calls and GUI, etc.
Swift and Rust
Swift and Rust are also a thing. But it's boring to just have Rust be new, and then to not do Zig as well. The thing is that C needs something very much like Zig that could potentially compile with it and blend well with old C and C++ projects.
No comments:
Post a Comment