I heard that Swift can be used for anything you need. Is that true? If I am to start a technology company can I use Swift exclusively for its software architecture? Would you recommend that I use Swift for everything I program with? Is Swift really the programming language of the future?
1 Like
The answer is yes. You can do almost everything in Swift (I think only except some specific low level stuff) but you would barely need it.
And about the recommendation. I would say that you should have a lot of tools in the box. Swift is not the most popular choice for backend, web frontend and internet of things and etc. That is why it will be harder to find good candidates.
I think that language of the future will be developed in the future :D (and I think that language is not very important, having good engineers does really matter).
1 Like
I'd recommend to stick to established standards on other platforms (Kotlin for Android, C# for Windows, etc). Server side is more interesting choice.
Other than that swift is not recommended for low level code (like interrupt handlers or schedulers) or realtime code (like low level audio).
3 Likes
Other than that swift is not recommended for low level code (like interrupt handlers or schedulers) or realtime code (like low level audio).
I digress. Interrupt handlers and schedulers can even be done in Python, as I've seen extensively in Jupyter. Networking, I/O, and process spawning is language-agnostic. For low-level audio, you often depend on system libraries or third-library libraries for optimized kernels, like FFTs and matrix factorizations. If not, Swift provides every single optimization mechanism available in C/C++, except the goto keyword. Don't be discouraged by the fact that very few people are doing this. If you need an example to prove Swift can be used for these things, PassiveLogic.
If you know a language well, you can bypass any barriers to using it on a particular platform or for a particular purpose. People have used Kotlin on iOS by compiling it into stuff that isn't Java bytecode, and used Swift on embedded devices where the Swift stdlib is larger than system RAM (using clever tricks). The most important task is learning to use Swift for everything from high-level scripting to low-level optimization. If When you encounter barriers to deployment, there's an entire community waiting to help you.
5 Likes
The main reason why I'm thinking of using Swift for all of my coding infrastructures is that back in high school my computer science teacher was talking about how swift is the perfect language that steals good ideas from all the other languages. He was telling us about how swift is really good because it is easy to learn, easy to use, it's fast and it can be used for pretty much anything. Therefore it's the revolutionary language of the future.
1 Like
He couldn’t have phrased it more perfectly. But just as precaution, everything has its upsides and downsides. I don’t want to give a misleading impression that Swift is a panacea that solves all of your problems.
6 Likes
You can write it in asm. Or on a Turing machine simulator. Doesn't make it a wise choice.
So is SwiftUI internals... written in C++, I wonder why... 
With swift it's just too easy to shoot yourself in the foot and hit a lock (which can take an unbound amount of time, hence audio glitch). retain/release or mutex lock, or many things in swift runtime, - it's a minefield in those regards. Unless you don't mind the glitches (say, an in-house experimental app), or extra carefully avoid pretty much all swift and limit yourself to a very limited portion of it (plus check the asm afterwards to be sure.. and check again in a new compiler version).
On the contrary, this is typically a very good indication of the road to avoid.. unless for some very curious types ("why exactly is that road blocked") and among those who have too much free time on their hands.
A good language for the task at hand means ... you don't need any clever tricks to do.
For questions about issues specific to Kotlin apps deployed to iOS that would be, say, 1/100 of the overall iOS / Kotlin community who can help.. for Swift apps deployed to Android - divide that by another factor of 10. I'm petty sure I am overly optimistic with the number.
1 Like
That certainly hasn't been my experience with Swift. I don't like where this thread is going.
Let's do some fact-checking before making a conclusion based on numbers. Do you have a source showing the number of iOS apps made using Kotlin vs. the number of Android apps made using Swift?
Programming language is the least important factor in software development 
What you need is people with good communication skills and high level of emotional intelligence, with basic knowledge of computer science and math, and people with a strong desire to learn new things.
3 Likes
That was a fermi estimate ballpark figure. google agrees:
"Android app in Swift" - 10 results
"iOS app in Kotlin" - 10 results
"Android app in Kotlin" - About 150,000 results
"iOS app in Swift" - About 103,000 results
1 Like
I know but since Swift seems to be capable for anything and easy to learn and use, I would want to try to use the same language for everything if that language is legendary.
My goal is to create a software infrastructure for my company that will remain up-to-date for as long as possible. I believe that in the long run, it's more important that the language is easy to learn and use. After all, ease of usage is what makes it easy to edit and maintain it right?
Those numbers show relatively equal numbers of Kotlin + iOS vs. Swift + Android. In the earlier comment, you said that Swift + Android had 1/10 as may users as Kotlin + iOS.
I don't mean to be nit-picky about specifics of an argument. But multiple assumptions were made about how Swift is "less popular" for specific use cases (including a unique form of mobile development), or that Swift will be more problematic to use.
This is also an example of an assumption being made, then used as the premise of an argument. While it is possible that Apple used C++ instead of Swift because it's more ergonomic, you didn't give a source to back that up. Then with "I wonder why... ", you implied that we all "know why Apple chose C++". Is this a correct interpretation of your statement?
That involves hiring people, no? Would be really challenging hiring a Swift developer for Windows / Android project (unless you are top 20 company). Or hiring a Windows/Android person who is passionate about swift. Perhaps not impossible but reduces a hiring pool by a factor of 100 (another ballpark figure - my estimate).
1 Like
@realkevinthegreat's argument is that Swift is easy to learn and use. If a Windows/Android developer is experienced enough to work professionally, couldn't they learn how to program in Swift? Then you don't need to pick from the small pool of developers who already have experience with the language.
I really don't know why. If I had to guess - that would be "for performance reasons".
They could, they just won't. If you ever hired for your team you would know that the post "Looking for an experienced developer willing to learn and write in Swift for Windows/Android" would attract significantly fewer relevant CVs (1/100 - would be my optimistic estimate) than a more traditional "Senior C# Developer for Windows" / "Senior Kotlin Developer for Android". Unless you are one of the top companies, that divide by 100 may well give you zilch or few CVs to choose from. Because of this then you hire some junior developer, teach them, and in a year's time they jump the ship for a more traditional project. Or three years from now the "peculiar choice of language done by the old decision maker" is corrected anyway "to match industry standard" or for another reason. YMMV.
That is an appeal to authority, a logical fallacy. I have never owned a company or employed other people, but I don't think someone needs that experience to make a valid conclusion here. PassiveLogic has grown rapidly to around ~100 employees, with many using Swift without prior experience with the language. Looking at the careers page, a variety of jobs do not require prior experience with Swift. For example, AI Graphical Application Developer only mentions Swift once:
Yet the AI graphical application will likely interface with Quantum Solver, a gigantic Swift code base. The employee could be brand new to Swift, but they can type import Quantum into a file and make some basic code. The most important skills are general development skills, like "3+ years experience in software development" and "experience with OO and MVC design patterns", which are language-agnostic. While this is one job example, it disproves the assumption that:
I understand that it would be somewhat difficult to hire people for Swift development. However, for now I plan to do all of this mostly by myself. Maybe in the future I will worry about hiring people to maintain my Swift code.
1 Like
this is unnecessarily negative towards swift.
no single language is the best language for doing everything, and you shouldn’t try to look for one language that “does everything”. different languages are different tools and different tools are for different things.
for example, python is a great tool for doing things that have to interact with files and operating systems. you can write the same code to do the same thing in swift, but it’s going to be way easier to write it in python.
on the other end of the stack, CUDA/C++ is a great tool for doing things that have to run on a GPU. you could write the same code to do the same thing in swift, but it’s going to be way easier to write it in CUDA.
swift is a systems programming language. it mainly competes with (in order of popularity):
- C++
- C
- go
- rust
it would not be a good idea to use swift as a front end language unless you are doing something that really requires close-to-the-metal performance, like a browser game, in which case you could use something like SwiftWasm. in most cases, you’re better off using a common front end language, like typescript.
among the languages that swift competes with, i think that swift is a better option than many of the alternatives. although nobody here likes to admit it, swift is a C-based language, and it can interop with just about anything speaks C. since swift compiles to machine code, it can also call assembly instructions, which the swift-png library uses to power hardware accelerated PNG decoding in pure swift.
unlike rust, swift has a large intrinsic user base, since Apple protects and promotes it within its (largely closed) ecosystem.
it’s hard to hire swift developers, and it’s very hard to hire experienced swift developers. this is a reason to learn swift, because swift is a valuable skill, which is in very high demand right now.
this is likely why swift developers are among the most highly paid specialists among major languages, and why it was one of the fastest-appreciating languages by wage growth from 2021–22.
unfortunately many of the most experienced members of our community have an excessive amount of familiarity with the cutting edge of the language, where compilers and apps break, and have opted to take an intellectually honest approach to the shortcomings of the language, which all programming languages have.
this is good for the long term health of the language, but counterproductive (and misleading) to tell beginners just getting started with systems and server-side programming. maybe this is why new developers are 35% less likely to choose swift, but 72% more likely to choose C++, when compared to professional developers.
4 Likes
Then perhaps we should be discussing the pros and cons of you personally using Swift.
Swift's main benefit is being easy to understand and debug. If anything, it should excel in areas prone to bugs, which includes audio processes according to @tera's statement. Someone made a really cool audio framework in Swift and I had some discussions with him. Regarding mutex locks, I can't remember the last time I used one. The paradigm that works best for me is a DispatchSemaphore, which you can either signal or wait on.
Please elaborate, because this is the first I'm hearing about that (despite ~3000 hours of working with Swift and Apple platforms).
It depends what your company is about. I think the important thing in a new team with a greenfield project is to set some guidelines for your growing team. You can almost use any language but what you don’t want is too many languages in production at the same time unless you have teams focused on each ecosystem. Pick one or two main languages and don’t look back until you have a product.