Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Lightning talk on ATP episode 205

Caution - Ahead be spoilers!!

  1. John, Casey and Marco
  2. Chris Lattner is on the show. Creator of LLVM and Swift. Now working at Tesla on automotive software (he later calls it autopilot, so ¯_(ツ)_/¯
  3. LLVM is a collection of compiler infrastructure projects.
  4. Ex: SourceKit leverages LLVM (rather than a monolith, access underlying services)
  5. LLVM first used in  OpenGL stuff to repack buffers for various GPUs. Code gen stuff. llvm bytecode files -> GPU machine code 😳
  6. bytecode vs bitcode - originally LLVM had bytecode(inspired from Java Bytecode), later in 2.0 used bitcode (bytestream vs bitstream)
  7. Bitcode is important because it’s kind of more CPU agnostic. So adding instructions (ARMv7s iPhone 5 chip with integer divide), compiler optimisations, don’t have to make multiple slices(ARMv7 ARMv7s etc).
  8. Bitcode isn’t panacea though. Can’t move 32 bit to 64 (because you might have #ifdefs in your C code)
  9. in ye olde days(even now), lipo would take your binary slices and put them together.
  10. Swift first commit in 2010
  12. Swift is supposed to scale not only in terms of levels(low to high), but also in terms of learning(progressive discoverability of complexity - ex inline assembly code.)
  13. Swift 3 is going to be source compatible
  14. Swift 4 will have perl style grammars
  15. Swift 5 will have go style concurrency
  16. ABI stability will be somewhere in the middle (source stability >>>>> ABI compatibility)

how an application should make system calls to the operating system and, if the ABI specifies direct system calls rather than procedure calls to system call stubs, the system call numbers

  1. Marco writes swift for Overcast

  2. Swift Server side group (bringing together people)

  3. PigeonHoling is a problem - Swift isn’t just for  platforms

  4. Scripting to system level lang. Make easy things easy, make hard things possible

  5. Rust memory ownership as an alternative to ARC

  6. Swift is the Rorschach test of languages - everyone sees their favorite language in it.

  7. Swift in the browser - asm.js Trojan horse.

  8. ARC is a great default of swift

  9. RxSwift - Chris has no opinions as such. Just happy that the language supports all of these variable models

  10. ARC vs GC (finally!)

    • GC is (ideally) a magic fairy in the background
    • Python = ARC + Cycle collector (no idea which implementation, probably CPython)
    • Perl is GC, btw
    • Tracing GC, not regular GC
    • Stutter problem - GC haters gonna hate
    • finalizers, similar to deinits running on wrong thread, object maybe revived- 🤔
    • ARC has overhead, have to think about cycles
    • But GC injects code to your app.
    • generational GCs nursery -> regular memory.
    • Safe point in loops(so GC doesn’t run indefinitely) -> your loops may come in
    • Memory ownership model more like a middle ground
    • ARC has nowhere the near the amount of research done on it as tracing GC (think how JS is fast only because Google and  💰)
    • also explicitly thinking about memory (weak parents might be a good idea).
    • Also, ARC lets swift be big on IoT and low memory domains where GCs can’t run
    • ARC lets you interface with C code, no need for JNI.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.