Writing Gnome Apps with Swift
swift.org
swift.org
The key premise of this approach is to provide a SwiftUI-like declarative wrapper around Gnome functionality. It's unclear what it adds over swift-cross-ui.
SwiftUI itself has growing pains mainly around being on the right thread for processing/updates and getting data binding right.
Blog entries on swift.org or from Apple tend to be little demos that show the happy path, but when discussing new frameworks (like a Gnome wrapper) or platforms (like the recent embedded), I'd like more demonstration that the authors understand and address key issues and will sustain development. Cross-platform UI frameworks get complicated quickly and have a long tail of issues (cf Flutter, Java/Eclipse, et al) that can be blockers for clients/users. For Swift it doesn't help to have multiple concurrency models and obviously different behaviors on apple platforms and Linux (where UI is not officially tested).
Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is.
I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable
https://github.com/stackotter/swift-cross-ui https://github.com/TokamakUI/Tokamak
I’m also working (slowly) on native Flutter channels:
https://github.com/PADL/FlutterSwift
But this is really targeted at embedded use cases.
Do any of these have a good wkwebview equivalent
As an indie dev who quit my job to try to make it solo, I'll either need to wait until I have more revenue to afford this, or hopefully you add some indie-friendly tier for bootstrapped pricing (such as a discount on team size, or ARR like Apple does with its small business program).
> Educational institution, nonprofit, or business/individual with less than 250K USD annual revenue
I remember making some rudimentary accounting software for which I'm sure now the source is long gone.
"Miguel de Icaza and his ostracization from FOSS" https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bru...
"What killed the Linux Desktop" https://tirania.org/blog/archive/2012/Aug-29.html
"How I ended up with a Mac" https://tirania.org/blog/archive/2013/Mar-05.html
One might wonder how things would have turned out instead if the community had been more welcoming of his efforts on GNU/Linux.
What I mean by this is the legalities behind it.
Remember, my comment above is based on views 20 years ago. My perspective is that Microsoft cannot "beat" Linux purely as competition. It isn't going anywhere. While it may not be a concern in the Desktop market, it certainly dominates on servers! Microsfot are not stupid and see CONTROL through other means.
Imagine if most programs that come default in Linux distributions being C#? If more and more programs are written in C# (whether Mono or not) gives them power over the Linux user.
Today, Microsoft has .NET core (recent release .NET 8) and also replaces Mono. We still have Xamarin of course but that is getting replaced with MAUI. A lot of Microsofts software is now cross platform, like Powershell, SQL Server, etc. This "concern" I was having 20 years ago is still just as big of an issue today.
Imagine Microsoft getting the marketing right and SQL Server starts gaining momentum on Linux boxes. This means less using MySQL or Postgres.
Imagine is Powershell starts gaining more traction in Linux land rather than Bash.
Now -- I think this is EXTREMELY UNLIKELY to happen but you can garantuee this is a strategy. They have the money and manipulation skills to help make it happen. Big companies can easily eat this up and it starts with "but we can support you!"
Think about it -- WSL is easy to setup on Windows machines! More and more C# applications can easily be tested for Linux. Microsoft just gave you the tools, and letting developers/companies do the rest for them. Soon it is sheep follow sheep.
Bit of a long winded comment/reply - and while I do not share targeting hate towards anyone (I do not know Miguel personally but he seems like a cool guy) -- I just think efforts should have been elsewhere. Dlang could have been a really, really good replacement. My guess as to why Dlang didn't take off back them was the compiler was not open source. Who knows?
As usual, while Microsoft has its own actions to answer for, it isn't alone in making everything happen.
The Year of Desktop Linux comes packaged in desktop VMs, regardless if it is on Apple, Microsoft or Google's hardware.
That’s the developer side of things, then on the more operations side of things it’s hard to justify not using Powershell if you’re running a lot of Microsoft products. It integrates very well with everything your IT operations department does anyway from EntraID to Azure Automation, where you may be able to use Python as well, but Python is often not what Microsoft IT operations people “grew up with”. So unless other cloud providers have a strong Powershell presence on their IT operations side of things, using them, instead of using Azure, because a huge change management issue… Often one you can’t really solve, because a lot of IT operations people will rather find a different job than switch away from their Microsoft focused talents, and why wouldn’t they? Good cloud operations people are harder to find than basically anyone else in IT.
That said, Swift's implementation of borrowing seems significantly more user-friendly than Rust's. While this is very much an advanced feature, I'd expect it to be actually used in many cases where in Rust folks would resort to working around the borrow checking (via things like indexing into arrays and such). As a result I expect it to be significantly more useful.
I tried blueprint, and while I liked the format, I struggled with a lack of documentation on how to do some more advanced things. Gtk's .ui files are ok, but you still end up writing a lot of code to hook everything up.
While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI.
At that point, why not just do everything in Swift? What does Vala give you that Swift doesn't?
Kinda like using COM from Visual Basic 6 vs using it from plain C.
This trivial example lacks it, and places it simple logic inside the UI code. But what if we want to protect against negative numbers? Or want to increase the number with larger increments if we hold the button pressed? Etc.
Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic.
It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".
This is true for any library/framework/architecture, and the same problem is very prominent in Svelte/Vue/React/Backbone/Angular and everything else.
No. It's true for any library or framework that lack isolation or decoupling concepts.
In react (and many of the ones you mention) there is nothing on place that guides you into decoupling. It has nothing, not even conventions, that help a junior to put stuff in the right place (or to prohibit or make it difficult to put stuff in the wrong place).
Part of that is due to how in TS/JS everything can grope around in everything else. But the bigger part is lacking conventions, primitives and structure in the libs and frameworks.
Sure, a library (which react is) doesn't provide structure (it's a distinguishing trait from frameworks). But the many frameworks on top of React don't do a good job either. They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance. And in all situations, it's still possible to just fire a fetch() or put data transforms or business logic within the UI. Only discipline keeps people from taking this "much easier" route.
And when only discipline stands between us and "the easier way for now", that "easier way for now" will be chosen, and pain in future will be felt.
At least Redux provides a semblance of immediately grokable data flow, this all gets worse with mobx which gives you all the flour you need to make spaghetti for the whole village. Worked on a codebase where you might have to chase down references across all sorts of files you wouldn't expect because everything is 'observable' so people, working 2-week sprints, just stop thinking about any kind of coherent structure cause it works anyway.
I've seen too many react projects that employ all sorts of enterprise patterns (amongst which redux) yet also wrangling-spagetti of useEffect and useState, often intermixed. There's one thing worse than having to unknot a mess of useStates: thats having to unknot a mess of useStates that is sometimes synced to and sometimes from and sometimes both, a redux global state.
So basically, the same as Cocoa/obj-C?
Generally writing UI code in Xcode (and presumably before that on NeXT as well) is a breeze and a joy. Work with your delegates, connections, outlets etc.
And then how about version control? Sure there could be (and is) underlying machine code, and you could try hard to make it human readable. But... IDK seems like a lot of effort to me for some small benefits.
Disclaimer: I have only very little experience with UI programming.
I don't know about current Delphi, but in Lazarus (which is kind of an open source and crossplatform Delphi) you set those rules visually. For example you can "draw" the UI by drag-and-dropping controls in a window/containers/etc and then you can add rules like "this button's left side will be 5 pixels from that label's left side and will be placed vertically so that it is centered relatively to the label". You can also set things like "this control (or container or whatever) will always be at the top/left/right/bottom edge of its window/container". This is done in the visual editor with immediate feedback (you can even resize the window/container while you are editing its layout to see how it behaves).
This allows you to make UIs that work not only across dimensions, but also handle different fonts, texts (for localization), scaling (for DPI) and themes. Especially important for Lazarus since its GUI framework has various backends that often look very different from each other.
> And then how about version control?
Lazarus (and Delphi - with the exception of some earlier versions - and really most GUI designers) save UIs in a text based format with a tree-like structure of key/value pairs, e.g. (i edited it a bit for brevity):
object Main: TMain
Left = 625
Height = 505
Top = 393
Width = 903
Caption = 'World Editor'
Menu = MainMenu1
Position = poScreenCenter
object plRenderContainer: TPanel
Align = alClient
BorderStyle = bsSingle
object plRenderWindow: TPanel
Align = alClient
BevelOuter = bvNone
end
end
end
Look into how various design tools handle flexible layouts. Usually a combination of flexbox/something similar to flexbox or slightly more old-school; constraints.
Here is an example with Figma: https://gdwn.medium.com/how-you-can-create-really-flexible-a...
The window itself can have a layout control that stretches to fill the window regardless of resizing. Layout changes would cascade down through the tree of UI controls and everything would resize/reposition accordingly.
Not really in the case of Cocoa's Interface Builder (nib/xib files). There the artifact is basically a marshalled object tree of the actual UI objects, not declarative markup.
- Code-based UIs tend to work better with existing tooling, like comments and source control. You can freely customise your development environment, rather than being at the mercy of a single GUI app.
- Most serious UIs need code-like features, such as "for-each" to render a list of objects, or "if" to reveal a form when a checkbox is ticked. The easiest way to access code-like features is to write your UIs in code.
- You'll need to write some backing code in any case. Defining the UI tree and its "code-behind" in the same file could be considered more DRY.
- Live preview (or alternatively, hot reloading) will give you very quick iteration when writing a UI in code. It's not quite as good as drag-to-resize, but it's close.
- Automatic layout (which is non-optional nowadays) isn't necessarily a great fit for WYSIWYG editing.
- As React has demonstrated, the ability to quickly throw together custom components is extremely useful. Visual editors tend to make it more complicated and bureaucratic to define custom components.
- WYSIWYG editors are bad about making small unintended changes that can easily slip by undetected (Interface Builder in Xcode for example often changes XIBs/storyboards just by viewing them)
- WYSIWYG editors bury bits of configuration in inspectors that are only visible in certain conditions, e.g. a control being selected, making them less evident and more difficult to find
There are circumstances where I think they still work alright — for instance I still enjoy building Mac apps with XIBs in Cocoa, but there’s a reason for that: traditional desktop UI has much less of a need for flexibility and generally speaking, has far fewer moving parts since it doesn’t have to hide things as a result of limited screen real estate. Additionally, these apps will only ever run on Macs which further reduces need for flexibility/adaptivity.
For mobile and multiplatform on the other hand, I strongly prefer code. It just works better.
… assembles an appartments worth of new Ikea furniture…
Oh!
If you answer “brilliantly” I am genuinely curious to give it a go!
See it in action e.g. here:
Anyway, I went pretty deep on SwiftUI from the announcement, and started programming with Delphi 7 / Visual Basic 6. While I enjoy SwiftUI, it has some rough edges still, and it's been 3 or 4 years. Hopefully Apple can put things together this year, especially for macOS apps.
I agree that Delphi is leaps and bounds better than the web technology in popular use today, and every reason I've heard for why (increased DPI, variable screen sizes, etc.) are just poor excuses.
The web is where the money was, development approaches forked, and now the worse approach happens to be more popular.
I can't decide whether it's sad or funny what Microsoft is trying to do with Blazor. They solved their Desktop UI problems by offloading them to you with a browser (now you have the problems).
Here's Andreas Kling briefly demoing both and talking a bit about it: https://www.youtube.com/watch?v=1QYBvTy9QKE&t=519s
The difference might sound trivial but in practice it is like trying to dismiss editing text with Emacs by experiencing editing text in Notepad.
[0] https://adkaster.github.io/images/build/VisualBuilder.png
But the question here is also if it makes sense to basically have the same UI or even UI paradigms for such different types of environments.
> On top of this example I’d add Arc for macOS and Windows.
Didn't development of Arc stop like a really long time ago? Anarki seems to be where development is at nowadays.
I will admit, Swift syntax is an acquired taste, but once you're familiar with all of the concepts (and understand that some design decisions were made for Objective-C interoperability), then it's a very usable language. To be frank, the only thing that stops me from using Swift is the fact that Linux support isn't as good as on Apple platforms. But if I am targeting nothing but Apple platforms, then Swift is probably the best choice, just for SwiftUI and SPM alone.
The Kotlin platform looks good and I've kept an eye on it, but the problem is, if I have to start working on an app now, it's still kind of scary, as you're basically just placing a bet on a horse race of which one will mature the fastest down the road.
At a previous job, I decided to adopt React Native in its early stages for a project. By some miracle (and with a lot of rolling-our-own) it managed to not hold us back and seemed to mature about as fast as we needed it to, but boy, even then it was still stressful, and I feel like we got a little lucky. (Just to be clear, I also knew this going into it and the choice was mine, I may just have a deathwish)
We have been porting to Jetpack Compose, and I really like it. It’s still got some growing pains. We don’t use ViewModels, hardly any Flow stuff, just mutable states and render trees and I’ve been pretty pleased. What makes me happiest is that it’s much more consistent. I don’t feel like I’m in a line at the DMV anymore; “oh you need that, go stand in that line and learn that stack, then come back”.
Like you, I’m extremely skeptical about the multiplatform siren. We tried it in Smalltalk land. The Java guys tried it and failed. I tried Flutter for a couple of apps, early testing iOS users were totally turned off (so fine for internal simple utility apps only). I would love it if someone really succeeded. We have 2 Swift UIKit apps I’ll have to convert to SwiftUI someday. So I will wish all that try well, but I’m not holding my breath at all.
Having a “write once run everywhere” pitch is about the same as politicians who run on “change”. It always sells; it never really delivers.
Compose is better for sure. I’m still figuring it all out but it’s a marked improvement.
Interesting. Why is that? I've been out of the Java loop for some years (although I did a fair amount of work with it earlier), so not up to date with this stuff.
Every single Gradle build system I have encountered in the wilds of GitHub has been broken on Fedora. I eventually realised it works if I run it in an Ubuntu container (using "toolbox"). So it's only portable if you bundle up the OS with your build system.
Now it should be portable. It's written in a JVM language and every Gradle project I have seen commits a copy of the Gradle JAR to its GitHub repo, which gives me those arbitrary code execution heebie-jeebies.
1. Every single gradle script is a unique snowflake of mishmashed plugins and custom functions
2. Gradle likes to pretend it is declarative, but as people very quickly learn it really isn't.
3. The one thing a build system is expected to do is be reliable in face of changing platform version, libraries and plugins. But gradle, being built on top a language on top of JDK itself has a Compatibility Matrix[0] that one has to be aware of. Often when upgrading a project you have to update JDK and gradle in explicit order, sometimes multiple times.
4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!
5. untyped groovy means you're forever left wondering whether what you wrote is actually correct until you run it, at which point it fails with excellent errors that tell you nothing. Granted, this situation has improved in recent days, but a jump from 90th floor compared to 100th is still painful.
6. Every single fkin thing that gradle offers can be done in half dozen ways and nothing tells you which way is better or why. Ex.A: is it providedCompile or implementation? Yes, one is intended to be a replacement for another, and no, they are /not/ same.
7. The 'One Nice Thing' gradle had going for is that it bootstraps itself. But look, if want to add gradle to a 'new' project, you have to install it to your system first and use it to add the wrapper. But after that, you are expected to use the wrapper. Nobody tells you that, you just have to figure it out. Oh and when it comes time to upgrade the wrapper version, you're to use the wrapper itself, not the system gradle, again mentioned nowhere, and if you try updating the wrapper using system gradle, the error helps exactly not.
8. Gradle takes free reign in breaking APIs /between minor versions/. WTF!
9. gradle starts a daemon to cache stuff, which is nice I guess. Except when you don't want it to run a daemon, so you tell it with `--no-daemon`. Do you know what that does? It starts a daemon, runs the build and shuts it down. This may not sound like a big deal, but it is just cherry on top of this shitcacke that tells you just how thoughtfully and well designed gradle is. /s
/endrant
[0]: https://docs.gradle.org/current/userguide/compatibility.html
What about toolchains?
I also am extremely unhappy that those functions can be 16 layers deep somewhere in a lib and cause your app to blowup.
I agree that Maven is nicer to use, but the faster compile times are worth it for me to use Gradle
That's definitely still a problem for libraries etc., but thanks to very recent developments (see the article) at least getting your app to users is super simple thanks to the new Swift Flatpak runtime: https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift...
The Linux kernel allows you to run proprietary apps because the kernel code and the userland code exist in two separate "planes" connected by the syscall interface. The kernel even has an explicit exception for any code that may need to be shared between the kernel and the userland to make clear that this code is excluded from GPL.
As another similar case, the Free Pascal compiler is licensed under GPL including the runtime and almost all libraries/units that come with it but it also has an exception to allow linking without having the GPL extend to the programs the users write. AFAIK the GNU C library also has a similar GPL-with-linking-exception license.
Flatpak apps aren't linked against a runtime, they just run in a bwrap sandbox with that runtime. Again, think of it as a Docker container.
In Fact, Flatpak apps aren't even supposed to know they're running in Flatpak. They can know that, because the user agent string says so, but nothing in the app code specifically should be adapted to run in Flatpak
That said GTK on Windows and macOS is very meh. You don't choose GTK for making a cross platform app.
I don't think Transmission is a good example.
Well, Angular is kind of dead now (or rather - will be). See https://twitter.com/sarah_edo/status/1770478763253379488
> Today we have some exciting news! We're merging frameworks! Angular and Wiz!
Wiz is awful and it's my read that a Wiz manager "won" a corporate battle and Angular (as it was) is dead.
It’s the best way to write native Multiplatform apps at the moment. It just is.
I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.
I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".
Good luck with your project!
(if there's a better place to have this conversation than (ab)using this thread feel free to point the way. Assuming you wish to indulge me at all that is. ;-)
Well, I disagree with that. Again, it just takes a lot more effort, but I believe this is achievable (to a large extent).
If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components).
If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?
Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2]
> difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes.
I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML.
I wonder how feasible it is to integrate Typescript into QML rather than JS.
But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native).
[1] https://www.get-plume.com/
[2] https://www.qt.io/blog/the-new-qtquick-compiler-technology
As an ordinary Linux user I at least welcome all applications with bonus points if they are well integrated into KDE.
Maybe the Gnome crowd is more picky?
We Linux users do like our desktops to be sleek, badass, and sci-fi ...
I'd been out of iOS dev for a good long while, and was still thinking in UIKit and Obj-C.
Overall I've found SwiftUI to be the most productive and enjoyable declarative framework and developer experience I've used!
To be fair my experience is limited to React and Flutter, but still, Apple have done a rather excellent job IMHO!
YMMV :-)
Unfortunately though SwiftUI hasn't completely matured yet. Especially if you are targeting iOS versions prior to 16, you will encounter many of SwiftUI's shortcomings. Some (many?) UI components are still UIKit under the hood, scroll view and its derivatives are still not as flexible as you sometimes want them to be etc. For some custom UI tricks that would be a piece of cake in UIKit are impossible in SwiftUI and you often resort to wrapping the old components in your custom ones.
Oh and don't get me started on resorting to the main thread (because of the underlying UIKit code) in the age of structured concurrency.
All in all, the concept of SwiftUI coupled with structured concurrency is beyond amazing but its maturing process is still underway.
> cross-platform
??
Do you know of any GTK4 app that runs well on non-Unix platforms?
You could do it in Python using contextmanager which packs after adding the widget to HBox to save a line, you could do it in Ruby using do/end blocks, you could do it in C with the help of some pretty macros.
And I also have to say that my days with Qt are quite some time ago. I never really got into QML, so if you say that QML is a great choice I'd put more weight on your word than on mine.
Qt Quick (The Qt Company's library that is exposed in QML) is very advanced today. I'm able to do things that would be considered very difficult with Qt Widgets. For example: true drag and drop between items in a virtualized list: https://twitter.com/plumenotes/status/1772599295243440137
Also, they started to work well on native widgets (at least on macOS), for example they support native dialogs, context menus, etc. Very helpful.
I'll probably write a blog post about the development and architecture (some said they'd be interested).
But how is everyone testing their Swift codebases? We've found the story around testing to be... lacking. The [docs](https://developer.apple.com/documentation/xctest) on the subject are pretty bare and don't offer strategies for mocks, stubs, reporting, code coverage, etc.
And good luck if your app uses a Network Extension... those must be tested on a live physical device due to the signing restrictions!
On that note, does anyone know of a good physical device CI service that supports both iOS and macOS devices?
It's a tool to help better manage complexity, and that naturally invites more complexity as well.
adding additional names does not add additional complexity. complexity arises in interactions between components.
For instance ruby helps to have shorter, less verbose code, but with more hidden components. Rails rose from there, tooling tends to support that style. I've seen java devs moving to ruby and naturally writing less verbose code.
In contract Java tooling makes it a lot more manageable to write 40 character long classes, deeper dependency trees and injections and potentially auto-generate half of the needed methods. The cost is low, and there's less incentive to fight that trend when tools help you abstract part of it.
You're right that total complexity across the system fundamentally doesn't change (it's up to the devs and the problems at hand). Local complexity in each part of the system can vary, but the whole will probably always be least as complex as it needs to be.
Swift does have an unconventional approach to function keys though, wherein you can specify an "external" label and an "internal" label:
func greeting(for person: String) -> String {
"Hello, " + person + "!" // the argument is "person" inside the function body...
}
print(greeting(for: "Dave")) // ... but it's "for" when calling the function
const hello = ({ for: person }) => `Hello ${person}`
hello({ for: "Dorian" })
'Hello Dorian'e.g.
const user = {id: "123"};
const { id } = user; // This extracts the `id` field
const { id: userId } = user; // This also extracts the `id` field, but renames it to userId
console.log(userId)I’m glad they found a nice way to do it in Swift.
// in greeting.h
void greeting(char* for);
// in greeting.c
void greeting(char* person) { ... }
An example I like to use to show when and how I used it. I have been playing with Metal. If I write a function called translate, I will have it's external parameter as 'by' with the internal parameter being 'vector'. As a simple example:
func translate(_ origin: simd_float3, by vector: simd_float3) -> simd_float3 {
// do some stuff
}
let newVector = translate(originalVector, by: translatingVector)http://avisynth.nl/index.php/Grammar#Functions.2C_Filters_an...
Isn't it good that now there is an alternative to C?
It's not exactly the first alternative, GJS (Gnome JavaScript) have existed for a long time and is also a C-like language, so doesn't seem this would give too much value compared to just using GJS, unless you know Swift a lot better than JavaScript but the languages are similar enough that even that doesn't provide much value.
AFAIK, GJS is an official Gnome project too, so there will be a vast difference in ecosystem support compared to Gnome apps written in Swift, which I'm not sure is so popular outside of Apple circles.
Use TypeScript if types are so important for you. Others find their own way of handling those issues without getting tripped up on it. Hardly a reason to completely switch between two languages in my mind, but of course it's alright if it's reason enough for you. Luckily there are acceptable workarounds for both groups of people :)
> Also, GJS is not well documented, as far as I remember.
What exactly is missing here? There are guides for the basics, API reference exists and there is a ton of apps you can look into for inspiration and/or figure out specific implementations.
Is that really worse than what exists for writing Gnome apps with Swift? Seems like a really weak argument for using Swift instead of GJS.
I still don't see how a language (GJS) with an already existing ecosystem of writing Gnome apps, lots of examples, API references and more is worse for writing Gnome apps than Swift, that seems to have been launched just some days ago?
Edit: I realize now that the "Adwaita for Swift" this blogpost is about isn't even an official Swift project, is the output of a student interested in Swift and Gnome.
But that's what so great with programming languages, there are so many that work so differently, so there is at least one language for everyone, no matter how different your brain works :)
By the way, if you're a fan of "conciseness" you should give a lisp-type languages a try if you haven't before, will show you a completely different level of conciseness! Clojure is a great introduction to lisps. And if you still need validation of data somehow, clojure.spec et al works great and will introduce you to some cool new things you probably haven't come across before :)
I mean, you said it yourself:
> One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great!
For those people it is definitely better than GJS!
But yeah, probably for some it's worth it, so that's pretty cool :)
Even the gold standard of GTK coding in C is still very undocumented outside of the happy path and confusing due to the Gtk 3->4 migration, and the only approach to learning it is by reading what other Gtk apps do.
Could you explain the nature of problems that occur due to javascrript's treatment of objects? What makes it a big and important issue?
Rust has had endorsed language bindings for GTK for a long time: https://www.gtk.org/docs/language-bindings/rust
Some official Gnome applications are written in Rust.
Swift only supports a small number of linux systems (Ubuntu, CentOS, Amazon Linux) which makes unsuitable for general linux application development.
You seem to have hallucinated that I said that swift cannot be made to run on other systems. You can even make windows-only games run on linux so that is not a surprise.
What distinguishes swift from gcc, clang, python, bash, go, rust, and so on is that languages other that swift aim to support linux in general.
"and so on is that languages other that swift aim to support linux in general." -> again not true linux distro dosen't change swift usage it is just official build is run for few most popular distros and you can use prebuild swift-bin on any linux repo. (arch, debina, ubuntu, centos etc. etc.) You can say the same stuff about rust/nim/go every other language that didn't have official release for some niche linux distro.
Swift here are basically saying they'll endeavour to make sure it works on those particular distros, but in general you're probably going to install Swift on Linux the same way you install rust; via your distro's package manager, and supported by your distro, not the Swift or Rust project.
Notice the [AUR] tag, that means it's in the Arch User Repository, not in the official repository.
https://wiki.archlinux.org/title/Arch_User_Repository
https://wiki.archlinux.org/title/Official_repositories
Slightly ironic given the whole "confidence" side-note you made earlier...
https://wiki.archlinux.org/title/MATLAB https://wiki.archlinux.org/title/Scala etc.
If rustup will be removed from official repo we can argue that rust isn't supported in arch?
There’s this new kid in town, IIRC it’s called C++
As do bindings for Python, C#, Lisp, Scheme, Vala, JavaScript (since GNOME 3)...
The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle).
You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*).
It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome.
* Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".
The only thing that really seems to be succeeding is web stuff like Electron, which usually throws the baby out with the bathwater and does its own thing of emulating the web (itself, basically) instead of trying to feel perfectly native.
Seems like you guys want either 0% or 100% ..that something either not exist at all or perfectly does everything you ever wanted without any effort or cost on your part.
This dynamic presents a legitimate problem for pretty much any open source project that aims to abstract away something very complex to enable more developers to use it. Any project that does this is going to have more developers relying on it than are capable of contributing to it.
You should never feel entitled to continued development of a project you don't contribute to, and you should always assess the community around tools you want to use in order to make good decisions. But this doesn't mean you can't be super frustrated if something you rely on goes dormant. I personally avoid using any library/package that doesn't appear to be very active, but nothing is foolproof. Even a seemingly healthy project die can fairly quickly in certain circumstances.
Or, you know, that's a strawman, and we just want something that exists and is mature, like hundreds of other FOSS people are fine with, as opposed to basing our code on something that is immature, has little community, and will probably be abandoned when the authors get bored with it.
Which has nothing to do with it being "100%" or "perfectly doing everything we ever wanted".
For production use-cases at this moment in time, I'd probably lean towards using Swift's pretty-good C++ interop functionality to thinly wrap a more battle-tested C++ library.
Swift has such low memory usage, that it's an order of magnitude easier on resources, than those Electron wrappers. At the same time, it gives what you loved about React - expressiveness for UI.
I wrote a lot of apps in SwiftUI, and it strikes a good balance between type safety and expressiveness, it's cool that we have something similar for GKT/Gnome now.I believe swift is a good language, however its ecosystem being steered by apple is a massive red flag. It also suffers a bit from being a commercially developed language in that its developers are clearly incentivized to add more features.
I agree that this is a must-have for idiomatic Swift. It is really hard to write the long-named-functions and get all the variable names correct without reasonable autocomplete.
UI is a different matter. Xcode is still miles ahead in performance tooling.
Emacs + lsp-mode + sourcekit + company-mode etc looks reasonably close to what I get with Rust in Emacs.
If I were doing application development I'd maybe consider Swift.
Do you have any evidence this is true? Most programming languages are developed either by a company (C#, Java, Swift, Go) or heavily influenced by many companies (Python, JavaScript, C++). Java had been criticized forever (until very recently) for it's slow pace of development and it was 100% controlled by either Sun or Oracle.
Comments like these show just how little developers investigate the reasons why features they personally dislike were introduced to a language.
But that’s OK. They do an amazing job of maintaining backwards compatibility and making things fit in the language well as well as trying to get it right the first time.
Some languages are more willing to remove things that don’t work. Others are willing to have multiple different attempts that all work completely differently every few years.
In many ways that’s just not Java’s style. And that’s OK.
Hardly any better than F#.
Kotlin is especially popular on backend if you can’t jump out of JDK8
F# is functional - by definition not mainstream
Spring supports anything that can bring them support contracts.
Kotlin, popular outside Android?
Reality check over here,
https://spectrum.ieee.org/the-top-programming-languages-2023
You can’t deny Kotlin is bigger lang than F# by any ranking from those popular (Tiobe) to unknown ones and is build on top of much bigger ecosystem (JVM) - that’s IMHO much more important factor for anyone doing commercial projects.
Additionally there is a big incentive to use it over Java (if you are stuck with older JDK) contrary to using F# over C#
Kotlin as a lang is better than C# (which is normal - it’s newer) and has better default IDE (IntelliJ) than anything on the market.
[0] https://www.youtube.com/watch?v=1ukSR1GRtMU (video)
[0] https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-deskt...
Did I miss it?
Makes me want to ask: Why? Why do this?
It is a decent language for 2005. But it has some serious shortcomings (reference counting garbage collector? Really?)
The worst thing IMO is its dreadful support for threads. The "DispatchQueue" seems to be a wrapper around "fork/renice". There is no attempt at memory protection.
But it is full of little niggles that get very irritating in this day and age.
I never used Objective-C so it may be a vast improvement on that.
It is no longer 2005, and we deserve, and we have, better languages.
My time as an Apple developer left me with the overwhelming sensation that Apple hates its developers. So much cool looking stuff that mostly worked...
The documentation of Apple is worse than hot garbage though. As in, at least with hot garbage you have something.
DispatchQueue is anything but fork/renice. Also there is async/await now. GCD should be used for concurrent work only now, not async work.
Memory protection is fully implemented in Swift 5.10, but compilation only warns, enabled by default as errors in Swift 6.
https://forums.swift.org/t/any-future-directions-for-support...
Two struct might be the same, but when I observe for changes in one, but not another, a distinction arises which is best captured by object-based identity
I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.
By and large, it’s a world of difference from what it was and my experience has been joyful. Xcode cloud just worked so that’s cool. Profiling is wonderful (signposts etc). Could there be improvements? Sure. Are there other languages with better features? I think so. But I haven’t found myself longing much for something provided by other languages and platforms
Point is, I no longer dread iOS development. In fact, it’s quite fun.
That is DispatchQueue. Or NSOperationQueue. Or preferablly Swift concurrency.
Most wrappers around dispatch queues are unnecessary and use it incorrectly. (I would say this is true of operation queues themselves.) Swift concurrency is better than dispatch, though.
For some things, sure.
I can't see any logical reason why people would not use Electron/Tauri.
Swift doesn't allow you to have full control of what you want to do.
I built a whole macOS [ fixkey dot ai] app in Swift, and it was a very painful development experience.