Hacker News Reader

Hacker News

Comment by nardi | Hacker News Reader

Parent Full thread

nardi

> Swift will also let you do everything Rust can, very low level stuff.

Not quite. Swift requires a runtime, so you probably won't see people writing OS kernels in Swift.

View on HN

> Swift is a successor to both the C and Objective-C languages.

Source: https://developer.apple.com/swift/

Objective-C requires a runtime, and the Darwin kernel is not implemented in Objective-C.

Also, Swift, unlike Objective-C, is not a superset of C.

Interesting that you decided to ignore the fact that Apple also mentions C, which is what the Darwin kernel is implemented on, isn't so?

Which also happens to have a runtime, crt0.o.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels.

http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios.

Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change.

If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

What I think you're missing is that using a runtime is impossible in an OS kernel, unless the runtime doesn't use any OS features. You at least need to bootstrap enough of an OS before you can use the runtime. It's not the same thing as kexts or IOKit modules.

It is so impossible that history of computing is full of such examples, but the C community likes to re-write history so thay younger generations don't feel the need to dive into ACM papers about how the world was outside AT&T walls.

Sincerely: I would love to learn about one or more of these. Do you have any links to papers?

Could be, I wouldn't rule it out, but if so I've got serious doubts that it would be the full Swift language - the Objective-C style "dynamic" dispatch seems rather inappropriate for kernel space.

I agree that dynamic dispatch is not suitable for a kernel however if you compile Swift on a linux host then there is no ObjC runtime support anyway so its not an issue. However I would still see it as the full Swift language

It is possible but the Swift stdlib does rely on a minimal set of libc functions including malloc()/free() and the usual str* and mem* functions. Some of the other functionality can be removed eg the math and floating point but even implementing malloc() in Swift would be hard because any data structures that get used eg Arrays will themselves rely on malloc(), and even if you wrote it using UnsafeMutablePointer it would not be much different to a C implentation. Also the globalinit functions that get called at startup themselves rely on malloc() so it ends up being circular.

However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

> However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

I would rather use Assembly or compiler intrinsics instead, just like many C alternatives, some much older like NEWP, do.

Also many of the C library calls are impossible to implement in pure ANSI C without language extensions or Assembly, malloc() and free() being two of them.

Swift uses LLVM as backend, so as far as I understand it can generate standalone binaries. No ?

All languages add a bit of code to a binary to make the code you write runnable. Rust [1] and C add almost none, language like Swift and Go have to add their GC support code even if it's in the same binary, and jit+scripting languages generally come with an external runtime.

[1] https://www.rust-lang.org/faq.html#does-rust-have-a-runtime (also mentions what's in the C runtime)

Swift doesn't have a GC and you can use it to program like C with malloc and free via UnsafeMutablePointer<T>.

IIRC, Swift's runtime is like C++'s with v-table lookup for dispatch on functions that do not involve Objective-C objects.

Swift's GC is in the form of pervasive reference counting for reference types with no automatic cycle detection. Though as we're demonstrating, calling this GC is contentious, it would be better if people weren't too lazy to type out "pervasive reference counting for reference types with no automatic cycle detection". :P

(For the record, I believe Chris Lattner is on the record as saying "yes, Swift has a runtime, let's not bother arguing that point" though I can't find the link, but I agree that Swift's runtime is less invasive than most other languages (e.g. Go).)

Does saying 'ARC' not work for you? :)

And the Swift runtime is pretty minimal, mostly used for storing dynamic type information, dispatching protocol methods, generating (unspecialised) generic types, checking conformances etc. It's mostly used by the compiler to add the dynamic features of the language; for example, the compiler observes the lifetimes of variables and inserts retain/release instructions, which are lowered down to a swift_retain or swift_release calls on the runtime instance. These functions are implemented in the runtime and do the manipulation of reference counts and deallocation.

I can see how you'd say that's minimal compared to languages with really huge runtimes — but do you really think it's minimal compared to C or Rust?

It is simpler than a full GC, but I would not call that "pretty minimal". In particular, weak and unowned references and the guarantee that referencing them after the object they referred to was deallocated crashes your program make swift_release nontrivial.

Yes, the swift runtime does stuff like heap allocation & reference counting for classes, type introspection (including `as` casts), error handling, as well as generating instances of unspecialised generic types, and dispatching (dynamic) protocol methods (and other witnesses, like computed properties).

https://github.com/apple/swift/tree/master/stdlib/public/run...

Generating standalone binaries is orthogonal to the presence of a runtime. Go also generates standalone binaries (even more standalone than Rust and Swift) though it indisputably has a runtime.

Reply on news.ycombinator.com