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.
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 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.
There's no such indication. "The number of binaries using Objective-C is still growing with each iOS release." https://blog.timac.org/2020/1019-evolution-of-the-programmin...
This is not true either. "the number of binaries written entirely in C is now stagnating"
> the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year
This is true. But it's a much weaker claim than the one I was replying to.
In other words, the reports of Objective-C's death have been greatly exaggerated. ;-)
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.
There are already controls in Big Sur and iOS 14 (Color Picker) which are SwiftUI and bridged to UIKit/AppKit.
Which just happens to be one of the biggest development niches in the world.
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.
IBM dropped Kitura more than a year ago [1]. There's Vapor [2] which seems popular, but I don't know how much.
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
[1]: https://vapor.codes [2]: https://github.com/apple/swift-nio
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)
There is no way out of it.
* 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.
> (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.
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?
interesting, what could be added/changed to make it better?
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?
Generics are supported through associated types.
I'm curious if you've seen https://docs.microsoft.com/en-us/visualstudio/python/debuggi..., and if so, to what extent it helps with C++/Python interop in TensorFlow context?
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 expressionsSwift 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..
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.
(No language war please ...)
Nope, NGEN exists since .NET 1.0, .NET Native since Windows 8, Mono aot since ages, and then there are the third party tooling like IL2CPP.
There's nothing wrong with this. Swift can be the best language for the Apple platform and find lots of success in that.
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 took the code and extended it, they had little choice for the source code license.
The churn may not be a deliberate strategy but it is certainly very effective in locking developers in.
[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.
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.
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.
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.
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.
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?
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.