5 ms·

Swift is statically typed, so it doesn't really compete with JS or Clojure. The company already has a C# implementation for sale. Also, Swift was designed to c

by djur 12y ago

Swift is statically typed, so it doesn't really compete with JS or Clojure. The company already has a C# implementation for sale. Also, Swift was designed to compile to native code, unlike any of the other three languages.

pjmlp 12y ago
.NET has NGEN since 1.0.
- marcosscriven 12y ago
  You can surprisingly effectively cross-compile C and C++ to Javascript now, with Emscripten.
  - pjmlp 12y ago
    The point is to AOT compile to native code.
    - marcosscriven 12y ago
      In fact that's exactly what it does: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...
      - pjmlp 12y ago
        I wasn't aware there was a CPU that could run that code natively without a JIT translation layer.
        marcosscriven 12y ago
        There isn't, perhaps you're getting confused again.
      - vidarh 12y ago
        When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application. In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime. They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.
        marcosscriven 12y ago
        The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.
        pjmlp 12y ago
        But it isn't AOT in CS speak.
        marcosscriven 12y ago
        I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand. Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.
        pjmlp 12y ago
        Well, I majored in compiler design. Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process. Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.
- rikkus 12y ago
  And .NET code _does_ compile to native code even without NGEN - it just does it 'Just In Time'. It's pretty close to native code just before that step, so the actual native compilation is very fast.
- djur 12y ago
  Sorry, I was imprecise. Swift was designed for the iOS platform as a replacement for Apple's dialect of Objective C. This is an unmanaged environment. There's no VM or garbage collection, although both languages support automatic reference counting. C# was designed for the CLR and has a large standard library that relies on garbage collection. It also has features permitting calls into unmanaged code, but the language was still designed for a VM.
  - pjmlp 12y ago
    Except there isn't any VM when the code is AOT compiled to native code with NGEN, MDIL in Windows Phone 8, .NET Native, or in iOS. The presence of garbage collection has nothing to do with being native or not. Besides a language runtime and VM aren't the same thing. Actually Swift makes use of Objective-C runtime to achieve interoperability with Objective-C libraries. Oberon, Oberon-2, Modula-3, Component Pascal, D, Spec#, Dafny are all examples of languages that compile to native code, were used to write operating systems and use garbage collection.
MarkSweep 12y ago
Mono supports ahead-of-time compiling to native code. I'm pretty that's used on iPhone.
brudgers 12y ago
I understand that Apple built Swift to compile to native code, but I thought the allure of this product was running on the JVM and .NET runtimes. I guess I should clarify that I get why using Swift for OSX and iOS might make sense. The question is about using it for other platforms.
dragonwriter 12y ago
> Swift is statically typed, so it doesn't really compete with JS or Clojure. This seems to imply that developers make a static vs. dynamic choice separately prior to and separate from evaluating other aspects of languages to choose between them. While some developers may do that all the time, and some may do that some of the time, I don't think its true as a generalization. Certainly Go is statically-typed, and often portrayed as competing fairly directly with Ruby/Python, which are not.

by djur 12y ago

pjmlp 12y ago

.NET has NGEN since 1.0.

marcosscriven 12y ago
You can surprisingly effectively cross-compile C and C++ to Javascript now, with Emscripten.
- pjmlp 12y ago
  The point is to AOT compile to native code.
  - marcosscriven 12y ago
    In fact that's exactly what it does: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...
    - pjmlp 12y ago
      I wasn't aware there was a CPU that could run that code natively without a JIT translation layer.
      - marcosscriven 12y ago
        There isn't, perhaps you're getting confused again.
    - vidarh 12y ago
      When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application. In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime. They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.
      - marcosscriven 12y ago
        The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.
        pjmlp 12y ago
        But it isn't AOT in CS speak.
        marcosscriven 12y ago
        I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand. Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.
        pjmlp 12y ago
        Well, I majored in compiler design. Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process. Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.
rikkus 12y ago
And .NET code _does_ compile to native code even without NGEN - it just does it 'Just In Time'. It's pretty close to native code just before that step, so the actual native compilation is very fast.
djur 12y ago
Sorry, I was imprecise. Swift was designed for the iOS platform as a replacement for Apple's dialect of Objective C. This is an unmanaged environment. There's no VM or garbage collection, although both languages support automatic reference counting. C# was designed for the CLR and has a large standard library that relies on garbage collection. It also has features permitting calls into unmanaged code, but the language was still designed for a VM.
- pjmlp 12y ago
  Except there isn't any VM when the code is AOT compiled to native code with NGEN, MDIL in Windows Phone 8, .NET Native, or in iOS. The presence of garbage collection has nothing to do with being native or not. Besides a language runtime and VM aren't the same thing. Actually Swift makes use of Objective-C runtime to achieve interoperability with Objective-C libraries. Oberon, Oberon-2, Modula-3, Component Pascal, D, Spec#, Dafny are all examples of languages that compile to native code, were used to write operating systems and use garbage collection.

MarkSweep 12y ago

Mono supports ahead-of-time compiling to native code. I'm pretty that's used on iPhone.

brudgers 12y ago

I understand that Apple built Swift to compile to native code, but I thought the allure of this product was running on the JVM and .NET runtimes. I guess I should clarify that I get why using Swift for OSX and iOS might make sense. The question is about using it for other platforms.

dragonwriter 12y ago

> Swift is statically typed, so it doesn't really compete with JS or Clojure. This seems to imply that developers make a static vs. dynamic choice separately prior to and separate from evaluating other aspects of languages to choose between them. While some developers may do that all the time, and some may do that some of the time, I don't think its true as a generalization. Certainly Go is statically-typed, and often portrayed as competing fairly directly with Ruby/Python, which are not.