Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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.


Can Swift even be used for kernel development?


In 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


It 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.


I think he's trying again with Mojo – just from the top (Python) down.


With a somewhat different definition of “kernel” this time.


GPGPU code has similar constraints to actual kernel code, so in a way it kind of overlaps.


He’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.


IMO 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++.


I 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-us...


Additionally, 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


Thanks, I had never read something about this.


It’s reference counting is far too slow for kernel code.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: