5 ms·

In the long run, Swift, IMO. It has all the advantages of Go but with a more expressive language, much better C interop and a platform that will create a commu

In the long run, Swift, IMO. It has all the advantages of Go but with a more expressive language, much better C interop and a platform that will create a community around it very quickly, the other day I saw somewhere that there are already more Swift books and courses than Go. Swift will also let you do everything Rust can, very low level stuff.

nardi 10y ago
> 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.
- 31reasons 10y ago
  Swift uses LLVM as backend, so as far as I understand it can generate standalone binaries. No ?
  - kibwen 10y ago
    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.
  - grayrest 10y ago
    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 https://www.rust-lang.org/faq.html#does-rust-have-a-runtime (also mentions what's in the C runtime)
    - autoreleasepool 10y ago
      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.
      - kibwen 10y ago
        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).)
        joewillsher 10y ago
        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.
        chc 10y ago
        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?
        Someone 10y ago
        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.
- pjmlp 10y ago
  > Swift is a successor to both the C and Objective-C languages. Source: https://developer.apple.com/swift/ https://developer.apple.com/swift/
  - nardi 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - pjmlp 10y ago
      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.
      - the_why_of_y 10y ago
        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 http://www.iso-9899.info/n1570.html#4.p6
        pjmlp 10y ago
        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.
conradev 10y ago
Some key differences with Rust: - Swift code can't be called from C code yet - Swift has a runtime, Rust does not Swift can't do everything Rust can, but I also don't expect it to be able to.
bsaul 10y ago
i think that as long as swift doesn't have a proper official concurrency model, we can't really know how good it will be as a go competitor on the server side.
- DrJokepu 10y ago
  Isn't that what libdispatch is though?
  - chc 10y ago
    Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.
    - WoodenChair 10y ago
      Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.
      - ghthor 10y ago
        Don't be a dick. Have a conversation. Be kind.
      - chc 10y ago
        I did. The top result for "libdispatch linux" is a third-party library, and the second one is a project from Apple with very little activity (looked like a couple dozen LOC changed since the beginning of April) that sounds very far from "winding down" and looked to be more in the mode of "hey, it's open source, so you could theoretically run it on Linux if you wanted" that libdispatch has been in for over half a decade now — so it seemed like a fair question.

nardi 10y ago

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

31reasons 10y ago
Swift uses LLVM as backend, so as far as I understand it can generate standalone binaries. No ?
- kibwen 10y ago
  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.
- grayrest 10y ago
  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 https://www.rust-lang.org/faq.html#does-rust-have-a-runtime (also mentions what's in the C runtime)
  - autoreleasepool 10y ago
    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.
    - kibwen 10y ago
      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).)
      - joewillsher 10y ago
        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.
        chc 10y ago
        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?
        Someone 10y ago
        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.
pjmlp 10y ago
> Swift is a successor to both the C and Objective-C languages. Source: https://developer.apple.com/swift/ https://developer.apple.com/swift/
- nardi 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - pjmlp 10y ago
    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.
    - the_why_of_y 10y ago
      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 http://www.iso-9899.info/n1570.html#4.p6
      - pjmlp 10y ago
        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.

conradev 10y ago

Some key differences with Rust: - Swift code can't be called from C code yet - Swift has a runtime, Rust does not Swift can't do everything Rust can, but I also don't expect it to be able to.

bsaul 10y ago

i think that as long as swift doesn't have a proper official concurrency model, we can't really know how good it will be as a go competitor on the server side.

DrJokepu 10y ago
Isn't that what libdispatch is though?
- chc 10y ago
  Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.
  - WoodenChair 10y ago
    Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.
    - ghthor 10y ago
      Don't be a dick. Have a conversation. Be kind.
    - chc 10y ago
      I did. The top result for "libdispatch linux" is a third-party library, and the second one is a project from Apple with very little activity (looked like a couple dozen LOC changed since the beginning of April) that sounds very far from "winding down" and looked to be more in the mode of "hey, it's open source, so you could theoretically run it on Linux if you wanted" that libdispatch has been in for over half a decade now — so it seemed like a fair question.