5 ms·
A lot of the low level code is working code in ObjC. There is no reason to replace perfectly working code that is battle tested if the requirements don't chang
by keyle 3y ago
A lot of the low level code is working code in ObjC.
There is no reason to replace perfectly working code that is battle tested if the requirements don't change.
The fact that the new binaries on it are written in Swift is showing their 100% commitment to Swift, which is great to see. And why wouldn't you, Swift is a joy to work with, especially if you're from Apple :)
- zoogeny 3y agoSure, but "working code" written in C is declining. So some choices are being made. It fits in line with how I've seen Apple developers at conferences highlighting the memory safety aspects of Swift. They are maybe hoping to position it as a competitor to Rust on that front. I wonder how they feel Objective-C compares from a safety perspective compared to Swift. I wonder if that might influence decisions on what kind of stuff gets re-written in Swift. I hope we can see further graphs like this to track what happens. I don't feel MS ever committed to C# in this way but that is due to ignorance at the numbers. I would love to see all of that data for Windows and even macOS.
- tambourine_man 3y ago> Sure, but "working code" written in C is declining Perhaps it’s just not increasing much since the value is in percentage and overall code size has increased dramatically. I doubt they will rewrite Mach/XNU, for example, in the foreseeable future.
- Wowfunhappy 3y agoCan Swift even be used for kernel development?
- balder1991 3y agoI believe you’d need a subset of Swift, there’s a thread about this on the forum: https://forums.swift.org/t/introduce-embedded-development-using-swift/56573 https://forums.swift.org/t/introduce-embedded-development-us...
- glhaynes 3y agoAdditionally, until very recently, there was no (practical) way to reach the performance potential of manual memory management in pure Swift: all heap management was done via Automatic Reference Counting (ARC). A series of "ownership" features have been getting integrated into the most recent versions of the language that let you avoid that runtime cost while retaining memory safety (at the expense of more complex code — the vast majority of code should still use ARC). That makes Swift much more suitable for lots of "systems programming" than it was just a few months ago. https://www.swift.org/blog/swift-5.9-released/#ownership https://www.swift.org/blog/swift-5.9-released/#ownership
- balder1991 3y agoThanks, I had never read something about this.
- tambourine_man 3y agoIt was Lattner’s vision, a language that would scale from scripts to kernel. Oh yeah, and one that’s easy for a beginner to learn. I think that’s impossible, Swift should try to be a great language for building Mac/iOS apps and hopefully frameworks. But what do I know. I wouldn’t think writing a new industry grade C++ compiler in a modular architecture would be feasible. Just use GCC. And yet here we are with clang and LLVM.
- nxobject 3y agoI think he's trying again with Mojo – just from the top (Python) down.
- saagarjha 3y agoWith a somewhat different definition of “kernel” this time.
- pjmlp 3y agoGPGPU code has similar constraints to actual kernel code, so in a way it kind of overlaps.
- tambourine_man 3y agoHe’s the only reason we are paying attention to Mojo. I have more faith in Mojo being a fast Python than in Swift being an all encompassing multi-platform language.
- vbezhenar 3y agoIMO such a language must be designed from the kernel and up to scripts, not the other way around. And it must be nested, like C and C++.
- stephen_g 3y agoIn the recent talk about the new Swift to C++ bidirectional bridge [1] the presenter from Apple says that they intend to eventually use Swift for basically all their first-party code from embedded code on microcontrollers, to the kernel, libraries and apps. There will be language subsets for embedded and kernel development, not all features would be able to be used at the lower levels. 1. https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw
- vips7L 3y agoIt’s reference counting is far too slow for kernel code.
- MBCook 3y agoWorking code can hold unknown bugs, including those Swift could help prevent. There are reasons to rewrite it, though I’m sure it will take a long time and they’re prioritizing risk vs reward.
- brailsafe 3y agoPrioritizing expense and risk vs nebulous reward
- MBCook 3y agoIt’s not nebulous. There are kinds of bugs that Swift can provably catch that Objective-C can’t. There are bits of safety that Swift can ensure without needing to do additional boundary checks or something else, leading to faster/smaller code. Perhaps biggest of all Swift doesn’t need a runtime like Obj-C. Apple has done an amazing job tuning it, but a direct function call is always going to be faster than message passing.
- bobbylarrybobby 3y agoSwift doesn't need a runtime, but if it runs alongside Objective C code, doesn't it? On iOS wouldn't much of what Swift is doing be to calling down into Objective C? In other words, I think that unless you get rid of all of the Objective C in iOS, Swift will still be sitting on top of a runtime.
- astrange 3y agoSwift does need a runtime. The language design is kind of accepting of implementation complexity in a way that interpreted languages often are but compiled languages usually aren't, so there's a lot of implicit heap allocations.
- brailsafe 3y agoWhat is nebulous is the actual return on the investment of time and money, just the same as it would be in any rewrite of any code ever, when the same resources could be allocated differently. The possibility that some hypothetical bugs might be avoided isn't a compelling argument for spending dollars and time on doing the work, if it's measurably doing it's job now.
- gumby 3y ago> There is no reason to replace perfectly working code that is battle tested if the requirements don't change. Are you familiar with Apple's MO? Take a perfectly good, working app and replace it with a total rewrite with half the features.
- aalimov_ 3y agoGenuinely curious to know which apps you are referring to.
- gumby 3y agoOff the top of my head here are some notorious examples you can look up from the Jobs era: On the consumer side, iMovie was probably the worst, not even being able to read projects made in the prior version. Not just the interface but the whole paradigm was different, only supporting a few features of the original program. I gave up on it. iPhotos was another example: it had languished, but what came out had less functionality (no more external streams, for example) and simply threw info away (tags, face recognition, added metadata like location was all gone). Links to external tools were no longer available, though added later. This happened to Pages and Numbers (& Keynote?) as well but I don't know if they count as consumer or pro apps. Consumer I guess. On the Pro Side, replacing Final Cut Pro with Final Cut X (~2010 or 2011) pretty much drive video production off the Apple platform onto Windows. Like the iMovie case (I guess they didn't learn) it was a completely new interface without most of the features of the old version. I hear a lot of the functionality made it back in over the following decade, but you wonder why. I think the loss of the pro production side in video (and replacement by Adobe) led to the abandonment of Aperture too. Apple announced that the consumer product Apple Photos was supposed to be the replacement -- what a joke!
- flakes 3y agoI feel like this was a trend. Windows Movie Maker from XP was tremendously better than all of their replacements. I remember using that heavily when I was in middle-school, making stop motions and stupid videos with my friends.
- inopinatus 3y agoI really do enjoy working in Swift too, but the anemic cross-platform story is a colossal hurdle to selection as the primary development language in many commercial cases. It seems to me that Apple's strongly insular instincts serve them well for integrated product design, but for the Swift language, alas, they form a severe hindrance to wider adoption.
- cageface 3y agoThe vision of Swift as a truly cross platform, modern language Apple laid out in the initial announcement was genuinely exciting. Unfortunately it seems like they didn't really mean it.
- pjmlp 3y agoHardly any different from going with .NET (many stuff is still Framework only), or C++ with OS specific SDKs like MFC/WinUI/...
- varjag 3y agoIf cross-platform is your thing 'fraid Objective-C isn't a great sell either.
- mpweiher 3y agoAt least two open-source compilers, several runtimes, several Foundations. What more do you want?
- eviks 3y agoThe reason is those battle tests showed time and again that the code is vulnerable, so it's not working perfectly
- corbezzoli 3y ago> the new binaries on it are written in Swift It appears to be 50:50 with Obj-C for now. See how the Obj-C line in the "Evolution of the programming languages" chart is still growing steadily. I can see Swift taking the majority of new code for the next year though.
- pjmlp 3y agoMost of the new code written in Objective-C tends to be related to Metal, or new features being added to existing Objective-C frameworks like UIKit.