Live data from Hacker News

Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

infoq.com

271–280 of 308 posts

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#271
post #66

Earlier quoted context omitted.

Windows switching to the Linux kernel would be wild, but I think we all know it's coming.

I don't know how they can pull that off. They would need to support customers who need that compatibility. So either they start being major contributors to WINE or something like it ... But then what about people who need a propriatary driver? Maybe a VM with hardware passthrough.... But they already have WSL for compatibility in the other direction. Not good enough?

It won't happen all at once. Linux already coexists with Windows through WSL and virtualization. The real work is in porting the APIs that the core MS products make heavy use of (DirectX, .NET, GDI, etc.).

The old Windows kernel will run in a hypervisor as needed. Windows already takes advantage of virtualization for everyday programs for security purposes. It wouldn't be that much of a shift to virtualize the kernel too.

More and more of the MS stack is being ported to Linux, seemingly in preparation for this. As of recently you can run PowerShell on Linux and run .NET "Core" on Linux. Since Visual Studio and Office are all .NET, if the Windows graphics/GDI layer is also ported to Linux, then it should be possible soon to build Microsoft Word for Linux.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#272

Earlier quoted context omitted.

JavaScript is a language that's neither abstracted from the basic programming concepts nor its syntax is alien. Most of the people who picked it up can learn many other mainstream programming languages in a week, if not a weekend. Add 1-2 more weeks and they're writing GUI code. Yet, they don't. JavaScript is popular for pragmatic reasons (a.k.a. "it delivers results"), so is PHP. They aren't the best languages, but…

I will never ever ever work with PHP again. It's dead.

While I hope never to work with it, in what concerns the tiny set of PHP files on my web site, it is alright.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#273
post #172

Earlier quoted context omitted.

> Electron ends up being the technology of choice for so many desktop apps. probably because of the large number of JS only developers.

I’d say electron became popular thanks to HTML, not JavaScript. IMO HTML is by far the “easiest” to use GUI framework because it is so unconstrained. It will end up a mess, but eventually you can get the result you want. This is not the case with native frameworks which come with a larger sets of rules on how they can be used.

I beg to differ, having been doing GUI coding since a couple of decades.

Guess what, what in most of them I never had any issues to center elements, or create fake UI elements out of list items.

Also layout managers were already a thing back in 2000.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#274

Earlier quoted context omitted.

What would it provide that Qt + QML don't right now? (if we assume that the crossplatform GUI is the killer feature)

A modern, powerful memory safe language? C++ is hardly a good choice for making casual small GUI apps.

Depends, if you are coding C in C++, or making use of idiomatic C++17 (eventually C++20).

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#275
post #237

Earlier quoted context omitted.

Nobody is submitting Windows apps written in Swift to the Mac App Store.

That’s not what I implied. Without a vibrant app ecosystem, way less iDevices would be sold. Without developers, the ecosystem suffers.

And without Mac hardware their sales suffer.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#276

Earlier quoted context omitted.

Why would you want an old API like OpenGL when you can use Vulkan and Metal

And in case anybody comes in raving about how Vulkan isn't supported on macOS, that's fine, Vulkan-to-Metal compatibility layer libraries are available.

Well, Vulkan is also not supported on PlayStation, XBox, Win32 and UWP sandboxes, Android devices until Android 7, and until version 10 only flagship devices actually had any kind of proper support.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#277
post #66

Off-topic, but I read the title as "Supported on Linux distributions including but not limited to Windows". Microsoft, you know what we want.

Windows switching to the Linux kernel would be wild, but I think we all know it's coming.

Why would Microsoft want to adopt a less technology interesting kernel stuck in the age of monotliths?

WSL is there to sell Windows laptops to those that would rather buy Macs without any interest in Apple's eco-system, rather using them as pretty UNIX for GNU/Linux work.

They realised the mistake of not giving first class support to the POSIX subsystem and nowadays Linux compatibility is more relevant than POSIX.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#278
post #186

Earlier quoted context omitted.

Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language. Way way way way way harder, I'd think. It's basically never been done in the modern era. All the successful ones from the past look (and work) like garbage on a modern desktop computer (I use gnucash for my dad's business, ha ha). SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tel…

I think the opportunity is particularly on how SwiftUI has been implemented in iOS, iPadOS and macOS, by relying on the native UI of each platform and providing a common abstraction for developers. Instead of providing the same UI that works badly on every device, SwiftUI interprets each concept differently according to the platform. For example, a Toggle in an iOS and iPadOS app looks like a on/off switch, while on…

Yes, I totally agree with that.

The way they have implemented it for even their own "cross-platform" needs (where the "platforms" are really basically different versions of the same OS) works very well — the sickening, jaw-droppingly awful apps from Twitter, JIRA, etc that use the "Catalyst" system of porting iPad apps to Mac shows why the approach is really necessary.

(Those apps bring iPad metaphors to the Mac, so what should be a single interaction, picking something from a menu, is a jarring series of taps, swipes, and animated fuckery.)

If that "render the concept using the OS's native widgets" approach was necessary even for cross iOS-macOS apps, it will be even more necessary across Mac and Windows, where a lot of the UI conventions are wildly different, and sometimes literally the opposite (e.g. the standard placement of buttons).

And it's obviously the only way it could work for web apps.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#279
post #230

Earlier quoted context omitted.

Like Crystal, Go and Rust? (and QML for the basic events handling) https://en.wikipedia.org/wiki/List_of_language_bindings_for_...

Have you made any non-trivial use of the Qt bindings for those languages? Qt is a big and complex library, and most bindings are incomplete or poorly documented. As far as I know, PyQt is the only Qt binding is the only one that you can really rely on to work now and in the future.

Not terribly complex, but not trivial either. Yes, there are missing pieces in non-python ones. But given that basics are handled, it's often pretty easy to add the pieces which you need.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#280

Earlier quoted context omitted.

In some ways, Swift is a higher-level Rust. It places a lot more emphasis on functional programming, null safety, value types and immutability than C# does. The more flexible memory management model added recently, native binaries, (as the default option) and even identifier: Type over type identifier is also a nice plus for me, I agree that the IDE situation is heavily in C#'s favor. If C# is a nicer Java and Kotlin…

null safety modern C# has optional chaining, Elvis operator and non nullable types value types C# has value types contrary to Java (until project Panama) What would you argue C# has going for it over Swift? feature wise I don't know but it clearly has a far bigger lib ecosystem which is the most important criterion

Yes, some of these have been slowly added, similar with Java slowly moving to embrace features from Scala and Kotlin, but to me it doesn't feel as nice, rather sort of baked on and many of the libraries don't use these latest features.

Swift was designed to seamlessly blend functional and OO styles from the get go.

Fundamentally, there's still classes and inheritance everywhere in C#, which is also what I hated about Cocoa and using it from Swift before they came out with SwiftUI.

Now don't get me wrong, I am not saying C# is a bad language, just that when you compare it with Swift, Kotlin, Rust etc, it's clearly playing catchup.

> far bigger lib ecosystem which is the most important criterion

Going by that metric, you could argue there's no point to C#, because Java likely still wins handsomely on that front and maybe Java should just give it up to JavaScript anyway.

Clearly we don't just evaluate languages solely by the size of their ecosystem. There's a critical mass that needs to be achieved, but at some point there's 2-3 libs for everything you may want to do and simly having 5 more is not magically better, the same way having "millions of apps" on the App Store doesn't mean much if most of them are not that great and people stick to just a few.

As an example, the GUI situation on Windows clearly offers more choice for C# devs as to how they want to go about their GUI, but I'd argue the Windows GUI situation is a bit of a hot mess right now and SwiftUI seems like a breath of fresh air compared to that.

Post reply on HN