@Max_Desiatov well said. You voiced most of the concerns I personally have for Swift. I fear that it will follow the path of Objective-C and be mostly “an Apple language”.
Much of the recent years popularity of Swift and Objective-C was driven by the rise of the iPhone and iOS development. Nowadays I see an enormous pressure from cross platform solutions like React Native or Flutter especially in the enterprise space. Even the iOS stronghold is starting to weaken which will have a negative impact on Swift popularity outside of Apple.
1 Like
There's still plenty on the implementation that we could see changed that wouldn't affect the public API at all.
I don't really have anything to say about Apple surprising us with this language feature, I think it could be a great addition.
I do have to say that the feature is extremely limited in it's current form. It's frankly not going to be very useful if we can't use switch statements or true for/while loops. I assume these are in the works, but in its current state it falls well below the hype being heaped on it at WWDC.
+1 to the idea, but devil is in the details.
3 Likes
I think every successful new language is tied to some niche. Kotlin will be mostly Android only, C# is PC Apps, Java ist Server Side and Android, Swift is Apple Devices, Python is AI/ML, JavaScript is mostly Browser, etc.
C and C++ are probably the only general purpose languages even in the next decades.
And Rust ist trying hard to find its niche - as for a replacement to the general purpose languages it lacks the progressive disclosure attitude.
I think the niche/domain Swift is in is not too bad actually. And who knows - maybe another one will be eventually found outside the Apple ecosystem.
Just as a sidenote in the context: Even though I quite like the actual outcome, the process which lead to SwiftNIO was indeed no different. There was a Server Side Swift Group for quite a while (1-2 years?), with people providing API suggestions and actual implementations.
While at the same time Apple developed NIO in its usual secrecy, for roughly a year. It even participated in discussions well knowing that a replacement was in the works. When it was done, it got announced and the sssg work discarded and later reestablished around NIO/Apple (w/ some members not even really deploying NIO ...).
But if the stuff provided is good, why complain? ;-) Apple is putting a lot of effort and resources into Swift, other languages don't necessarily have that. The primary feature of NIO is not that it is open source, but that it actually works and is well designed.
Everyone is perfectly aware that Apple doesn't do such stuff in the open and that you have to expect being sherlocked.
I guess all I'm saying is that the NIO, and I think 4TF too, both have been developed "in a closed environment". And that wasn't a bad thing after all :-) (Contrast that with say SPM, which was developed in the open ...)
10 Likes
While we all know it, it's not a good thing, and not something we should readily dismiss as if it's merely "the cost of doing business". Apple might be putting tons of resources into Swift, but don't forget, they're investing in it because it's in their best interest (and of course, I have no problem with that).
But don't treat it like charity. For one, many people in the community spend loooooots of their own free time and effort to advance the Swift ecosystem. They deserve a level of recognition and respect that's higher than "oh here, we worked something in secret for a year so now your project is useless ... but it's free, so you should be happy and grateful".
3 Likes
As someone who spends a lot of time providing crucial OpenSource Swift packages (like cows) I'm very much aware of that.
I'd be more concerned if awesome contributions by the community would be proactively rejected (which I think has never really happened). I'm not so much concerned if Apple does complex, effort intensive, nice stuff and even allows the community to pitch refinements prior final release.
"oh here, we worked something in secret for a year so now your project is useless ... but it's free, so you should be happy and grateful"
If it is substantially better than the previous proposals? AFAIK few or no people complained about NIO for example. To the degree that it is even proposed as a good example for OpenSource-Swift as we've seen as part of this thread ;-)
(sorry, looks like I hijacked the thread, I just wanted to point out that how NIO came into existence is not that different, it is not a typical FOSS community project either)
2 Likes
I want to express how much I appreciate everyone's candid, thoughtful and passionate input on this thread. I think the discussion here has been very good.
Aside from the function builders feature (now being discussed) all of the language features that are used by SwiftUI have been either gone completely through the evolution process or are close to being wrapped up:
- Opaque Result Types
- Implicit returns from single-expression functions
- Property wrappers (nee delegates)
There's probably others I'm missing, but they all went through the evolution process. Even the priority of proposing SE-0254 was indirectly motivated by SwiftUI, although it ultimately turned out to not be necessary (but a good addition to the language nevertheless).
Property wrappers is an excellent case where the evolution process played a crucial role in shaping a feature. While the proposal hasn't completed the full evolution process, it has gone through a review and multiple rounds of pitches, and the Core Team had already decided and publicly stated that the feature was going to be eventually accepted into Swift. What's in Xcode 11 is a preview of a feature, and the evolution review process needs to focus on deciding the final details. Even the renaming of the feature from property delegates to property wrappers was an outcome of the evolution discussion.
Regarding functional builders, I think it's important to dispel a potential misconception that this has been sitting in a cask for an extended period of time awaiting some public reveal:
Function builders was not a planned “surprise reveal”. Function builders emerged as a fairly recent solution to a problem after lots of design iteration and trial and error.
So why is it function builders coming up now on Swift Evolution:
-
It was recently developed, and all evolution proposals require an implementation. A change of this magnitude certainly needs to be put through its paces to demonstrate that it works and is cogent and cohesive.
-
We (on the Apple side) also got very close to WWDC and had a lot of plates to juggle. At some point it was so close to WWDC that running the pitch before WWDC wasn't realistic. We were also hammering out the details for a proposal until very recently.
I think pretty much everyone — including the folks at Apple — would have preferred to have had time to bring this to evolution before having it in beta tools. That said, the tools are still previews of a yet-unreleased stuff and details can change. It also probably helps the discussion to be able to see how the feature is used by SwiftUI.
I think the following statement from @GetSwifty summarizes what's going on well:
If anything, a feature like this really needs the oversight of the evolution process to ensure the right short-term and longer-view decisions are being made.
It is true that...
- The Core Team are the ultimate deciders in what goes into Swift
- Many of the folks on the Core team work at Apple and were involved in the conception of this feature
... but it also remains true that the evolution process remains an invaluable part of the evolution of Swift and will play an important role in the evaluation of this feature.
79 Likes
Now that I think about it, a surprise reveal would be SwiftUI, not Function builder. 
3 Likes
Out of curiosity, is SE-0257 Eliding commas from multiline expression lists related and used in SwiftUI. I'm not seeing commas on the snippets so I assume it is but you didn't mention it ^^'
2 Likes
No, SE-0257 is not part of the SwiftUI DSL. The component values in a function-builders DSL are grammatically statements; if you want to explicitly separate them, you must do so with semicolons, not commas.
We think function builders are a better language direction for multiple reasons, but the feedback to SE-0257 unquestionably shaped the direction we took.
13 Likes
I'd just like to show my support here. Like basically every heavy Swift user, I was super happy in seeing SwiftUI, but also surprised and a little concerned, because it seemed to clearly rely on either:
- some "unannounced" Swift feature;
- hacks and magic.
But I'm actually thankful that it's going to be about a new feature, developed internally over progressive iterations, and it's great to see an actual pitch and draft proposal, for discussing details and move towards the final shape of this.
To me it's extremely important that there's a motivated core team that ultimately decides what goes into Swift, which of course means both what doesn't go, and what goes no matter what: it helps keeping the language consistent and opinionated, and I don't see this as a restriction on what the community can achieve as a whole.
10 Likes
I want to express my gratitude for what the core team and Apple has done here! I think it’s great!
I also think the process used is something we as a community should get used to.
It’s the best of both worlds - big money/muscles, long term commitment and vision together with the many eyes/opinions/use cases and ability to get your voice heard with the open source community.
Puritan open source advocates will not like it - but I think you are doing everything right here, and getting the best of both worlds!
I for one like these huge, surprise announcements at WWDC - and wouldn’t like it to change!
So a huge thank you for your great work!
13 Likes
My $0.02
Similar to SwiftNIO and Swift-Log I see the Core Team as iterating on things and releasing them to the community. The fact that it was even released to the community for review is a sign of good-faith by the team to engage the community. Most folks have already said that they can't use it because it doesn't support iOS 12, so unclear why there is so much flack. Even if SwiftUI itself doesn't become open source, DSL as a concept can be used by the community to do great things.
10 Likes
I followed a number of language development forums over the last 30 years.
I can only say that most of them had, and benefited greatly from, a "benevolent dictator".
1 Like
i know c++ and i used to think c++ was just an excuse but today i encountered an auto tryTypoCorrection = [&] { }; in the swift compiler and that was when i decided to leave the c++ be
3 Likes
Off-topic: That's just an empty lambda that captures referenced variables by reference.
1 Like
Note that you can’t usefully reassign that variable, because it’s an auto and different lambda’s have incompatible types.
It’s a local func, and if it could be declared that way it would be.
I think C++ is a flawed language in many ways, but its problems have taken on a life of their own in internet discourse beyond all connection to the language itself.
10 Likes
I don't really mind the Core team deciding things unilaterally. Language design is not a democracy and shouldn't be. If anything, I think that sometimes too many people try to influence Swift in their own way, leading sometimes to inconsistent language design.
However, in this case, I echo @Max_Desiatov's concerns about the language losing focus. In order to introduce a feature like SwiftUI, it seems that so many low-level design decisions would need to be made first, that the risk of unduly rushing these decisions seems quite high.
To me (admittedly as a non-app developer), it looks like Apple is reprioritising important development resources in order to satisfy some marketing promises, instead of fixing and improving core issues with the language first.
But it's Apple's decision to make, just as well as it's every developer's (or company's) decision whether to want to invest in Swift.
14 Likes