9 ms·

Swift, especially with its recent developments, is a hugely promising language for building servers. Type safety? Check, with great type inference. Like functio

by ruddct 11y ago

Swift, especially with its recent developments, is a hugely promising language for building servers. Type safety? Check, with great type inference. Like functional programming? Functions are first class citizens. Immutable data structures? Available and always encouraged. OO? Classes are there. Structs, kickass enums and interfaces? Fine by Swift. Predictable memory management? Check, ARC rocks. Plus lots of nice language features like guard, do/try, optionals, etc. Really the only thing that's missing as a language feature is some kind of concurrency support, though I'm hopeful future iterations will include this. In the mean time, it might be a bit of a blocker for serious server-side adoption.

fleitz 11y ago
Reflection sucks in swift which makes many web patterns tedious to implement.
- joslin01 11y ago
  Ya, I was just gonna post this. Scala has more powerful generics and an eco-system of, oh I don't know, every java library ever created. It's also got the Play framework and Akka. When it comes to rationally planned web development, Swift is very low on the totem pole and a bunch of cute language features aren't gonna change that.
  - falsedan 11y ago
    Swift's biggest advantage over Scala is its tight coupling with a commendable IDE. Perfect doesn't seem to address how debugging a server-side app will work with Xcode…
    - joslin01 11y ago
      I agree with you and that's a nice rebuttal. I use XCode daily since I code in Swift for an iOS project. Great tool. However, I really wouldn't trade so much away just to stay in the same IDE and I certainly wouldn't construct a plan to do so. All the people down-voting me are just Swift fanatics who probably haven't touched the language all that deep. Good language, love the replacement for Objective-C, and you could argue GCD makes Akka unnecessary (though I wouldn't go that far), but again not fit for web development in my humble opinion..
    - fleitz 11y ago
      XCode (for ObjC) is very commendable for no longer crashing every 5 minutes, other than that its pretty crappy compared to other IDEs created by multi-billion dollar companies (even some open source IDEs are better) When working in swift it's as if someone rewrote the thing in Java. As obnoxious as eclipse can be, it at least code completes in a reasonable time.
    - tychuz 11y ago
      I don't know, most people I know use XCode only for drag and drop quick UI stuff and for actual development they use AppCode (also supports Swift 2).
- bjz_ 11y ago
  Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many of the good points of statically typed languages - ie. type safety, ease of optimization, and performance.
  - joslin01 11y ago
    Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems." Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"
    - netheril96 11y ago
      > Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
      - joslin01 11y ago
        Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
        netheril96 11y ago
        I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
supster 11y ago
Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can still get really verbose.
- tcdent 11y ago
  Isn't that a problem with most typed languages? You're bringing in untyped data, so native types need to be spelled-out somewhere. There's a line somewhere between excessive verbosity and dumb trust (like the YAML snafu). I haven't seen great syntax yet, though.
  - supster 11y ago
    Agreed, it would be cool if we could specify untyped zones within a function e.g. @untyped func parse(json: AnyObject) -> String? { /* code here is not type checked, if returned value is not type String then value will become nil */ }
  - rjbwork 11y ago
    Newtonsoft.Json with dynamics is really good at it in the .NET world. I usually use actual typed objects, but the DLR has enabled some cool stuff concerning dynamic input type things.
- bribri 11y ago
  Argo is great and applicative functors are a great way of parsing in a type safe way
- Tloewald 11y ago
  I think the problem is JSON. Because JSON is tied so strongly to Javascript it tends to be very ugly in any other language. I think we need a simplified (and more concise) alternative to JSON that more closely matches the way languages that aren't Javascript work. E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)
Einherji 11y ago
Swift's concurrency story is pretty much handled by GCD. IMO a fantastic set of APIs that make it pretty easy to deal with worker threads and queueing tasks and such.
- madeofpalk 11y ago
  The interesting part about Swift being open sourced for linux is what API's will come with it. I would not be surprised if GCD doesn't come along.
  - icodestuff 11y ago
    libdispatch is Apache licensed.
    - madeofpalk 11y ago
      Ahh nice - I didn't know that. It'll still be interesting to see what happens to the rest of the libraries and API's that are common place in Swift development

by ruddct 11y ago

fleitz 11y ago

Reflection sucks in swift which makes many web patterns tedious to implement.

joslin01 11y ago
Ya, I was just gonna post this. Scala has more powerful generics and an eco-system of, oh I don't know, every java library ever created. It's also got the Play framework and Akka. When it comes to rationally planned web development, Swift is very low on the totem pole and a bunch of cute language features aren't gonna change that.
- falsedan 11y ago
  Swift's biggest advantage over Scala is its tight coupling with a commendable IDE. Perfect doesn't seem to address how debugging a server-side app will work with Xcode…
  - joslin01 11y ago
    I agree with you and that's a nice rebuttal. I use XCode daily since I code in Swift for an iOS project. Great tool. However, I really wouldn't trade so much away just to stay in the same IDE and I certainly wouldn't construct a plan to do so. All the people down-voting me are just Swift fanatics who probably haven't touched the language all that deep. Good language, love the replacement for Objective-C, and you could argue GCD makes Akka unnecessary (though I wouldn't go that far), but again not fit for web development in my humble opinion..
  - fleitz 11y ago
    XCode (for ObjC) is very commendable for no longer crashing every 5 minutes, other than that its pretty crappy compared to other IDEs created by multi-billion dollar companies (even some open source IDEs are better) When working in swift it's as if someone rewrote the thing in Java. As obnoxious as eclipse can be, it at least code completes in a reasonable time.
  - tychuz 11y ago
    I don't know, most people I know use XCode only for drag and drop quick UI stuff and for actual development they use AppCode (also supports Swift 2).
bjz_ 11y ago
Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many of the good points of statically typed languages - ie. type safety, ease of optimization, and performance.
- joslin01 11y ago
  Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems." Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"
  - netheril96 11y ago
    > Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
    - joslin01 11y ago
      Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
      - netheril96 11y ago
        I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.

supster 11y ago

Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can still get really verbose.

tcdent 11y ago
Isn't that a problem with most typed languages? You're bringing in untyped data, so native types need to be spelled-out somewhere. There's a line somewhere between excessive verbosity and dumb trust (like the YAML snafu). I haven't seen great syntax yet, though.
- supster 11y ago
  Agreed, it would be cool if we could specify untyped zones within a function e.g. @untyped func parse(json: AnyObject) -> String? { /* code here is not type checked, if returned value is not type String then value will become nil */ }
- rjbwork 11y ago
  Newtonsoft.Json with dynamics is really good at it in the .NET world. I usually use actual typed objects, but the DLR has enabled some cool stuff concerning dynamic input type things.
bribri 11y ago
Argo is great and applicative functors are a great way of parsing in a type safe way
Tloewald 11y ago
I think the problem is JSON. Because JSON is tied so strongly to Javascript it tends to be very ugly in any other language. I think we need a simplified (and more concise) alternative to JSON that more closely matches the way languages that aren't Javascript work. E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)

Einherji 11y ago

Swift's concurrency story is pretty much handled by GCD. IMO a fantastic set of APIs that make it pretty easy to deal with worker threads and queueing tasks and such.

madeofpalk 11y ago
The interesting part about Swift being open sourced for linux is what API's will come with it. I would not be surprised if GCD doesn't come along.
- icodestuff 11y ago
  libdispatch is Apache licensed.
  - madeofpalk 11y ago
    Ahh nice - I didn't know that. It'll still be interesting to see what happens to the rest of the libraries and API's that are common place in Swift development