'Swift Finally Matches Objective-C in One Major Way' (dice.com) 131
The editor of Dice's "Insights" blog argues that Apple's Swift language "has begun to eclipse Objective-C in a key way."
Apple was never shy about prioritizing Swift. As one developer on Twitter pointed out, once Swift dropped, Objective-C documentation and tutorials quickly started vanishing. Since then, the company has iterated on Swift and continued to shy away from Objective-C (except when necessary, such as supporting libraries and frameworks). Swift 5 made an important step forward with ABI stability, which means Swift code worked directly with a binary interface. Before ABI stability, the only safeguard was code was compiled on the same compiler, a fingers-crossed approach Apple really had no option for avoiding...
Swift's performance has also improved. For some time, when compared to Objective-C, Swift compiled slower. Because of ABI stability, performance has improved, and compile-time differences have vanished... Apps written in version 5 are also roughly 10-15 percent smaller than Objective-C apps. Bridging performance also improved.
A lot has gone into Swift 5 to make it more stable, and those improvements have resulted in performance parity with Objective-C... It's time to seriously consider the move to Swift.
In 2017 the creator of Swift (and a self-described "long-time reader/fan of Slashdot") began a five-month stint running Tesla's Autopilot team -- and stopped by to answer questions from Slashdot readers.
Swift's performance has also improved. For some time, when compared to Objective-C, Swift compiled slower. Because of ABI stability, performance has improved, and compile-time differences have vanished... Apps written in version 5 are also roughly 10-15 percent smaller than Objective-C apps. Bridging performance also improved.
A lot has gone into Swift 5 to make it more stable, and those improvements have resulted in performance parity with Objective-C... It's time to seriously consider the move to Swift.
In 2017 the creator of Swift (and a self-described "long-time reader/fan of Slashdot") began a five-month stint running Tesla's Autopilot team -- and stopped by to answer questions from Slashdot readers.
Objective-C for me... (Score:5, Insightful)
For my game engine's native layer, I pretty much had to use Objective-C when Swift first came out. Back then, Swift didn't really interop so easily with C++ code. It looks like that's improved somewhat over the last few years.
Still, I'm not planning to rewrite code that's already written and working well enough. Here's hoping that the Objective-C interfaces last a while. I'm already irritated that OpenGL is considered "deprecated", so now I have to decide if I want to ship a new game with OpenGL (already written and working) or rewrite a Metal interface for my graphics library.
Re: (Score:2, Insightful)
You did answer your own question. Once you've rewritten for the new interface you'll have new interface chops. It's that simple. Unless your game is deprecated also.
Re: (Score:1)
You should have used Rust.
Re: (Score:3)
You should have used Rust.
Does Metal work with Rust?
Re:Objective-C for me... (Score:4, Interesting)
No, nothing low level works with Rust because it violates the memory management models. The biggest questions on Rust forums are still "how do I make my code run without all these safeties"
Re: (Score:1)
You're missing the entire point, those are people trying to port without fixing their underlying issue.
Re: (Score:1)
Wasn't rust invented to solve all sorts of underlying issues?
Re: (Score:1)
DO you know what porting means? It means you wrote it in another language, tried to bring it into this one, don't understand that requires fundamental changes, don't know where they need to be, and you fail. That's what that means.
If you write it in rust you don't have that problem inherited from another architecture's translation to something you never tried to understand. #derp
Re:Objective-C for me... (Score:4, Informative)
And there are already low level bindings for Vulkan and Metal. Since I haven't used them I can't say what they're like to use.
Whether Rust is a good idea in a proprietary environment like iOS is another matter though. I expect using it is always going to be an uphill struggle compared to using Swift.
Re: (Score:2)
This is not true, Rust has FFI and unsafe keyword, those are made specifically for interoperability purposes and low-level code with manual memory management.
Re: (Score:1)
No, nothing low level works with Rust because it violates the memory management models. The biggest questions on Rust forums are still "how do I make my code run without all these safeties"
Rust works with metal. Look up gfx-rs, it's a wrapper library that supports OpenGL, DirectX, Metal and Vulkan all in one.
I have yet to find out what doesn't work with Rust, given that it's a native language that uses LLVM.
Re: (Score:2)
Re:Objective-C for me... (Score:4, Interesting)
"You should have used Rust."
That's not the entire use Rust meme.
"You should use Rust, then your program won't have any bugs in it."
Re: (Score:1)
"You should use Rust, then your program won't have any bugs in it because your program won’t do anything."
Fixed that for you.
Re: (Score:2, Funny)
So multi-threaded rust code has no racists conditions?
Thank you thank you. I’ll be here all week. Try the veal.
Re: (Score:2)
Re: (Score:3)
Re: (Score:1)
That's why many of us lose interest as we get older. Watching the wheel being invented and perfected was pretty cool, but watching it being reinvented over and over for no good reason, and having to re-factor code over and over to suit, is as frustrating as it is pointless.
So much energy and time wasted on things that never needed to be done in the first place.
Re: (Score:2)
Swift Is Garbage (Score:5, Interesting)
I was never an Objective-C expert and only wrote a bit of most stock UI glue code with it and the rest of app logic in C++.
Swift has turned me into diehard Objective-C fan.
Swift is:
* Ugly, really, really, ugly and clunky
* A silly vanity project that serves to do little other than for its creator to show off stuff he learned in his CompSci compiler/language course
* Has lead to absolutely no real world benefits to application development times or code quality
* Was clearly pushed out years to early for real world use thanks to a large number of Apple developers willing to declare anything and everything AMAZING!
Re: (Score:1)
Nobody uses rust.
Re: (Score:2)
I don't particularly care for your oxide bias, it seems to ignore the large quantity of oxides that are not iron-based.
Re: (Score:2)
non binary
So, you want to program Russian ternary computers, then?
Re:Apple should have adopted Rust (Score:5, Funny)
Nobody uses rust.
Trolls do, apparently. Just not for programming.
Ha Ha Ha Ha no (Score:5, Informative)
I see Swift as a very late response to C#
Why you would think Swift was a late response to a language that was a late response to Java, I find very much confusing because there was no need for Apple to respond to Java at that point.
Swift was a response to the rise in functional languages of all sorts, and the realization that long term the Apple platforms would have to have a language switch to maintain developer interest and availability.
As such Apple did a pretty amazing job with Swift in terms of launching, then letting the community define how it grew even as Apple added some broad strokes to help define useful direction (See: SwiftUI and Combine). Swift is at a point now where it's a really good language with a lot of nice features, and generally I enjoy programming in it more than most other languages...
Those who think Swift should have been Rust (or Apple should have used Rust), I just find strange - Rust isn't really used for any kind of large UI apps, the most complex kind of programming you can get. Swift is proving itself over time in a trial by fire while Rust just kind of sits there slowly pecking away at the boundaries of the much smaller box it is used within, even as the use of server side Swift expands as well...
Re: (Score:2)
Swift was a response to the rise in functional languages of all sorts, and the realization that long term the Apple platforms would have to have a language switch to maintain developer interest and availability.
Apple could require you to write in Brainfuck and I would remain a developer, and available (although at that point I would probably write my own pre-processor). It has nothing to do with the language, and everything to do with the platform.
Apple doesn't require a specific language... (Score:3)
It has nothing to do with the language, and everything to do with the platform.
Apple doesn't require anything - you could in theory write in any language.
But they have to present some language as the default choice - that was originally ObjectiveC, and is now Swift.
Apple needed Swift because over time, the default language of Objective-C would appeal to fewer and fewer developers as archaic - there is a large draw to Apple's platform but you also don't want to undermine that with a language that is hard for
Re: (Score:2)
Apple doesn't require anything - you could in theory write in any language.
Oh yeah? Where are the language bindings for Rust?
Re: (Score:3)
Oh yeah? Where are the language bindings for Rust?
I find it absolutely Hi-Larious how many technically ept Slashdot users don't even bother to use Google [bignerdranch.com] before issuing a hot-take.
Of course, that article is back from 2015, so I guess things have probably improved since then? Why don't you look into advancements since you need to know and kind of owe me one here.
Re: Apple doesn't require a specific language... (Score:2)
Re: (Score:2)
You can't call into the UI libraries, so Swift or Objective C is still required.
...
Why would that be the case? Rust can call any C library
Re: (Score:2)
Re: (Score:2)
No idea what you mean with "language bindings" ...
https://www.rust-lang.org/tool... [rust-lang.org]
At Your Service
Re: Apple doesn't require a specific language... (Score:2)
Re: (Score:2)
No idea what you mean with that.
You want to say there is no "Rust Header File" exposing the macOS APIs, and you can not make one yourself?
Re: Apple doesn't require a specific language... (Score:2)
Re: (Score:2)
* Ugly, really, really, ugly and clunky
Swift is a nice modern language inspired by many other new/nice modern languages.
What exactly do you find ugly and or clunky?
Re: (Score:2)
I asked about Swift, not about Metal or OpenGL.
Re: (Score:2)
The part of your game code that's interfacing with OpenGL should be a pretty small portion of your code. Work on abstracting that and supporting multiple APIs.
Once you've separated the rendering API from the game logic, it's not a ton of work to support a new rendeirng API. It'll help a ton if you ever try to develop on more platforms - say if you do any console work.
Re: (Score:2)
The part of your game code that's interfacing with OpenGL should be a pretty small portion of your code.
Yep, my engine is already multi-platform (Windows/Mac/Linux currently, maybe consoles in the future), and platform-specific code is nicely abstracted away behind clean virtual interfaces. 95% of the engine is platfom-independent modern C++. So adding a Metal renderer won't be overly difficult or anything. I just don't relish the thought of doing work that's functionally equivalent for no real gain.
I'm funding my own development on a solo project, and there are lots of priorities vying for my limited atte
The objective C documentation was withdrawn? (Score:4, Interesting)
If the objective C documentation was withdrawn, then it's well past time to consider dropping Apple support. Who knows what's next. That's a really shitty move.
Re: The objective C documentation was withdrawn? (Score:2)
No it was not (Score:5, Informative)
If the objective C documentation was withdrawn
Look at any page of the API documentation. [apple.com]
You'll see Swift example code, right? But look at the top of the page, at the left - a dropdown for language....
Change that to "Objective-C" and the sample code changes to Obj-C [apple.com].
Honestly what Objective-C tutorial or documentation was withdrawn by Apple? I don't remember anything going away, and I know a lot of people who would have been quite irked had it done so. Most third party sites have whatever Objective-C tutorials they had still up as well.
How do API docs solve problems (Score:2)
Spoken like someone who has never tried to fix an issue based on their documentation.
Not quite sure what you mean here?
Like everyone else, Stack Overflow is the first place I look for fixing problems.
Really API docs are not exactly the place to go to look for fixing API problems - generally the API docs for any framework or language are the ones that got you into the problem to begin with. :-)
Re: (Score:2)
Well, I haven't looked at their documentation for over a year...possibly several...because I didn't need it and wasn't using their system. So perhaps you are right, and the summary/article was wrong.
P.S.: One reason I didn't develop for Objective-C, the main reason, was that the documentation was so terrible. That's not all on Apple's head, though, as it predates their association with the language.
Pretty impressive if you ask me (Score:2)
She keeps releasing hit albums, has an awesome tour, and is one of the highest paid celebrities. How she finds the time to make her own language to dominate Objective-C is amazing.
Re: (Score:3)
well past time to consider dropping Apple support.
My wife's app business sales are 95% iOS and 5% Android. I don't think she'll be dropping Apple support anytime soon.
Android users download free apps, but rarely are willing to pay for apps.
Re: (Score:1)
Talk about a cherry picked unvalidated anecdote being spun into a truism about "everyone on an entire platform doing xyz" lol? Bill sometimes you out-bullshit even yourself. Enjoy spending several minutes cobbling together a bullshit shield..
Does your wife ever read the ridiculous bullshit you write here, lol? Does she even exist, one inherently wonders? You fucking liar lol.
How about you try to refute his claim and prove to us once and for all that Android users actually out spend Apple users on app purchase instead of shitting all over them man's wife like a toilet mouthed little imp? Otherwise people might start to think you are resorting to ad-hominem attacks because he is right and you are out of arguments.
Need a native-Swift Core Data replacement (Score:1)
Swift can [never] theoretically match Objective-C (Score:2)
the company has iterated on Swift and continued to shy away from Objective-C (except when necessary, such as supporting libraries and frameworks).
Objective-C cannot theoretically be beaten as its coding is closer to the metal as compared to Swift; for lack of better terminology.
Re: (Score:2)
When they're both produced by the same company, they can push whatever suits their agenda.
That is not the case (Score:5, Informative)
Objective-C cannot theoretically be beaten as its coding is closer to the metal
Thing is, it's really not.
In any modern compiler the language that can best be transformed into machine language wins - and over time that is more and more true of Swift, because it was designed to make many compiler optimizations easier for a compiler to realize it can apply.
Swift produces cleaner IL than C/Obj-C and so can be transformed into better/faster machine language.
Endgame, you could theoretically beat Swift with assembler but not with C / Objective-C / C++.
Re: (Score:3)
But even if it were slower, speed is rarely the critical deciding factor for languages anyway. More important is which language is likely to yield less bugs, produce more maintainable code and get you to market faster. For example C/Obj-C is cursed by NULL / nil problems whereas Swift uses
Re: (Score:2)
Endgame, you could theoretically beat Swift with assembler but not with C / Objective-C / C++.
When Brian Kernighan and Dennis Ritchie created C, it was more or less Assembler macros. Admittedly, the language has "grown", but I really don't see Swift as ever being closer to Assembler than C.
Keep thinking positively though. :)
Re: (Score:2)
Absolutely false. It started out as a compiled language derived from B.
You are not wrong, but it is more subtle than that, so my characterization of it being essentially Assembler macros is still accurate. The language was specifically designed to translate directly into Assembler and in fact, that is how the original compilers for it worked, they translated directly to Assembly language and then an assembler was used to turn it into machine language.
Re: (Score:2)
Objective-C cannot theoretically be beaten as its coding is closer to the metal as compared to Swift; for lack of better terminology.
The C part might arguable be "closer to the metal".
The "Objective" part most certainly is not.
Close to the metal is irrelevant anyway. Or do you actually have a #ifdef IOS and an #elsif MACOS in your Objective-C code? Shudddder!
Why not to learn Swift (Score:1, Flamebait)
No reason to learn Swift: look what they did to ObjC. That was going to be the future. Except it never was, and they write all their critical stuff in C++, just like everyone else. They will drop Swift too eventually. Young people like to learn new languages, but if you are smart you would learn C++. That is the past, present and future.
Re: (Score:3, Interesting)
I already know C++.
And learning it as a "first" or "early" language is imho a waste of time. Not enough demand. Much to deep/steep learning curve. Arcane syntax.
My suggestion always is: learn something that either is fun or is useful, preferable both.
Re:Why not to learn Swift (Score:4, Interesting)
No reason to learn Swift: look what they did to ObjC.
I had about 15 years using Objective-C (and I know people who had 30), and it has served me well. Still does.
But in two, three years time you will have a hard time finding an iOS or macOS developer job that doesn't require Swift full time. And in all seriousness, about at Swift 3.0 it was a better language than Objective C, more efficient to write (saving about 30% of code), more efficient to execute. Swift 5.0 is way ahead of Objective-C.
Re: Why not to learn Swift (Score:1)
In regards to Apples main use of ObjC it lasted about 7-8 years, during which time they cause massive churn, rewriting of documentation, tutorials, countless lost man hours of bug hunts, features not working, developers waiting on features. The same happened with swift. Quit fucking changing everything for the sake of changing it. Case studies can be made either way if it saves code, is safer, faster, etc. Itâ(TM)s all meaningless. Itâ(TM)s highly dependent on the case study.
Thatâ(TM)s g
How can ABI not be stable? (Score:2)
I surfed the web and found this quote from Swift 5 ABI Stability [medium.com]
ABI stability means locking down the ABI to the point that future compiler versions can produce binaries conforming to the stable ABI. It enables binary compatibility between applications and libraries compiled with different Swift versions.
But, I thought the ABI was defined by the processor -- not the language. I come (ok... you can start giggling) from IBM / AIX and the Power PC. On that platform, you could compile in any language and it all boiled down to the same ABI. Indeed, you could mix xlc with gcc with g++, etc.
So... can someone help me out here? Why doesn't the Intel chip have a stable ABI? Or am I utterly confused?
Re: (Score:1)
The ABI also handles stuff like how functions are internally named. This is important during link time. In any language that supports polymorphic function calls, the name the linker sees is different than the name the you wrote. For instance that two functions:
foo(int a)
foo(float b)
In thermal the compiler will change the name to indicate they difference.
fooi
foof
Things like this and other call conventions, argument order, call by reference/value, etc... all depend on the ABI.
Re: (Score:2)
Yes, you are utterly confused.
The processor defines the instruction set.
The ABI defines how executables are using it, e.g. in which order function call arguments are pushed on the stack, who is cleaning the stack, caller or callee? How are function/method names represented in binaries, so that linkers can link binaries from different compilers. If you have multiple registers that could serve as a stack pointer, which is used "in the ABI"?
Etc.
GOD DAMN "NS" function names (Score:1)
Go away!
Re: (Score:2)