5 ms·

I see some mentions of Server API's on their website. With these libraries in place, how comparable is swift to golang?

hasenj 9y ago
I think it's nicer to program in swift than go. It's already possible to do so to, by the way. http://perfect.org/ http://perfect.org/ What I think go has over swift is the complete independence from platform. You can write go code on osx and compile it to a linux binary and it Just Works! Swift on Linux is not perfect yet, though it can be made to work with some effort.
- alexashka 9y ago
  Swift has no quality high-level concurrency primitives - until those arrive, Swift is a complete non-starter as a server language. Concurrency is at the level of proposals currently, so it'll be another couple of years until they come up with something, and another couple until good server libraries/frameworks figure out how to use them properly. It's a shame really - I imagine this could've been moving along at a faster rate had Chris Lattner stayed on with Apple and recruited some extra help. He has written a really nice proposal for concurrency, that'll definitely influence Swift going forward. [0] [0] https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
  - efficax 9y ago
    I agree, for the most part, but then again, C also has no high-level concurrency primitives, and basically every server ever is written in C. You can use Grand Central Dispatch, and it works. It's not as wonderful as go routines and channels, but hey, it works.
    - alexashka 9y ago
      I hear you. C has performance because it doesn't have to do any sanity checks and because 20 years of serious effort has gone towards optimizing everything possible. The very motivation behind creating Swift, has been to have performance, and none of the undefined behaviour (cause of innumerable security breaches and unintentional complexity in compiler design and everyday programming) [0] To me, grand-central-dispatch feels one small step above semaphores/locks/monitors. There has been a lot of research in distributed computing and concurrency - I'd like to see libraries, language constructs and runtimes based on research fresher than before I was born :) [0] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
  - valuearb 9y ago
    Isn’t one of the most popular server languages JavaScript?
    - akmittal 9y ago
      No, JavaScript is not even close. It has gotten popular in past few years. Most server apps are written in Java, C#, Ruby and python.
      - adamrezich 9y ago
        PHP?
        nindalf 9y ago
        Hush, we don't speak of that.
  - hasenj 9y ago
    People have been using python for server side applications for years, and not only it had no concurrency primitives (until very recently), but it has a GIL that makes multi-threaded programs impossible. According to the documentation at perfect.org, it supports asynchronous request handling. I've tested it locally a while ago and IIRC it could utilize multi-cores just fine.
    - alexashka 9y ago
      Python and Ruby got adoption because they provided frameworks that made writing websites easy - Django and Rails respectively. Node became popular because now front-end devs could write their own backends. Go became popular because of Google and it's concurrency primitives (as far as I know) Swift is going to become popular because of Apple and... fill in the blank. My take is that it'll take good performance, and easy to understand concurrency primitives that make writing libraries and using them a joy - that's the only way. That'll be the differentiating factor that'll entice people to pay attention - otherwise as you have pointed out, there are plenty of alternatives.
      - willyt 9y ago
        There was a post about energy use recently. C, C++, Rust and Swift were often sharing the top 4 slots for various efficiency metrics. I would guess that energy efficiency is also a good metric for execution speed as well. Concurrency support is planned for swift, maybe efficiency, friendly syntax and concurrency support will be a winning combo?
      - valuearb 9y ago
        >Python and Ruby got adoption because they provided frameworks that made writing websites easy - Django and Rails respectively. Node became popular because now front-end devs could write their own backends. So you are saying concurrency primitives aren't required for a successful server language?
      - hasenj 9y ago
        Swift is at least an order of magnitude faster than python. It provides static typing. It compiles to native binaries. It's still fun to program in. There are already frameworks that allow programming web servers in Swift. It's more expressive than Go. It's a matter of time for it to get traction. The only thing python/ruby have going for them at the moment is momentum. Remember in 2005, Python was a fringe language on the web. Most web programming was done in php.
  - vesak 9y ago
    >Swift has no quality high-level concurrency primitives - until those arrive, Swift is a complete non-starter as a server language. That's just false. Server-side projects that require concurrency are a tiny minority.
    - LASR 9y ago
      Not disagreeing with you. I just wanted to know why you think this way. Wouldn't you want easy concurrency when building a high-performance http/tcp server? Also with the parent, why do you think "swift has no quality high-level concurrency primitives"? GCD and blocks along with some promise library should make it easier then goroutines and channels no?
      - cakoose 9y ago
        I think "server-side projects" is maybe too broad a term. Yes, there are plenty of server-side software where concurrency pervades the codebase. But if you're making a web app, for example, it's common for all of the code you actually write (the "business logic") to be single-threaded. Things like the core request loop and the DB connection pool will need to handle concurrency, but a few people will have figured out how to get that stuff working and you can just use their libraries.
  - josephg 9y ago
    Just to add to this, probably the biggest, most important reason to have language-level concurrency primitives is the 3rd party package ecosystem. In Go, Erlang and Nodejs packages don't need to make any decisions about what kind of concurrency to use. The postgres driver in go will expose a blocking API, and the postgres driver in node will expose a continuation-passing-style API, or use promises. Everyone who uses those languages already knows how to consume those APIs. In these languages its very hard for an experienced developer to make concurrency mistakes - you can instead spend all your time thinking about the actual problem you're trying to solve. In C, Swift and Rust this isn't true (yet). Despite all three of these languages having lots of tools for concurrency, the lack of standardisation means you can't just grab any postgres library. You also have to look at how that library does threading and figure out how to correctly integrate it with the threading model you're using in your own code. (Does it depend on tokio? Does it use posix threads? GCD? Green threads? Async?). This turns the 3rd party package ecosystem in these languages into a fragmented minefield. As far as I know there are 4 main swift-based http server libraries[1] at the moment. Each one works slightly differently. Because they all roll their own concurrency tools, they're all mutually incompatible. Each one has implemented its own static file server, its own hsts header middleware, its own json parser, etc. I'm not sure about erlang but in node and go because the concurrency primitives are standard, they're all similar enough that you can migrate code between them or wrap a tool thats designed for one to work for another. (Of course rust has tokio, but tokio is being rewritten[2]. Rust also has mio and raw threads. In a few years we'll probably have strong standards for both swift and rust, but until then the ecosystems will be a mess compared to the bliss of node and go.) [1] https://medium.com/@rymcol/current-features-benefits-of-the-top-server-side-swift-frameworks-b15b4f2d7bc3 https://medium.com/@rymcol/current-features-benefits-of-the-... [2] https://tokio.rs/blog/tokio-reform/ https://tokio.rs/blog/tokio-reform/
  - bjt 9y ago
    Thank you for that link; it was a very worthwhile read. Two things stand out: 1. Lattner's ability to present complex topics in an approachable way is very impressive. 2. I'm really excited for Swift 8.0 (my best guess at the first version that will include all this).
- rudedogg 9y ago
  There's also https://vapor.codes/ https://vapor.codes/ and Kitura
mahyarm 9y ago
Don't do it, the compile & indexing times alone as your code scales up get pretty bad. The debugger also just crashes when your codebase gets big and becomes uselessly slow when it doesn't. Backends have far more code than a typical client app, so if your 'successful' you'll run into it quickly enough. Swift needs more maturity as a language before using swift in a backend is a good idea.

I think it's nicer to program in swift than go. It's already possible to do so to, by the way. http://perfect.org/ http://perfect.org/ What I think go has over swift is the complete independence from platform. You can write go code on osx and compile it to a linux binary and it Just Works! Swift on Linux is not perfect yet, though it can be made to work with some effort.

alexashka 9y ago
Swift has no quality high-level concurrency primitives - until those arrive, Swift is a complete non-starter as a server language. Concurrency is at the level of proposals currently, so it'll be another couple of years until they come up with something, and another couple until good server libraries/frameworks figure out how to use them properly. It's a shame really - I imagine this could've been moving along at a faster rate had Chris Lattner stayed on with Apple and recruited some extra help. He has written a really nice proposal for concurrency, that'll definitely influence Swift going forward. [0] [0] https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
- efficax 9y ago
  I agree, for the most part, but then again, C also has no high-level concurrency primitives, and basically every server ever is written in C. You can use Grand Central Dispatch, and it works. It's not as wonderful as go routines and channels, but hey, it works.
  - alexashka 9y ago
    I hear you. C has performance because it doesn't have to do any sanity checks and because 20 years of serious effort has gone towards optimizing everything possible. The very motivation behind creating Swift, has been to have performance, and none of the undefined behaviour (cause of innumerable security breaches and unintentional complexity in compiler design and everyday programming) [0] To me, grand-central-dispatch feels one small step above semaphores/locks/monitors. There has been a lot of research in distributed computing and concurrency - I'd like to see libraries, language constructs and runtimes based on research fresher than before I was born :) [0] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
- valuearb 9y ago
  Isn’t one of the most popular server languages JavaScript?
  - akmittal 9y ago
    No, JavaScript is not even close. It has gotten popular in past few years. Most server apps are written in Java, C#, Ruby and python.
    - adamrezich 9y ago
      PHP?
      - nindalf 9y ago
        Hush, we don't speak of that.
- hasenj 9y ago
  People have been using python for server side applications for years, and not only it had no concurrency primitives (until very recently), but it has a GIL that makes multi-threaded programs impossible. According to the documentation at perfect.org, it supports asynchronous request handling. I've tested it locally a while ago and IIRC it could utilize multi-cores just fine.
  - alexashka 9y ago
    Python and Ruby got adoption because they provided frameworks that made writing websites easy - Django and Rails respectively. Node became popular because now front-end devs could write their own backends. Go became popular because of Google and it's concurrency primitives (as far as I know) Swift is going to become popular because of Apple and... fill in the blank. My take is that it'll take good performance, and easy to understand concurrency primitives that make writing libraries and using them a joy - that's the only way. That'll be the differentiating factor that'll entice people to pay attention - otherwise as you have pointed out, there are plenty of alternatives.
    - willyt 9y ago
      There was a post about energy use recently. C, C++, Rust and Swift were often sharing the top 4 slots for various efficiency metrics. I would guess that energy efficiency is also a good metric for execution speed as well. Concurrency support is planned for swift, maybe efficiency, friendly syntax and concurrency support will be a winning combo?
    - valuearb 9y ago
      >Python and Ruby got adoption because they provided frameworks that made writing websites easy - Django and Rails respectively. Node became popular because now front-end devs could write their own backends. So you are saying concurrency primitives aren't required for a successful server language?
    - hasenj 9y ago
      Swift is at least an order of magnitude faster than python. It provides static typing. It compiles to native binaries. It's still fun to program in. There are already frameworks that allow programming web servers in Swift. It's more expressive than Go. It's a matter of time for it to get traction. The only thing python/ruby have going for them at the moment is momentum. Remember in 2005, Python was a fringe language on the web. Most web programming was done in php.
- vesak 9y ago
  >Swift has no quality high-level concurrency primitives - until those arrive, Swift is a complete non-starter as a server language. That's just false. Server-side projects that require concurrency are a tiny minority.
  - LASR 9y ago
    Not disagreeing with you. I just wanted to know why you think this way. Wouldn't you want easy concurrency when building a high-performance http/tcp server? Also with the parent, why do you think "swift has no quality high-level concurrency primitives"? GCD and blocks along with some promise library should make it easier then goroutines and channels no?
    - cakoose 9y ago
      I think "server-side projects" is maybe too broad a term. Yes, there are plenty of server-side software where concurrency pervades the codebase. But if you're making a web app, for example, it's common for all of the code you actually write (the "business logic") to be single-threaded. Things like the core request loop and the DB connection pool will need to handle concurrency, but a few people will have figured out how to get that stuff working and you can just use their libraries.
- josephg 9y ago
  Just to add to this, probably the biggest, most important reason to have language-level concurrency primitives is the 3rd party package ecosystem. In Go, Erlang and Nodejs packages don't need to make any decisions about what kind of concurrency to use. The postgres driver in go will expose a blocking API, and the postgres driver in node will expose a continuation-passing-style API, or use promises. Everyone who uses those languages already knows how to consume those APIs. In these languages its very hard for an experienced developer to make concurrency mistakes - you can instead spend all your time thinking about the actual problem you're trying to solve. In C, Swift and Rust this isn't true (yet). Despite all three of these languages having lots of tools for concurrency, the lack of standardisation means you can't just grab any postgres library. You also have to look at how that library does threading and figure out how to correctly integrate it with the threading model you're using in your own code. (Does it depend on tokio? Does it use posix threads? GCD? Green threads? Async?). This turns the 3rd party package ecosystem in these languages into a fragmented minefield. As far as I know there are 4 main swift-based http server libraries[1] at the moment. Each one works slightly differently. Because they all roll their own concurrency tools, they're all mutually incompatible. Each one has implemented its own static file server, its own hsts header middleware, its own json parser, etc. I'm not sure about erlang but in node and go because the concurrency primitives are standard, they're all similar enough that you can migrate code between them or wrap a tool thats designed for one to work for another. (Of course rust has tokio, but tokio is being rewritten[2]. Rust also has mio and raw threads. In a few years we'll probably have strong standards for both swift and rust, but until then the ecosystems will be a mess compared to the bliss of node and go.) [1] https://medium.com/@rymcol/current-features-benefits-of-the-top-server-side-swift-frameworks-b15b4f2d7bc3 https://medium.com/@rymcol/current-features-benefits-of-the-... [2] https://tokio.rs/blog/tokio-reform/ https://tokio.rs/blog/tokio-reform/
- bjt 9y ago
  Thank you for that link; it was a very worthwhile read. Two things stand out: 1. Lattner's ability to present complex topics in an approachable way is very impressive. 2. I'm really excited for Swift 8.0 (my best guess at the first version that will include all this).
rudedogg 9y ago
There's also https://vapor.codes/ https://vapor.codes/ and Kitura

mahyarm 9y ago

Don't do it, the compile & indexing times alone as your code scales up get pretty bad. The debugger also just crashes when your codebase gets big and becomes uselessly slow when it doesn't. Backends have far more code than a typical client app, so if your 'successful' you'll run into it quickly enough. Swift needs more maturity as a language before using swift in a backend is a good idea.