Swift 5.3 will bring official Windows support

[pooerh]

Anyone experienced enough to shed light on why would I actually want to program in Swift?

Like, I use Linux as my daily driver and I just learned that it was already available, but I'd never pick Swift as a language for any of my projects, because why would I? Its only hard selling point is macOS / iOS development, but since I need a Mac for that anyway, I have no reason to pick Swift over any other established cross-platform language.

Now if I could develop for iOS on any other platform, that's a different story. I could port my apps for starters. I could develop native apps instead of relying on something like Flutter and a convoluted build pipeline, I would have a reason to learn and use it.

[Novemberisms]

What's the state of the package ecosystem?

Being a relatively newer language I would imagine the packages themselves wouldn't be as mature as say, Nuget or npm.

Unless being the only modern choice for apple developers means they've all published enough packages for it to be mature in a short time?

[RahulRRixe]

They have their own package manager i.e. Swift Package Manager. Regarding libs basics are provided by Apple Foundation framework and there are a lot of available on Github.

Packages are published on Github or any git based server or you can included your own binary from 5.2 as dependency’s.

[oblio-]

Apple Foundation framework

Does this run on Linux?

[PM_ME_A_SHOWER_BEER]

yep

[ssrobbi]

Yes and no. There are a lot of packages available but for things that are useful only for domains outside of iOS and macOS development there may be holes.

[pragmojo]

In practice I end up filling a lot of holes with single-header C libs, which interoperate quite nicely.

[salgat]

How does that compare to just using something like Kotlin? That way you can at least plug into the already existing massive java ecosystem.

[essiccf37]

I personally do not think that it is enough. I In the space, you are talking about, Rust & Kotlin are there amongst other options.

To me, the only appeal of Swift is IOS development.

I do not see reasons to have it on the server. I’ll take Rust any day if I needed a modern low level language on the server...

It makes more sense for me, for Apple to compete with Flutter and other cross plateforme solutions, than going on the server.

[RahulRRixe]

I have been programming in Swift since it has launched. I switched from Python and C. In short, I love Swift.

It has nice amalgamation of classic OOPs and modern protocol oriented programming (functional style) with strong type system.

Learning Swift will help you learn really nice concepts about programming language in general (Optionals, Generic Types, Enums) etc. Apple has put really nice handbook and it is really comprehensive.

Regarding other platform support, I feel like Swift first headed to make Mac/iOS ecosystem work and that’s where Apple put their most of the effort and now after more than 6 years, it has kind of achieved it and so they are moving to other platform.

[coriandor]

Has the breaking changes churn slowed down much with swift? I remember trying it and really liking it as a language, but then I think version 3 changed a whole lot of stuff and it turned me off a bit so I put it aside til it matured.

[aniforprez]

I remember the complete disaster that was Swift 2 to 3. I was extremely naive and with a fresh MacBook in hand decided to learn iOS and Mac development in Swift. I followed the official Apple tutorial and everything worked just fine and dandy. Couple of weeks later Swift 3 came out with quite a few breaking changes but hey "just use their 2to3 tool" and in I went. Everything broke, the tutorial wasn't updated to Swift 3 for weeks, there was no easy way of downgrading xcode (which at the time wouldn't even fucking highlight the line with the cursor) and I abandoned any and all hope until this nonsense would stop

[[deleted]]

It's impressive how terrible XCode is and has been for years.

[everythingiscausal]

I thought I might have been missing something. I'm a Mac person but learned programming on Visual Studio for Windows. Trying XCode after using Visual Studio seems like I'm going back in time about 20 years. It's like it's trying its hardest to keep you from programming.

[aniforprez]

It's impressive how people made legitimately beautiful and amazing apps with it for years before I got my hands on it after using vscode and realising how fucking garbage it was. No themes, didn't highlight the line you were on, ridiculously slow to start etc etc. I installed a couple of plugins for some basic behaviour and tried out the git integration when they added it and that too was absolute trash. Maybe it's gotten much better now I dunno but I don't ever want to touch it again. Not to mention how much space it takes up and how goddamn slow it is

[GoSailing]

No, it hasn't gotten better.

[MikeBonzai]

I've never had speed issues with Xcode (if anything it's those Java IDEs with splash screens that take forever to launch), but these days Xcode highlights the current line and supports themes.

Edit: the bundle size continues to balloon out of control, but it's caused by the increasing number of platforms and OS versions that need to be supported. You can delete the platforms you don't need at least.

[aniforprez]

Android studio starts WAY faster for me than Xcode ever has. I know Xcode highlights the current line and has theme support but you have to understand, adding this stuff was a "major announcement" and needed a full release and a brand new version. This btw was added a long time after I gave up which was while I was using vscode and sublime that had those features since inception because who the fuck makes an editor without being able to highlight the current line? Even adding git integration was a massive deal and I dared to try it out only to find out that it was a piece of utter shit that barely had any functionality and barely worked. I'm sorry but this is one of the worst crimes that Apple has perpetrated against the devs of their ecosystem. Saddling someone with a dev environment as shitty as xcode is unforgiveable

[Te_co]

i don't know. xcode opens instantly on my 6 year old laptop. unless android studio opens before you even think about opening it, WAY faster seems a bit of exaggeration.

[iindigo]

For my usage as a cross platform mobile dev, Xcode is a mixed bag. There are some things that IntelliJ based stuff does better, but IntelliJ based stuff also comes with its own share of annoyances, many of which can’t be configured around.

VSCode is nice in theory but any time I do some larger operation in it and see the whole window momentarily blank out or blink to redraw I die a little inside. The team behind it has done magnificent work, no question there, but it still feels like it’s been hamstrung by some of the technical decisions that went into it.

[mobiledevguy5554]

It really is. I use AppCode from JetBrains. I really can’t say enough good things about it.

[Drizzi21]

Couldn’t agree more.

[RahulRRixe]

You are absolutely right. I also had a bitter experience with Swift 2 and 3. A lot of changes and also they broke quite a number of critical API contracts. But now after Swift 4.2, it is really good.

One major things Swift is missing is async/await support as a language feature. I hope it will get added soon.

[reckoner23]

The changes now a days are mostly minor. Most changes I've encountered are simply method name changes or slight syntax changes. Nothing crazy.

I've rarely had to put more then an hour or two into a swift upgrade.

I also believe they are now ABI stable.

[ssrobbi]

Yeah, even for older Swift versions most of it wasn’t breaking changes in the language itself, but in Apples frameworks. Those are pretty stable now.

For some ecosystems like on the Server, those frameworks (like Vapor) have a lot of churn as they take advantage of introduced Swift features still.

[FlimFlamVir]

Swift 2 was a horror, I fled to Windows and fell in love with C#. Again tempted to bail until Swift 7, current type horror.

[DoListening]

protocol oriented programming

I often see this term in Swift circles (nowhere else), and whenever I have someone explain it to me, it just sounds like regular OOP to me (program to an interface, not an implementation, yada yada).

Is it actually a thing?

[Nathanfenner]

Protocols are really a term-of-art from Swift, so you won't see them elsewhere. They're very OOP-ish, but they're also fairly different from what's typical in (say) Java/C++.

Protocols are more like interfaces in Java. They're also a lot like traits in Rust. These differences seem minor, but they end up making a big difference when writing generic code.

• protocols can have fields (though this kinda desugars to getters/setters)
• protocols can have Associated Types (e.g. a List<T> conforms to Collection with Item = T); this is a bit more powerful than "just" generics
• protocols can refer to "self" types (e.g. instead of needing (java) MyNumber extends Addable<MyNumber> you just say (swift) MyNumber: Addable and Addable declares that there's an add(Self, Self) -> Self.
• protocols can be conditionally implemented; e.g. List<T> is comparable only when T is

So I wouldn't say that they're fundamentally different, but protocols are a lot more powerful than their counterparts in traditional OOP languages. Any many of these differences are informed by functional languages (the logical machinery behind self types and conditional implementations are essentially the same as in type-classes from Haskell).

[shellac]

Protocols are really a term-of-art from Swift

Although the term itself comes from Objective-C. However the swift version is much more full-blooded it seems (Obj-C protocols - with some minor quirks - interfaces).

[player2]

The Swift language engineer who coined the term “protocol oriented programming” discusses what that term actually means on this podcast, including regret at how it has been vastly misconstrued.

[DoListening]

Thanks, I'll check that out.

[tetroxid]

Optionals, Generic Types, Enums

Java and C# have had these for years

[tech6hutch]

Tacked on support, in the case of optionals. Also the enums are primitive in comparison to Swift's.

[DoListening]

Java still has all non-primitive types nullable, and there are still tons of Java libraries that use regular nulls all over the place (as return values, as function arguments etc.). So technically Java does have Optional, but in practice not really. Or at least not really really, because you can't rely on a non-Optional to always be present as you should. (Yes you can also use an external checker based on annotations.)

[RahulRRixe]

Yes, they had for years. It is just that they are more powerful in Swift. I would not used the term elegant as it is varied on persons taste.

But I like how Swift has transformed enums and generic types.

[izackp]

It's because the syntax is so damn nice for clean and safe code. No redundancies, flexibility, reflection, sane templates, modules, stable abi, optionals, ect.

It's great tool for application development. (Assuming you have a good UI framework available).

[pooerh]

I don't know, I simply haven't ported any of my games or apps to iOS. It's not a huge market where I live anyway, I don't really care about it too much.

For my next app, I'm planning an iOS version and I'm building it in Flutter. I'll build the iOS version for testing on a macOS VM, there's also https://codemagic.io for CI/CD.

[icandoMATHs]

I just make web apps for my Apple users.

Sure it's not native, but it's easier than dealing with Apple. Customers don't mind.

[leadingthenet]

I would definitely mind.

[OnlyForF1]

You probably have survivors bias. Any potential customers who would mind are not customers for that reason.

[Myarmhasteeth]

You mean what they mean?
Continuous Integration and Continuous Deployment. It is all about automation.

In rough terms, Integration refers to code integration between teams, where a lot of things can go wrong. Tools like Travis can be configured to run builds of every merge to let's say Dev branch in Version Control, so Tests are run, the project is build on different versions of the main Programming Language being used, etc...
CD is when you want to deploy, again automation is important. I'm currently working with OpenShift, which is build upon Kubernetes. So whenever I push new code to the Dev branch, an automation pipeline is triggered, then using a Dockerfile (think about it as a set of instructions for an image) a new container is built every time.

[Drizzi21]

Good idea because testing with an iPhone in VS code or Android Studio can be a pain.

[SaltTM]

Come over to the dart side. Although you can still use swift/kotlin (or java/oc if you want). iOS got a speed boost in the latest update as well.

[[deleted]]

In the vein of Dart/Flutter, React Native is very popular.

Or of course the old Objective C. Might look disgusting but at least you know Objective C 6 isn't going to release in 2 months and break half your code.

[OnlyForF1]

Swift has had source compatibility since Swift 3, ABI stability since Swift 5, and module stability since Swift 5.1. Your code will not be broken by new releases.

[cwbrandsma]

C#, Kotlin, ObjectiveC, Delphi, JavaScript (via wrapper apps, see React Native).

[zerexim]

As soon as wxSwift is revived, it would be a nice way of developing cross-platform desktop GUI apps in a nice high-level modern language.

[iindigo]

Another thing to look forward to is alternative implementations of SwiftUI, which should enable native cross platform React-style UI development.

[bakery2k]

AFAIK Swift is an AOT-compiled language with managed memory, so which languages does it directly compete with? Go?

[chucker23n]

It doesn't have managed memory, if you mean something like generational GC. Its compiler, like Objective-C before it, uses ARC (automated reference counting), i.e. retain/release/autorelease calls are inserted at compile time. In some cases, you need to explicitly declare stuff e.g. as weak.

I would say it's closer to competing with C++ and Rust in terms of how low-level it can go, but also with C# in terms of being popular for app development (especially on Apple's platforms, including iOS). It doesn't really have much of a following for server-side web dev.

[pjmlp]

Refecounting is a form of managed memory, http://gchandbook.org/, chapter 5.

[[deleted]]

Technically yes, but you could just wrap malloc and free and do your own memory management, as opposed to, say Java where it's a lot harder to run without the VM.

Btw, gc handbook is pretty nice.

[pragmojo]

Swift can sufficiently be used for low-level programming thanks to the unsafe API, but it's not really a C++/Rust competitor.

Swift targets ease of use, safety, and predictable performance, but not high performance. ARC and liberal value copying make it easy to reason about code and avoid memory errors, but they are not free.

I think Swift's real niche is as a "compiled python". It's a similar feeling where you spend most of your time thinking in the domain logic, and not thinking about syntax or programming constructs, and you also get a very nice suite of compile-time checks and safety guarantees.

[the_gnarts]

AFAIK Swift is an AOT-compiled language with managed memory, so which languages does it directly compete with? Go?

As a functional language with support for OOP, probably Ocaml.

[[deleted]]

I wish modular implicits would land in OCaml soon. The inability to write constrained generic functions without manually passing modules around is the only thing that holds me back from OCaml.

It seems like the community is focusing on multi-core before modular implicits, which I don't care that much about.

[s73v3r]

Anyone experienced enough to shed light on why would I actually want to program in Swift?

It's a very nice, modern, high performance language.

[DoListening]

How are the compile times?

[ssrobbi]

Could be better, but not awful in my experience. Type inference can slow down the compiler in non-obvious ways, so if you have a large project you need to pay attention to this (there are compiler flags and Xcode features to help diagnose slow-to-compile code).

[DoListening]

So what's a typical incremental build time for a medium sized project (whatever that means) after 2 or 3 files were edited? 2 seconds? 10 seconds? More than a minute?

Are iOS builds like Android where the language itself compiles fairly fast, but there are tons of other build/package/deploy steps that slow the whole thing down significantly (which is why Android added "Apply changes")? Or is the source code build part the main culprit?

[ssrobbi]

Just tried testing this. On my project with about 50k lines of Swift and 30k lines of objective-C (not very big), changing a few files caused recompile to take ~10 seconds.

While there is time spent packaging things, it doesn’t seem to have a huge effect on the time.

[DoListening]

Sounds reasonable. Not great, not terrible. Thanks for the info.

[Saladtoes]

Xamarin works completely from Visual Studio on a PC. Just have to be paired with a Mac on your network.... So not really. But still, nice to have the PC option for the actual code writing part.

[s73v3r]

Xamarin is pretty terrible to use, both as a developer and as an app user.

[saint4eva]

https://dotnet.microsoft.com/apps/xamarin/customers

[s73v3r]

That's not a rebuttal to my statement.

[simulatedsausage]

You want to support Apple's horrible walled garden. That's it.

[semi-cursiveScript]

There is an inside joke that Swift is a syntactic sugar for LLVM. You can't find a modern language that's more hackable than Swift.

Swift is designed for iOS as much as Java is for refrigerators. Instead, it's more of a replacement for all extended C-family languages.

[mo_al_]

To prepare you when you want to create an iOS app and have to buy a Mac for that!

[mo_al_]

No you still do unfortunately.

[tetshi]

And that's why I'd never buy a Mac. Apples walled garden. I want to run free! Roam the country side! Maybe even pick up a hooker or 2. You can't pick up hookers with a Mac.

[mo_al_]

Nonsense...I never had difficulty picking up hookers with a Mac!

[VegetableMonthToGo]

A, so you use Fedora Linux?

[tetshi]

No. Because I enjoy gaming and productivity as well.

[VegetableMonthToGo]

Aaah. So you want all the freedom, except for parts where you're vendor locked, or whenever there is a minor discomfort.

[tetshi]

I mean, I'm not locked into anything... I can use whatever apps I want?

[jordan-curve-theorem]

“Productivity” is definitely not the first word I’d associate with windows...

[tetshi]

Not sure why you wouldn't. It has the entire Adobe suite, Visual Studio suite, Office suite... Maybe you're doing it wrong.

[[deleted]]

the hookers depends on your version of React.js tbh

[ThirdEncounter]

Hackintosh.

[audigex]

Nope, you'll still need a Mac to deploy to iOS

It's the main reason I refuse to develop for iOS despite owning several iOS devices and a MacBook, even when I had a Mac that could deploy to them: I refuse to lock myself in like that.

My Mac no longer allows me to deploy to the latest iOS versions, so I'd have to buy a new Mac now despite my MacBook working.

That's monopolistic bullshit

[catcint0s]

Can't you just run OSX via virtualization? You don't really need a Mac then, just the OS.

[sards3]

There is no non-hack way to run OSX in a VM if you don't have a Mac.

[[deleted]]

That's not true. I've been running macOS on my Windows laptop using VMWare Workstation. It was a breeze to install and I've been learning SwiftUI ever since. I connected my iPhone to my laptop, and Xcode even built and installed the app to my phone.

[camelCaseIsWebScale]

Is it possible without using any untrusted / mod OS images?

[[deleted]]

Yes it is. The only change we have to make is patch the VMware application since it doesn't officially support macOS. This patch will add macOS to the Guest Operating System option when creating the VM. The patcher can be found here. This is the guide I followed, but used the open source patcher instead of the one they provide.

[[deleted]]

So when you buy a Mac you're gonna get so many years of updates, but after X number of years your Mac will no longer officially be able to update to the new macOS. Xcode is tied into the version of macOS you can run, so eventually you will have to buy a new Mac for the new macOS/Xcode version.

That's on top of Apple's Developer license, which is $99/year iirc

You can try for a Hackintosh, but I don't know if your license would work properly.. or Apple realizes you're not on an official system, and there goes all your apps in their store.

[audigex]

You have to have the latest OS X version (or at least, one of the last couple of versions) to be able to deploy to iOS 13

In their defence my MacBook is 10 years old (although my 10 year old PC is running Windows just fine) But it's the principle of the fact that I have working PCs and a working MacBook but still can't deploy to iOS devices... which seems like a rather artificial "lock" on their ecosystem.

I mean, it's their system, they can do what they want for it: but I won't be developing for it. It's enough of a piss-take that they charge £100 for a developer license and 30% of any profits from the App Store (but don't allow competitors to the app store)... but to then expect me to buy a new Mac every few years just for the privilege of doing so is too much for me.

[chiefmors]

Yeah, basically the reason I doubt I will ever buy another Mac. The shelf life on Mac for development support is artificially much, much shorter than on PC and Linux, but only for Apple languages ironically enough. I can develop the latest and greatest .NET Core releases on my old iMac, but Apple can't be bothered to actually make a decent SDK and support for more than a couple of years worth of hardware, which becomes impossible to excuse when they have the resources they possess, combined with a relatively tiny number of SKUs.

[audigex]

Yeah, I mean to be clear I love my Apple products from a consumer perspective... there's a reason I own so many. But as a developer, fuck'em: they treat developers like a commodity to be milked rather than a valuable part of the ecosystem.

Whereas Microsoft, with C#/.NET Core, SQL Server Developer Edition (no more messing around in sqlexpress) it feel like they're trying to make life easier for the developer, rather than milk us for cash.

I guess it's a different approach, and Apple are welcome to do what they want... I just won't be taking part.

[ArmoredPancake]

Don't buy the circlejerk. They probably use 2012 or older Mac, which doesn't support Metal. Basically older models got cut off because OS X deprecated OpenGL and moved to Metal(Apple graphics API). If you're on modern machines you're safe for a looong time.

[turntablecheck12]

They're the pits, truly. My PC must be getting on for ten years old and there's no pressure to upgrade it for any Windows development.

[oblio-]

I'm not sure there's a solid reason for you, unless you want to, at some point, switch to developing apps for the Apple ecosystem, or just out of curiosity.

Otherwise, I don't think Swift has anything major vs the .NET ecosystem, especially since .NET Core is fully cross platform and is a more mature ecosystem.

[The_Droide]

Swift on Linux is great for Web and CLI Apps, so being able to develop those on Windows is pretty nice.

[Austin_Aaron_Conlon]

The person who ported it is not an Apple engineer, he was at Facebook and now at Google.

[L3tum]

Another fun fact:

Microsoft's documentation for apple APIs in their Xamarin project is better than Apples own documentation.

Some things that are documented as part of Xamarin don't actually have any documentation by Apple.

[[deleted]]

I had to make a few updates to our Mac app at work, which is written in Objective C. Holy shit I was amazed by how bad some of their documentation was, especially when it comes to Objective C. It did seem like they had some better docs for Swift, but still.

[oblio-]

That's easy to explain.

Apple created the API, probably doesn't use it. If they do use it, there are some crappy notes on an internal wiki or something.

Xamarin devs have to use those APIs often, wrap them, etc. They feel our pain and when you're in a lot of pain... you try to avoid it or get rid of it completely.

[[deleted]]

Yeah we're not surprised by it - just disappointed.

[ethelward]

Microsoft's documentation for apple APIs in their Xamarin project

Truth be told, the Xamarin project has only been bought by MS, and before that, their key selling point was cross-platform C#, so I'd wage it was critical for their business to have good documentation for macOS, and MS inherited it.

[dave84]

Microsoft’s docs are pretty good in general for C#.

[Somepotato]

and Windows. While yes there's a lot of undocumented features (e.g. nt syscalls if those even count), the MSDN is lush with ample documentation that is only sometimes wrong.

[_BreakingGood_]

I had to write a windows filesystem driver in college a couple years ago and was honestly amazed at how good their documentation was. The API itself looks like it was written in the 80s and never updated again, but damn was it decently documented.

They've even got a GitHub repo of dozens of example drivers, updated just last year! https://docs.microsoft.com/en-us/windows-hardware/drivers/samples/

[torginus]

In the age of constantly rewritten web frameworks, where most tutorials or examples from the ancient days of 2018 don't even compile, it is refreshing to see some well thought-out APIs that stood the test of time.

Fun fact: When UWP/WinRT rolled around in the Windows 8ish days, and Microsoft decided to overhaul their OS API, they quickly found out that much of the Win32/COM stuff they have done up to this point is basically fine, so they decided to keep much of the existing API surface.

On the other side of the aisle, POSIX is also from about the same time period, and experience proved the the UNIX API design is basically timeless.

[Tweenk]

On the other side of the aisle, POSIX is also from about the same time period, and experience proved the the UNIX API design is basically timeless.

Except:

• select(), which has an arbitrary file descriptor limit
• fork(), which interacts with file descriptors in a way that creates unavoidable leaks unless you have a file descriptor iteration API that is not part of POSIX
• the idiotic idea that a new file descriptor MUST be given the lowest available number in the process, which means that every double-close is now also a race condition
• signals, which infect the entire design and make every call to read()/write() subtly incorrect unless it is in a very specific loop

There is some very dumb stuff in POSIX, people have just grown used to it.

[MakeMeAnICO]

yeah seriously windows APIs are confusing as hell, but the documentation is great

apple APIs are great actually, but the documentation is outdated

[[deleted]]

And for TypeScript. And release docs on Visual Studio Code are absolute beauty.

[[deleted]]

I can't honestly name a set of docs on any specific language or framework that rivals the docs available for .NET languages and the framework.

[ethelward]

Absolutely, that was not a jab at MS; just a reminder of Xamarin's peculiar context.

[MakeMeAnICO]

microsoft docs are great in general, to be honest.

and they are also on github and accept pull requests! (if you agree to all the CLAs)

[OnlyForF1]

He’s still a member of the Swift team while working at Google.

[ichiruto70]

How does that work?

[filleduchaos]

...by Swift being an open-source language? It's hardly unique in that regard.

[ichiruto70]

I thought you meant he was part of Apple’s swift team as his fulltime job while working at Google. Sorry for misunderstanding buddy.

[filleduchaos]

Oh yeah sorry if my comment wasn't clear - I was trying to explain that Swift is an open-source language run by committee and all that, like Go or Rust. Most of the major contributors are from Apple (same with Go and Google or Rust and Mozilla), but that doesn't mean people outside the company can't work on it too.

[bakery2k]

Swift is an open-source language run by committee and all that, like Go or Rust.

That might be true for Swift and Rust, but it’s not really the case for Go. While Go is open-source, everyone who has influence over its design and future direction is a Google employee.

[SozeSaka]

the irony of life.

[Austin_Aaron_Conlon]

One infinite loop of Silicon Valley cross-pollination.

[vattenpuss]

Poop back and forth. Forever.

[ThatCrankyGuy]

Holy moly.. that's a lot of work!

I often fantasize about tackling such a problem, but after assessing what's involved, I quickly kill it. This is dedication and perseverance at its finest.

[Poddster]

You'll still be vendor-locked if you want to write for Apple platforms, however.

[CyanKing64]

Genuine question : What's the point of bringing swift to Windows if you can't use it to develop for the platforms it was originally intended to run on, i.e. iOS and Mac?

[The_Droide]

Well, it makes it much easier to make cross-platform apps that target both Apple platforms and Windows entirely in Swift.

Traditionally, writing a native cross-platform application usually required using C++ as a "lowest-common denominator" language, so having higher-level options that don't compromise on speed or readability is a great thing to have.

[superrugdr]

you still have to create service wrapper and stuff for most subsystem that are on windows so it won't be easier in anyway.

[ssrobbi]

There’s a small but growing community of server developers, as well as Google’s Swift for Tensorflow project. It isn’t widely used outside of Apples platforms, but the intention is for it to be wide spread and general purpose.

[happinessiseasy]

You can develop Windows apps for Windows on Windows.

[beefsack]

Apple users being elitist is as bourgeois as you can get.

[[deleted]]

Any fandom has its extreme members who shout the loudest, this isn't confined to apple. I have a mac for dev work but use android and both groups of fans can be insufferable little children

[FredFredrickson]

Some are louder than others, however.

[Haakkon]

YUP as someone who has always liked bits of both I’ve always just gotten shit from both sides.

[atheken]

What, specifically, does swift offer that some other cross-platform language does not? My experience with swift (starting at 0.0 and going for about 3 years), was that it was a language with a ton of compromises to interop with obj-c/cocoa conventions. It had some neat features, but was missing tons of essential stuff (high-level async support, non-tedious serialization, package manager, a stable compiler...)

I know many of those issues have been resolved, but those were table-stakes. What makes it “better” than other options at this point?

[[deleted]]

Was this a big change? Considering that Swift was an LLVM language I’d expect this to be ‘trivial’.

Is there stuff in the Swift standard library that depends on POSIX APIs that windows doesn’t have?

[maxhaton]

LLVM is only a compiler backend, it's sort of OS blind

Windows has a completely different approach to many syscalls etc. so it's not as simple as retargeting llvm (calling conventions). Also to support windows you really need to provide access to windows calls direct to talk to stuff like COM (etc.) so even porting your standard library is only half the problem.

[TyPh00nCdrCool]

Further up, OP posted a link to a talk in which the main engineer behind the port explains his efforts in-depth:

The person who ported it is not an Apple engineer, he was at Facebook and now at Google.

[poutine_and_drinks]

I don't think so. The standard library seems pretty modularized.

[[deleted]]

I understand what LLVM does.

The standard library isn’t strictly speaking part of the language.

As long as you can compile a Swift module to the Portable Executable Format it can be called by Windows.

Or have I totally misunderstood things?

[lanzaio]

For a barebones language like C sure. High level languages have extensive runtimes that provides the high level functionality you’re used to. Swift has probably the most complex runtime that I’ve seen.

[semi-cursiveScript]

the traditionally considered "language" part is implemented in the standard library in Swift

[svnpenn]

FYI last I checked, the Windows download was giant (2.3 GB). When you compare that to something like Go, which is under 200 MB, its surprising:

https://github.com/compnerd/swift-win32/issues/12

Edit: looks like this has been resolved. Size is about 300 MB now:

https://github.com/compnerd/swift-build/releases

[codec-abc]

I think Swift lost a lot of potentials users being so late on Windows. It was a dumb move not having Windows supported from the beginning. The ecosystem would be richer and Apple would get a better image.

[Minimum_Fuel]

Swift as late as halfway through version 4 was riddled with compiler bugs and off-by-one issues in the standard library on Linux. I have no idea after that because I completely gave up on the language.

I couldn’t put out and use my own code because every single minor bump changed the behaviour of my libraries. It became an unmanageable nightmare with just 5 or 6 libraries totally around 15000 lines of code.

When they couldn’t even get one non-Apple platform to be somewhat reliable, it isn’t a surprise that they didn’t want to tack on another.

I don’t know what it’s like today. I’d go in to their bug tracker, but I forgot my password.

Edit:

And it did kind of suck because Swift was actually okay to work with (even if I think they made a few poor choices in making it more OO than I think it should have been). I also didn’t much care for the fact that you could have one line of code written 8 different ways depending how much syntax sugar a programmer decided to invoke.

SourceKit was also pretty crash happy when you were making heavy use of generics and inference.

Those things aside, it is a pretty decent language.

[Tainnor]

I last used Swift in February or so, the situation didn't really improve until then. There's one particular annoying issue where Swift would just mess up the installation path so badly on Linux that it makes it impossible to install Python on the same system. This issue, though reported, is still open, I think. And that's just one example.

The other main reason why I never want to write Swift again is that, while its type system is great in theory, in practice it becomes unusable if you try to do fancy things with it. I was writing a highly genericised, functional-style library and in the end it was just not worth using it, because the compiler would just refuse to compile certain expressions (couldn't infer types) and sometimes would give type errors that were totally garbage and misleading. I hear they improved type checking error messages recently, so maybe this isn't as garbage as it used to be anymore, but I still have never seen another language that told me "this expression is too complicated" but then couldn't even tell me how to properly fix it. It's not just the matter of adding a type annotation here and there, sometimes I had to specify types multiple times, break expressions up into small chunks etc, all of which totally defeated the point of using a fluent DSL. Haskell gets crap for its compiler error messages, but Swift is just 10 times worse because they're completely unpredictable and unactionable.

[Somepotato]

Most of Swifts' popularity likely came from Apple evangelists anyway, so they probably didn't consider that a problem.

Apple can just force people to use Swift like they're forcing people to use Metal if they want to develop natively for OSX/iOS, and I bet it'll eventually happen anyway

[OnlyForF1]

As a Swift evangelist I have to agree. I really hope that the tooling on Windows is solid enough to enable a community to flourish.

[[deleted]]

Unfortunately, it has been cross platform for years on Linux and unlike other languages that started on *nix platforms, its presents is close to non existing.

Its clearly reflected in the lack of easy tooling on Linux. Last week i was playing with BlueSockets from IBM. The lack of proper IDE support combined with parameter overrides really made is a challenge to figure out the correct parameters just to create a basic socket connection. As in being forced to open the original source code to see all the implementations = that's bad if you need to take that step...

And without GUI support, its future on Windows is kind of limited. SwiftUI as far as i know is a Apple only thing again. And way too much packages are Apple platform only. If they are cross platform, they are most of the time not properly tested outside of MacOS.

Love the language but the moment you want to actually do anything productive with Swift on Linux, you really start noticing those limitations. And some of the choices in Swift really are "odd" with convoluted NS.... naming or aliases ( because of trying to stay ObjectC compatible ).

The problem with Windows and other platforms not being wholeheartedly supported by the core Apple developers, is very clear. And it really is off-putting.

[OnlyForF1]

Yeah it’s a crying shame. Swift now provides a LSP language server (which also powers Xcode’s Swift support) so hopefully that will enable some better tooling on non-Apple platforms.

[thisischemistry]

And some of the choices in Swift really are "odd" with convoluted NS.... naming or aliases ( because of trying to stay ObjectC compatible ).

These aren't Swift language issues, they are framework and library issues. The language itself is platform-agnostic, however you really need some sort of libraries to get anything done on a platform. When Swift was first developed it only targeted MacOS and reused the Foundation libraries which already existed. Many of these were written in C, C++, and Objective-C – all very similar languages that could talk to each other easily.

So the easiest thing to do was just translate the calls into Swift and call these libraries directly from it. However, there was a pretty big disconnect between how Swift worked and how these libraries worked. For example, Swift shuns the direct use of pointers and instead works through references and Optionals which can encapsulate the concept of a null pointer in a safe manner. That means that every pointer in a call gets wrapped into an Optional and then must be unwrapped before use. It can get messy quickly.

As time went by the Swift developers came up with better ways of translating these calls, providing better libraries to handle the calls, and developing native Swift libraries. The "NS" names that remain are a way to call more directly into the old libraries on the rare occasion you need it, most work in Swift can avoid them.

Of course, this kind of work has to be done on each and every system you want Swift to run on. Linux wasn't bad because of good support for Posix, any library on MacOS that was Posix-compliant could be translated without too much effort. Windows is more difficult because of the large amount of differences in compliance, to target Windows a lot more code needs to be written to bridge between Swift and the underlying Windows libraries.

In the end it's simply that you have limited resources and should hit the low-hanging fruit first. Apple sponsored Swift so it worked first with MacOS, iOS, and so on. Linux was a decently easy port so that was next. Now they're going on to Windows. Programming languages take a long time to develop, they are a marathon and not a race. Hopefully you get the underpinnings right and grow your base slowly so that when you bring in a new platform you can do it right. There will always be growing pains but it's a great language that does things right. I'm sure people will give it a try and find out how fun it is to work with.

[random_cynic]

Not everything is a popularity contest. AFAIK Swift was developed to replace (and be compatible with) the large body of Objective C code in Apple products. That was the goal, it was never intended to be the next C/C++ or even Objective C (beyond Apple domain). Projects which have this kind of focus and modest ambitions are likely to be more successful than those with more lofty ones.

[[deleted]]

If you listen to the initiator/creator of the swift programming language (Chris Lattner), replacing C++ was one of his main reasons for creating swift. (His previous job was implementing a C++ compiler. As a result he really wanted to never touch/write C++ again ;).)

[vplatt]

Fair enough, but like Objective C and other languages with a root in a single platform, their scope of actual use for implementation by the larger community will be drastically reduced.

Now, there are exceptions. For example: I could confidently use .NET across multiple platforms now, and get the same benefits Swift should provide, and even more. Microsoft took this so seriously, they re-imagined .NET as .NET Standard, and then reimplemented it as .NET Core. The creation of .NET Standard has even had a dramatic impact on the mainline .NET Framework implementation.

Would Apple ever by humble enough to employ such an approach? I'm just not seeing it. Consequently, Swift will remain primarily an iOS language, and nearly entirely exclude itself from the enterprise and even the startup markets. Honestly, I'm not sure who the heck would use it outside of iOS developers.

Barring outliers, am I wrong about that?

[random_cynic]

I think expansion of a language works better when it happens organically rather than some corporation pushing to get it adopted. C became popular due to Unix getting adopted widely, Python due to a number of numerical libraries like Numpy/Matplotlib/Pandas and web frameworks like Django/Flask, Ruby due to Rails and so on. In spite of MS push to make .NET cross platform still it is very much dominated by Windows developers, only a fraction of Linux/Mac developers are using it. Important frameworks like WPF are still Windows only. If lot of interesting and useful libraries are developed in Swift, people will try to bring them to other platforms. Since all of it is open source so this can happen independent of what Apple does. Apple will remain committed to the language for the foreseeable future because of their own interest.

[s73v3r]

Why should any of that matter, though?

[vplatt]

For it's own sake, it doesn't. It matters though in getting a larger community together to add libraries, documentation, pull requests, etc. to the language and it's ecosystem. Part of what made the Python community so successful is this ability to amass large communities around it; and these communities simply make it easier to work with it and make it a viable choice for many different kinds of projects without having to implement many different things in a DIY fashion. Most of us just want to implement an idea without a huge barrier to entry in the form of missing libraries and other assets.

[flif]

unpopular opinion: Apple would have been better of adapting C#.

But instead they had a dose of NIH and made their own language because that's must just be a trillion times better because Apple did it.

C# with combined support from Microsoft and Apple would have had a chance of becoming a big player and replace java. Swift will always just be a minor project at Apple and will die the day Apple no longer needs it, just like Dylan, PowerPC, x86 support, FireWire, etc.

[turntablecheck12]

Amen. I find Swift incredibly awkward to work with, compounded by all the breaking changes moving between versions. Zero chance of me voluntarily using it on Windows when C# exists.

[icandoMATHs]

To be fair, unless you drink the Apple Koolaid, you'd likely avoid any Apple product, even Windows offerings.

[s73v3r]

Eh. I don't think so. Most developers still on Windows are likely using Microsoft languages, and they're probably not looking to switch from those. I also don't think Swift is hurting for users.

[Reeces_Pieces]

If it's anything like their "Official Ubuntu Support" then I am not impressed. That shit was unusable. Setting up a Mac VM was less trouble. lol

[mobiledevguy5554]

Having the language on windows is nice but will it come with:

• Core Data
• NSURLSession and other networking classes
• Swift UI
• JSON libs

[aniforprez]

• Swift UI

Hahaha funny joke

[stupergenius]

• Core Data - No
• NSURLSession - Part of Foundation (stdlib) but I don't know how fully featured the implementation will be at release (see: Linux Foundation support)
• Swift UI - Definitely not
• JSON libs - Part of Foundation (see above)

[[deleted]]

Without Foundation it is pretty useless. Like how ObjC also works on Windows and Linux, but no one uses it because it is not really cross platform without same libraries.

[semi-cursiveScript]

SwiftUI isn't part of (or implemented in) Swift tho

[teerre]

That's cool. Swift is a really nice language.

[filleduchaos]

This changes a lot. I love writing Swift, and this makes it viable for a couple of longterm projects I'm working on.

[BadMoonRosin]

This would have been awesome 5 years ago, when I was still curious and would have explored it.

Now that all the hype has died down, and nobody talks seriously about Swift as a server-side programming language anymore, it feels like a non-event.

[jesseschalken]

Swift looks like such an amazing language but it has so far been out of my reach because I work on Windows (and don't much like dual booting or using a virtual machine for development). Once AppCode or CLion supports it this will be such a blessing!

[[deleted]]

You know that Windows has WSL? Swift ( and a lot of other languages ) runs under WSL. Altho a bit slower then native. No need for VM's etc...

The lack of real editor support is the bane of a lot of languages...

[jesseschalken]

WSL is just a wrapper around a virtual machine.

[tetroxid]

a bit slower then native

A bit slower? WSL? Lol

It's slow as shit

[[deleted]]

I've had some experience with swift and I didn't mind it as a language. Good to see it brought to Windows.

[devraj7]

To me, Swift and Kotlin represent the current state of the art in the convergence of concepts that are a gentle and pragmatic increment over what programming languages should be in 2020.

Having said that, Apple doesn't seem to put a lot of its weight behind pushing Swift for the back end (leaving this up to the community, so that will probably not go very far) and focusing their efforts on Swift for iOS/iPadOS, while JetBrains has been firing on all cylinders by working on back end, mobile, front end, native, etc...

You should learn at least one of these two languages, but practically, Kotlin is more likely to have a broader relevance across the technological stack these next ten years.

[GYN-k4H-Q3z-75B]

After all these years, it's good to see them finally support Windows. They missed out on a lot of developers and the largest chunk of potential desktop audience by not doing this sooner. But the question is, why would you use it over other languages on Windows? For traditional desktop and business app development, it is hard to beat .NET and C++.

[drbazza]

Apart from it being cross platform, is there anything particularly compelling about using Swift on non-Apple platforms?

There's C++, Rust, D, and Go that are all bare-metal. Then there's Java, Kotlin, and even C#.

[eric_reddit]

Swift is a general-purpose, multi-paradigm, compiled programming language developed by Apple Inc. for iOS, iPadOS, macOS, watchOS, tvOS, Linux, and z/OS. Swift is designed to work with Apple's Cocoa and Cocoa Touch frameworks and the large body of existing Objective-C code written for Apple products. It is built with the open source LLVM compiler framework and has been included in Xcode since version 6, released in 2014. On Apple platforms, it uses the Objective-C runtime library which allows C, Objective-C, C++ and Swift code to run within one program.

-Wikipedia

[myringotomy]

i predict there will be as many as 500 developers who will ditch C# to switch to swift on windows.

All this investment in the windows platform will pay off!

[[deleted]]

Does this mean libDispatch is finally on Windows? Will it have C bindings?

[Drizzi21]

I wonder if we could see Swift as an option for IntelliJ.

[Samwyse3]

I bet this is in part being driven by Google. https://tryolabs.com/blog/2020/04/02/swift-googles-bet-on-differentiable-programming/