Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous.
Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development.
I love this language, but i'm eager to see it handled by a proper foundation with big names behind, as it's a really great language.
>a very niche market of 100% native mobile development
I mean, it also works for native desktop development. And is there really an issue with that? Objective-C basically had no reason to exist beyond iOS/Mac programming and at least now we don't have god damn [myString stringByAppendingString:@"another string"].
I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both).
I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems.
That said, I have not done system programming for a long time (unless you count drivers). I think Swift is an almost ideal application-level language.
I'm not especially bothered by it being Apple-only. It works on all Apple-supported hardware, has a new application toolkit coming into play (SwiftUI), and has a very active development community. Spend some time on the Swift discussion forum to see some pretty heady discussions.
I'm a little bit confused by this comment. Obj-C is, in a lot of ways, the _higher_ level language on Apple systems now, and most of what I would consider "systems" programming on macOS and iOS is in C, assembly, and C++.
You can more or less write C in Swift as well, though. Some pointer operations get more verbose, but the standard library also makes some stuff easier. The only thing that's really missing is a nice fixed-size array syntax (they get imported from C as tuples, which is not ideal).
I suspect we will hit an inflection point where Objc is bridged to swift code rather than the other way around - no reason to let Swift be the one taking the interoperability hit.
There are already controls in Big Sur and iOS 14 (Color Picker) which are SwiftUI and bridged to UIKit/AppKit.
We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.
If you look closely at how that data was collected, what it's actually measuring is whether a binary links against the ObjC runtime library, which will be the case if a binary transitively depends on any ObjC framework, so even if all new frameworks and executables were written in Swift, we would still expect to see the number presented in that post to continue to grow until most or all of the important frameworks using ObjC are rewritten entirely in Swift. I don't think this data is sufficient to say one way or the other to what degree that is occurring.
Fair criticism. I'm not sure why the author didn't try to detect the use of objc_msg functions, for example. So the ObjC binaries may be overcounted a bit.
Still, the test for Swift binaries seems accurate, and if you look at iOS 13.1 vs 14.0, for example, according to the chart there was an increase of 157 Swift binaries and 446 Objective-C binaries. If we assume there are 157 "false positives" in the ObjC binaries, that's still an increase of 289 ObjC binaries that don't use Swift at all.
D'oh, right. A good test might be difficult. In the absence of that, I guess the safe bet is just to count every Swift binary as a false positive for ObjC, though that's not quite fair, since you can mix the two in the same code base.
The number of binaries of all languages in iOS (except C) increases year over year, so that doesn't really mean anything. It's more telling that the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year.
We'll see. Off the top of my head, only Combine and SwiftUI are Swift only for now. And Combine has specific features that are explicitly meant to make it interop with ObjC (and @objc Swift) objects, e.g. KeyValueObservingPublisher. The other "hot new" Apple frameworks, like CoreML, ARKit, HealthKit, ResearchKit, etc. are all still written in and usable from Objective-C. They _are_ starting to use Swift(UI) in UIKit, but so far continue to wrap it in an Objective-C interface.
not really.. games are made with 3D tools (unity, etc), Form-based "data oriented" apps are made with cross-plateform tools (react native, xamarin, flutter, etc).
The only things left are a very small percentage, and add to that the fact that you either 1/ have the budget for 2 development teams, or 2/ afford to skip the other "half" of the market staying iOS only.
> I have the feeling swift never really worked in the server side
Vapor [1] is wonderful to work with and has a large user base. Apple is also putting significant resources into Server Side Swift with Swift NIO [2]. Lots of really cool stuff happening in that ecosystem
I don’t think swift’s performance is good enough to really make a dent in that area vs rust/java and C. Nor are its macro-programming ability enough to compete with dynamic (and slow) languages.
Now there’s still go market of « server middleware ». But for that it would need a much higher quality of core libraries, tooling, and a much better concurrency story. Maybe it’ll come with the incoming actors, but somehow i doubt it (the underlying concurrency libraries remaing grand central dispatch, which looks too heavy compared to, for ex, goroutines)
Swift lovers have to grasp that unless Apple actually puts the effort like Microsoft started doing with .NET, it is going to be used outside Apple eco-system as much as Objective-C has been used in the last 30 years.
It seemed like Swift looked like a promising language for data science a few years ago. I'm not familiar with Swift. Can anyone provide additional context as to why the language seemed promising for data?
I disagree with the pitch, but the pitch I heard when this was announced was:
* Swift lets you write code that's as concise as Python while still being fast, and therefore allows you to get away from the problem of having to write ML code in multiple languages (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.)
* That the lack of static typing is a major pain point in Python, and Swift's type system would help write code with fewer errors.
> Swift lets you write code that's as concise as Python while still being fast,
> (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.)
To be honest, if I had to choose between Python and Swift I'd still choose Python. Swift is a nice evolution from Obj-C and all but it is nowhere near as simple as Python, or Ruby, or PHP, or Javascript, or Kotlin. And Apple's documentation of these things is pretty woeful at the best of times lately.
I also disagree with the pitch, is what I'm saying.
To say that Swift is "nowhere near as simple" as Javascript or Kotlin is a very strange opinion to me, and I have experience with all 3.
Simple as in syntax, memory management, or in what regard? I can't think of a single example where Swift is not equivalent or better. Do you have the same criticism of Scala?
Swift has no traced garbage collector which means you cannot represent circular data structure/references.
Also swift support for interfaces (protocol) is sub-par with today standards
No support for default implementation methods.
No support for generics in protocol.
There might be workarounds but for a newcomer, this is a red flag of reinventing a basic and universal construct (interfaces) in a sub-par one, this show a dangerous mentality from the swift vm devs, what else did they wrongfully reinvent in a sub-par way?
I think considering swift as merely an evolution of obj-c is a drastic underestimation. Swift is a very nice language in its own right. Having spent time with most of the languages you've mentioned, while the learning curve might be a bit steeper, I think Swift is much easier to manage a medium or large project with than any of those options with the exception of maybe Kotlin, and personally I find some of the design choices a bit better in Swift than in Kotlin.
I don't get the hype about Swift. There are at least 4 features in Swift I can think of that are just plain clunky:
1. Backslashed opening parens for string templating
2. Parameter labels and the use of _ when ignored
3. Splitting method names across opening parens eg. `move (to ....`
4. Verbose NSString Objective-C hangover in regular expressions
Those are really minor syntax details (except maybe the regex stuff, that’s more a library issue than a language one).
Swift is safe (no null pointer exception), has predictable garbage collection performance through ARC, has a familiar C-style syntax (easier to get on-board), has compile-time type checking, good-enough generic programming support, algebraic data types with pattern matching, and will very soon get actor support.
Plus, it has the potential to become a good cross-platform language since it’s using llvm, all it needs is a bit more love on tooling and libraries.
I don’t see many other languages with those characteristics..
Swift just seemed like yet another OCaml-like language to me; there are certainly far worse languages to borrow from, but I don't see any compelling reason why I'd use it over OCaml. ARC has the same worst cases as mark/sweep GC AIUI; exiting any scope might cause an arbitrarily large amount of cleanup work in the general case, and it doesn't solve the memory fragmentation problem which is the main reason you still need to occasionally stop the world (ish) in a mark/sweep GC.
I agree from a technical POV, but there is a social reason (network effect): Swift has Apple-backing, OCaml is not currently supported by any of the big,
influential software companies. OCaml's main backer now is Jane Street
who do a lot, but is too small, and Facebook's support (via ReasonML)
is too half-hearted to be compelling. As a former OCaml programmer, I
would not currently bank a career or startup on OCaml. Indeed I've
been doing OCaml programming over the last few weeks (and seen the shortcomings of OCaml's current library eco-system vis-a-vis more mainstream languages) in order to
interface with a big existing OCaml development, and they told me they
decided to move to Rust for all future new developments.
I say this with a heavy heart, as somebody who spent his first decade
as a programmer with OCaml.
Interestingly, even in Feb 2021, there is no compelling mainstream alternative to OCaml (in the sense that e.g. Jane Street are using OCaml):
Haskell's being lazy, Java/Scala etc as well as F#/C# being JIT'ed
make performance predictability difficult. Rust does not have this
problem, but for many tasks where software engineering agility is a more
important consideration that extreme performance (which might be most in-house business software?), a GC'ed language
would appear to be more suitable.
Thanks. I was not aware of this, since I've not worked on a Microsoft stack for a long time. Are those F# AOT compilers mature and support all features, including libraries? In this case F# would be a viable alternative to OCaml for Jane-Street-like tasks.
yeah, they're doing the world a favour by taking the code and conform to its licence, as opposed to... developing a new browser engine which is... easier?
WebKit got forked into Blink, which is no longer under Apple leadership. Brave, Chromium, and the other major KHTML-derived browsers adopted this.
I can think of dozens of examples from Microsoft and Google, which are more "outside ecosystem" inclusive as a means of gaining mindshare. TypeScript, Golang, Visual Studio Code, protobuf, gRPC, ...
Other companies think of the things living outside their moat more flexibly, or their moats are less rigid. That's not to say that Apple's approach is wrong (look at their market cap!), but it has different consequences in terms of the open source code mindshare they cultivate.
Apple churns languages every few years? They kept Objective-C around for 13 years before introducing Swift, and that was a language that was widely disliked by people from outside the Apple ecosystem. You can still use it for the vast majority of OS features today[0], nearly 20 years after it was first used on Apple platforms. Heck, Obj-C is used for Mac/iOS development because that was the preferred language for Mac OS X's immediate ancestor, NextSTEP, which means that it's been a part of the same development ecosystem for about 30 years. If this is churn, I think I'm okay with it.
[0] As far as I know, the only system feature that requires Swift is iOS 14/macOS 11's new widgets, which must be written in SwiftUI.
Next is not MacOS so I think it’s a real stretch to claim that means long term support! Perhaps some of this is normal but I think Apple have made little effort to avoid churn and it suits them to keep things changing.
Apple have had significant churn in dev tooling, languages, sdks, frameworks, chip architectures over the last couple of decades. Perhaps that is completely normal but it does mean developers are always struggling to keep up, and an app written for iOS 1.0 needs significant alterations if not a rewrite to work with later versions. Almost everything has been completely replaced, from language to frameworks to dev tooling like resources.
Right... Because Apple has done that so many times... oh wait they have done it exactly once since re-launching after acquiring NeXT. IT was Obj-C and now it's Swift except they actively support Obj-C still, so I'm not sure what you are talking about?
Java was introduced alongside Objective-C, with a common bridge to call into Objective-C runtime, as Apple was unsure if the Apple developer community would be welcoming to Objective-C.
They dropped it after the community was more than happy to adopt Objective-C.
About the same time they introduced PyObjC support and for a while there was MacRuby, which due to internal politics was eventually dropped, the creator left and now sells RubyMotion for mobile development, originally based on it.
Then if we switch back to the System days, there was Object Pascal, replaced by C++ frameworks, Hypercard, Lisp, Dylan.
Nice shifting of the goal posts. Introducing a possible technology while supporting your main one is hardly the same thing. Since Next became OS X Objective-C has been supported and it has been the main focus of development until Swift. Apple is a different company after Next, the System days have no real bearing on modern Apple. Java, PyObjC, and MacRuby were all attempts to offer more ways into the main eco-system. They were never attempts to support a new dev environment. Swift is the only time Apple has done that since Jobs returned.
> Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous.
Are you nervous about a language that is designed and supported by the largest and most successful company in the world?
> very niche market of 100% native mobile development
That "niche" is at least 1.5 billion devices. Devices bought by the 1.5 billion richest people in the world because they like them, not because their employers forced them to. Seems like a pretty ideal "niche".
But I wouldn't agree that "swift never worked server side". I've built several backends in Vapor and it's amazing.
> Are you nervous about a language that is designed and supported by the largest and most successful company in the world?
Yes, I am. The concentration of power between facebook and google for ML frameworks is worrying enough, but to their credit, they have so far been very open and collaborative and are giving a lot back to the ML community in terms of research
Apple on the other hand is the dictionary definition of walled garden. Their controlling and insular nature has been the reason for their success, and power to them, but for something as fast moving and community driven as machine learning, I would be very wary if relying on them for any part of it.
I think there is too much focus on Swift as a general purpose language. I really enjoy working in it and it’s great at what it does, does it have to be deployed in every domain?
What possible future are you trying to ward off here? Swift is an open-source project, it's self-evidently in Apple's interest for as many people as possible to use it.
Be concrete, please. What scares you about using an open-source language which is mostly developed by Apple? Do you have the same paranoia about clang? If not, why not, what's the difference?
iOS doesn't come as 100mb cellular downloads, so that isn't really the same kind of issue. There are many reports about showing how it's slowly coming into wider spread use at Apple.
For me the lesson is that just because a new technology/language is out doesn't mean you should jump on it. Things need time to mature, and if you're Uber, you can't risk having half of your income rely on something new. Compilers, linkers, and programming languages (and databases and OS kernels) take years to mature. Hell, just earlier this week was a post about diagnosing a 21 year old bug in the Linux networking stack for rsync of all things.
I'm quite shocked that enough experienced people felt that level of confidence. In earlier versions of Swift I personally experience slow compiles and that was on a not terribly large code base -- no where near Uber. That alone should have been a big clue of the state of things.
Uber doesn't have any pressure to have a reasonable tech stack because they don't have to be profitable (because they're an investor charity). On the other hand, having a fancy tech stack helps with recruiting.
Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development.
I love this language, but i'm eager to see it handled by a proper foundation with big names behind, as it's a really great language.