8 ms·
This seems like a super interesting feature to have as part of a language. I hope Swift can eventually become more of a general purpose language, as its actuall
by DenseComet 5y ago
This seems like a super interesting feature to have as part of a language. I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. However it seems right now its tied to much to just iOS development and Xcode, which doesn't make for a great experience using it for other things.
- tempodox 5y agoRight, you will never get your hands on a newer Swift compiler without also installing a whole new macOS with it, which is unacceptable for me. It's a shame, because Swift isn't a bad language.
- DrBenCarson 5y ago> Konrad Malawski is a member of a team developing foundational server-side Swift libraries at Apple, with focus on distributed systems and concurrency
- eklavya 5y agoIf I am not wrong he also worked on Akka, the distributed actors library for Scala.
- acjohnson55 5y agoYep, absolutely! He did fantastic work for Akka. Didn't realize he had left the Scala world, but good for him for taking the vision to other ecosystems.
- drewhk 5y agoNo, you are not wrong: https://akka.io/team/ https://akka.io/team/ (check the Honorary Members section)
- ternaryoperator 5y ago> I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. I hope for this too. I did a personal project in Swift on Linux and found that I loved the language. However, I was greatly frustrated by the lack of libraries. For Swift to reach the mainstream, IMHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I would vote for that even ahead of adding new features to the language.
- xvilka 5y agoI hope not, at least until they solve it being Apple-only. Of course, there's some support for other platforms but it's pretty bad. At this point it's better to invest time and money to the Rust ecosystem.
- ecs78 5y agoI think the language and runtime are evolving too fast for good support of other platforms outside of NIO based apps running in a Docker container. This should change once Swift has all the features originally planned for it. They are getting close, but there are several areas that need work. The biggest is an ownership system. But there is also variadic generics, extensions to the pattern matching system, c++ bridging, completing some missing concurrency features, SPM features, and lots of optimizations. Cross platform support is mostly for early community building right now. Much of it funded by Apple directly. Maybe around Swift 7 or 8 it will be better suited for other platforms.
- DaiPlusPlus 5y ago> MHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I suspect Apple is trying to do this for straightforward reasons like wanting to remain relevant and foster community growth as to retain credibility… while also subtly trying to not encourage the use of Swift as a language for any other GUI framework/platform than Cocoa + macOS. Obviously I don’t have any evidence to support my fantasy speculation (well, X11 for macOS is dead) - but consider how Apple is so very protective of their UX moat (and PWAs be damned). It’s not in Apple’s interests to facilitate and support any kind of true cross-platform UI framework: remember how Java AWT/Swing apps were like on OS X? The majority of dispassionate (I.e. not Panic Inc) devs are never going to optimise a cross-platform UI for macOS because the whole point of using an xplat UI is so you don’t need to spend time on platform-specific code. Those two reasons combine form a vicious-cycle negative feedback loop that devalues their platform. But with the web finally becoming the true, real, cross-platform that Microsoft was then-irrationally terrified of 25 years ago, I don’t know what Apple’s strategy is to remain the best provider of the best UX when everyone is going to be using Chromium in some form. And if Apple keeps pushing their own native apps devs to their hostile App Store while everyone else moves to the web, then the value-prop of an Apple computer looks bad compared to a Chromebook which is essentially just-as-locked-down and just-as-capable, just without iOS integration and a modest selection of (albeit) high-quality boutique Mac App Store apps. ———— On a related note: Apple does not have long-term support commitments as a matter of policy - which means enterprise/slow-moving/blue-chips won’t be interested in using Swift at all (compared to ISO-backed C++, Oracle’s Java, or MS’ .NET). Apple is going to have to maintain Swift’s support for Win32 and *nix in the long-run if they need to build their credibility and win-over large programming projects - but it’s just so against their corporate culture. It reminds me of their middling support for Safari for Windows. I know Apple gets Win32 and nix support for Swift “for free” by piggybacking off Clang+LLVM, but that’s basically the same as making Swift more like Java (“xplat for free”) but that’s just the bare-minimum they need to do: without Apple actively investing significantly in the developer experience for non-Apple platforms it just isn’t going to take-off. And they can’t do that for fear that a critical-mass of hackers will port Cocoa to Win32. Swift is basically analogue to Google’s Dart+Flutter but it wants to be like Go.
- metaltyphoon 5y agoWell, this seems interesting. https://ericsink.com/entries/sourcegear_bridge.html https://ericsink.com/entries/sourcegear_bridge.html
- eyelidlessness 5y agoMy experience is the opposite: using Swift for Apple ecosystem development basically removed all of the benefits that Swift the language offered. It’s clearly designed as a general purpose language, and its adoption mostly curtailed by this reputation.
- ChrisMarshallNY 5y agoI’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I like what I see). I’m interested in shipping, and shipping is almost always a couple (or more) steps back from “the bleeding edge.” In my experience, there’s not much of a downside to waiting for tech to mature and stabilize, other than not having jargon on my CV. Swift was unusual for me. I started learning it, and releasing apps in it, right away. It was a gamble, and it paid off. There’s lots of folks that are probably just getting started with Swift, now.
- eyelidlessness 5y agoTo be clear, I quite like Swift and did from day 1. Granted I’ve only tinkered with it. What I didn’t like was interacting with Cocoa APIs. I found it difficult to use Swift’s protocols and structs in a FP style, because Cocoa isn’t designed that way. I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
- ChrisMarshallNY 5y agoCocoa uses classic MVC, and actually started from NextStep (last century). UIKit smoothed it out a bit, but it’s still MVC/OO, under the hood. SwiftUI was developed from the ground, up, to use FP concepts, and things like Protocol-Oriented Programming. I’m looking forward to learning it, but the fact that most of the Apple world runs on tech from a design that was developed in the 1980s, should be an object lesson in the structural integrity of “classic” OO, and the MVC pattern. We rubbish the past at our peril.