Hacker News Reader

Comment by codedokode | Hacker News Reader

I don't understand why there are so many negative comments. Writing GUI in C looks like a stone age programming, and people are simply wasting their time to do routine work that can be diminished by using another language. One might use Python, but it is slow and memory-hungry.

Isn't it good that now there is an alternative to C?

View on HN

I used common lisp in the past to interface with GTK via the cl-cffi-gtk library. Performance was good I think (I did not benchmark but the UI was responsive and did not consume much resources) and dev experience was great because of the REPL. But it did take quite a bit of suffering to get the resulting artifact working on Windows which was a definite requirement sadly. It can be done though.

> 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.

JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Also, GJS is not well documented, as far as I remember.

> JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing.

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.

Swift is compiled, static-typed language and without tons of legacy like JS (for example, it has real objects, not dictionaries). Doesn't require an interpreter. It seems to be better than JS in every aspect.

One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great! Doesn't mean it's a silver bullet that improves development for everyone, and that's OK.

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.

Honestly I used to think the same way about JS, because not having types allowed for very concise code sometimes. But the more I used Swift I realized how powerful type inference can be, and the difference in conciseness shrunk to basically nothing.

Heh, yeah, everyone's journey is different :) I started out being a big fan of static typing but eventually found that I'm usually hit by different issues than "this was a int but I expected a string" that were more important to be solved, so I'm mostly using dynamic languages nowadays.

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 :)

Doesn't TypeScript – as mentioned above – solve all JavaScript type problems? I have, in 6 years, never encountered a single type error originating from a TS file.

Biggest problems with TypeScript IMO are that it’s a layer rather than a language proper and that untyped JS problems can too easily worm their way in if you’re using any libraries at all. Also depending on the group of developers involved, the ease at which one can pull the escape hatch and opt out of TS is a liability and can render much of its benefit moot.

> 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?

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!

Well, I mean if the difference was only about static typing, I definitively see what you're talking about. But the difference between GJS and Swift for Gnome app development is greater than that, so personally just that one "feature" wouldn't push me towards Swift.

But yeah, probably for some it's worth it, so that's pretty cool :)

I think you are vastly overestimating how good and current the GJS documentation and examples are. Without touching the fact that it is NOT a stable API and breaking changes are very common.

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.

> legacy like JS (for example, it has real objects, not dictionaries)

Could you explain the nature of problems that occur due to javascrript's treatment of objects? What makes it a big and important issue?

In JS you can delete properties, assign anything to them (no typing), cannot add comments to them, cannot restrict access from outside. Also you can access non-existing properties and no error will be thrown.

>Isn't it good that now there is an alternative to C?

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.

Why doesn't Swift run on other Linux distributions?

It runs just fine comment above is lying if you can run llvm/clang you can run Swift.

I don't know if I would say, 'just fine.' Technically yes. The issue comes in with that not everything in Foundation is quiet yet there on the Linux platform. But it is getting better and better and probably good enough for 90% of stuff. It seems more of a problem of just getting the last bit done to push Foundation over the finish line.

Swift run on almost every linux desktop (Arch, Debian, Ubuntu etc. have even their own packages) I hate when people are writing false information with such a confidence.

See https://www.swift.org/platform-support/ for a list of supported distributions.

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.

Swift only supports a small number of linux systems. which is at most half-truth cause this is just official installers and most likely you'll use some sort of rustup (rust wasn't working on every system few years ago if you use official installer not some sort of rustenv installer or building from source etc.) you can use https://github.com/kylef/swiftenv you can use community packages https://wiki.archlinux.org/title/Swift etc.

"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.

I don't think that, say, rust, offers any explicit support for any particular 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.

It might run but support and packaging is missing, compared to gtk oficially supported for other languages and packaged on distributions that matter (e.g. Debian).

https://forums.swift.org/t/new-swift-package-repository-for-...

"runs" would be different than "supports". AFAIK, there still isn't an official package for Swift in the Arch package registry, so to say Swift is supported by Arch sounds like "writing false information with such a confidence".

https://wiki.archlinux.org/title/Swift

> Install swift-bin [AUR]

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...

almost no smaller/newer language is added to official repo so i don't know what are you taking about it is kinda expected? (even if this languages are fully supported on linux)

https://wiki.archlinux.org/title/MATLAB https://wiki.archlinux.org/title/Scala etc.

Be that as it may, the initial claim was "Swift only supports a small number of linux systems" which you tried to refute but moved the goal post from "supports" to "runs". One of them are true for Swift + Arch, yes.

Supporting languages isn't the arch maintainers job I srsly don't understand your argument if all language stuff (LSP, language, debbuger etc.) work on every linux distro without any modifications is this distro "supported"?

If rustup will be removed from official repo we can argue that rust isn't supported in arch?

to be fair and looking at how closed is the apple ecosystem, I would not put my open source eggs in swift

My feelings exactly! It's frustrating the lack of viable alternatives though. Just typing on my japanese flip phone is a pain and i think the T9 could be improved. That said i don't think adopting apple tech would help much as far as fixing any deficiencies in ui imho.

How does the App Store affect Swift?

Swift is open source.

Yeah, I'll happily take GUIs written in a fairly fast and memory efficient language that are using a full GUI toolkit. It beats Electron, Python, Java or Go programs any day.

Gtkmm exists since GNOME 1.0 days.

As do bindings for Python, C#, Lisp, Scheme, Vala, JavaScript (since GNOME 3)...

> Isn't it good that now there is an alternative to C?

There’s this new kid in town, IIRC it’s called C++

Reply on news.ycombinator.com