3 ms·
Sure, 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 highligh
by zoogeny 3y ago
Sure, 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.