7 ms·

I just wrote a swift api that I'm running on Ubuntu 16.04. I wasn't hesitant to use swift because first, it substantially outperforms node on many benchmarks [1

I just wrote a swift api that I'm running on Ubuntu 16.04. I wasn't hesitant to use swift because first, it substantially outperforms node on many benchmarks [1] [2] and second, the community of people who are excited about swift seem to have made up for its young age. You can find workable tutorials and help online for server side Swift. And there are multiple backend frameworks to choose from. Having type safety on the server is as great as it is on the client. It's also great to be able to write the server in the same language as the client. Makes for a VERY smooth dev process. Why wouldn't you use swift on the server? (my guess is fear of new tech -- which can be healthy many times but, IMHO, at least in the case of server side swift, it may be a bit irrational!) 1. https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=swift&lang2=node https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... 2. https://medium.com/@rymcol/linux-ubuntu-benchmarks-for-server-side-swift-vs-node-js-db52b9f8270b https://medium.com/@rymcol/linux-ubuntu-benchmarks-for-serve...

mscdex 9y ago
The problem with those benchmarks are two-fold: 1. Specifically for the first set of benchmarks linked to, they are really irrelevant because they don't represent typical workloads unless you're writing a MAAS (Mandlebrot As A Service). Node was designed for I/O efficiency, not fastest CPU-bound computations. That's exercising the JS engine (e.g. V8) more than anything node-specific. With node becoming more VM-neutral, it's entirely possible for other engines (e.g Chakracore or SpiderMonkey) to be better at other types of computation. 2. Especially in the second set of linked benchmarks, it seems the author of the article was hardly a node.js developer because they not only used an older node branch at the time they wrote the article, but they left out a lot of common optimizations (some of which were pointed out in the comments section). Even Express (which the author used) is known to not be very well optimized. With that in mind, benchmarks are not the only thing you should be looking at IMHO. For example (for me personally), using a single language for frontend and backend is a big deal because there is less cognitive overhead when switching between the two (previously I often found myself writing JS syntax in PHP scripts and vice versa and trying to remember the APIs for different languages/platforms is difficult). There are many other benefits as well, just watch some of Mikeal Rogers' talks to get a better idea.
- coldtea 9y ago
  >1. Specifically for the first set of benchmarks linked to, they are really irrelevant because they don't represent typical workloads unless you're writing a MAAS (Mandlebrot As A Service). Node was designed for I/O efficiency, not fastest CPU-bound computations. Since everything that is not async will need to invoke CPU-bound computations in Node (e.g. for loops, string manipulation, JSON parsing, and generally everything that's not just delegating work elsewhere with a callback), this I/O efficiency doesn't buy much except for very lightweight uses. Most services in the real world soon get closer to Mandlebrot As A Service than "pure I/O". Node still does OK-ish there because V8 is fast serially too (and of course everybody runs it on cluster mode or similar), but it's not like fast I/O by itself is enough. >With that in mind, benchmarks are not the only thing you should be looking at IMHO. For example (for me personally), using a single language for frontend and backend is a big deal because there is less cognitive overhead when switching between the two What about the reduced cognitive overhead of not having to deal with JS on the server though? Plus, aren't usually the backend and frontend teams different ?
  - mscdex 9y ago
    >Since everything that is not async will need to invoke CPU-bound computations in Node (e.g. for loops, string manipulation, JSON parsing, and generally everything that's not just delegating work elsewhere with a callback), this I/O efficiency doesn't buy much except for very lightweight uses. These are different levels of CPU-bound-ness. Comparing for-loops (which barely cost anything) to encoding video or computing PI for example is not comparing apples to apples. The body of a for-loop will typically greatly dwarf any "overhead" incurred by the for-loop construct itself. Obviously any non-I/O tasks like these are going to be CPU-bound. What I meant was Node is good at waiting for databases, web servers, file systems, etc. to respond to requests without blocking other work. >Most services in the real world soon get closer to Mandlebrot As A Service than "pure I/O". I disagree with this. I think most web apps spend most of their time waiting on the network, file systems, etc. to respond. >What about the reduced cognitive overhead of not having to deal with JS on the server though? I don't understand this question. JS is not a hard language to learn/pick up and there is a large number of developers out there who already know the language from working in the browser. However, my main point there was about using a single language. Yes, technically you can use Ruby, PHP, etc. in a browser (via JS), but nobody does that because it'd be very slow compared to just using JS from the get-go. >Plus, aren't usually the backend and frontend teams different ? It depends. I would say for most small businesses (and including the many "one man team" developers who do remote contract work for example) this is not the case. I cannot speak for large corporations, but there is definitely a larger possibility of having separate teams there. However just because you have separate backend and frontend teams doesn't mean having separate languages on each is any more beneficial (e.g. code sharing in some cases can be a win when using the same language). There's also the benefit of being able to "reuse" a JS developer on either end, depending on the work that's needed.
throwaway91111 9y ago
How does ARC hold up for long-lived servers? Are the leaks manageable?
- breatheoften 9y ago
  Why should ARC imply leaks?
  - throwaway91111 9y ago
    It doesn't.
- iainmerrick 9y ago
  I would expect it to be more reliable than a GC, as its performance and memory usage are more consistent.
  - rbehrends 9y ago
    That can cut both ways. 1. Swift's ARC uses atomic reference counting underneath, which is normally very expensive, and relies on compiler optimization to remove as many reference count operations as possible. This is normally pretty effective, but there are situations where it's not possible. 2. Reference counting allows for arbitrary long pauses as the result of cascading deletions (i.e. where object deletions trigger other object deletions). You can work around that (by deferring deletions), but then you don't have any guarantees about the timeliness of deletions anymore. As far as I know, this is still an open issue for Swift. 3. Without a compaction scheme, you risk memory fragmentation. While this is a rare occurrence in practice, there are workloads where it can happen. 4. Reference counting cannot reclaim cycles without a mechanism for detecting cycles; such a cycle detector (e.g. trial deletion) poses pretty much the same challenges as tracing GC. Obviously, tracing garbage collectors pose their own challenges; my point is merely that whether performance and memory usage are more consistent has to be judged on a case by case basis.
    - iainmerrick 9y ago

mscdex 9y ago

The problem with those benchmarks are two-fold: 1. Specifically for the first set of benchmarks linked to, they are really irrelevant because they don't represent typical workloads unless you're writing a MAAS (Mandlebrot As A Service). Node was designed for I/O efficiency, not fastest CPU-bound computations. That's exercising the JS engine (e.g. V8) more than anything node-specific. With node becoming more VM-neutral, it's entirely possible for other engines (e.g Chakracore or SpiderMonkey) to be better at other types of computation. 2. Especially in the second set of linked benchmarks, it seems the author of the article was hardly a node.js developer because they not only used an older node branch at the time they wrote the article, but they left out a lot of common optimizations (some of which were pointed out in the comments section). Even Express (which the author used) is known to not be very well optimized. With that in mind, benchmarks are not the only thing you should be looking at IMHO. For example (for me personally), using a single language for frontend and backend is a big deal because there is less cognitive overhead when switching between the two (previously I often found myself writing JS syntax in PHP scripts and vice versa and trying to remember the APIs for different languages/platforms is difficult). There are many other benefits as well, just watch some of Mikeal Rogers' talks to get a better idea.

coldtea 9y ago
>1. Specifically for the first set of benchmarks linked to, they are really irrelevant because they don't represent typical workloads unless you're writing a MAAS (Mandlebrot As A Service). Node was designed for I/O efficiency, not fastest CPU-bound computations. Since everything that is not async will need to invoke CPU-bound computations in Node (e.g. for loops, string manipulation, JSON parsing, and generally everything that's not just delegating work elsewhere with a callback), this I/O efficiency doesn't buy much except for very lightweight uses. Most services in the real world soon get closer to Mandlebrot As A Service than "pure I/O". Node still does OK-ish there because V8 is fast serially too (and of course everybody runs it on cluster mode or similar), but it's not like fast I/O by itself is enough. >With that in mind, benchmarks are not the only thing you should be looking at IMHO. For example (for me personally), using a single language for frontend and backend is a big deal because there is less cognitive overhead when switching between the two What about the reduced cognitive overhead of not having to deal with JS on the server though? Plus, aren't usually the backend and frontend teams different ?
- mscdex 9y ago
  >Since everything that is not async will need to invoke CPU-bound computations in Node (e.g. for loops, string manipulation, JSON parsing, and generally everything that's not just delegating work elsewhere with a callback), this I/O efficiency doesn't buy much except for very lightweight uses. These are different levels of CPU-bound-ness. Comparing for-loops (which barely cost anything) to encoding video or computing PI for example is not comparing apples to apples. The body of a for-loop will typically greatly dwarf any "overhead" incurred by the for-loop construct itself. Obviously any non-I/O tasks like these are going to be CPU-bound. What I meant was Node is good at waiting for databases, web servers, file systems, etc. to respond to requests without blocking other work. >Most services in the real world soon get closer to Mandlebrot As A Service than "pure I/O". I disagree with this. I think most web apps spend most of their time waiting on the network, file systems, etc. to respond. >What about the reduced cognitive overhead of not having to deal with JS on the server though? I don't understand this question. JS is not a hard language to learn/pick up and there is a large number of developers out there who already know the language from working in the browser. However, my main point there was about using a single language. Yes, technically you can use Ruby, PHP, etc. in a browser (via JS), but nobody does that because it'd be very slow compared to just using JS from the get-go. >Plus, aren't usually the backend and frontend teams different ? It depends. I would say for most small businesses (and including the many "one man team" developers who do remote contract work for example) this is not the case. I cannot speak for large corporations, but there is definitely a larger possibility of having separate teams there. However just because you have separate backend and frontend teams doesn't mean having separate languages on each is any more beneficial (e.g. code sharing in some cases can be a win when using the same language). There's also the benefit of being able to "reuse" a JS developer on either end, depending on the work that's needed.

throwaway91111 9y ago

How does ARC hold up for long-lived servers? Are the leaks manageable?

breatheoften 9y ago
Why should ARC imply leaks?
- throwaway91111 9y ago
  It doesn't.
iainmerrick 9y ago
I would expect it to be more reliable than a GC, as its performance and memory usage are more consistent.
- rbehrends 9y ago
  That can cut both ways. 1. Swift's ARC uses atomic reference counting underneath, which is normally very expensive, and relies on compiler optimization to remove as many reference count operations as possible. This is normally pretty effective, but there are situations where it's not possible. 2. Reference counting allows for arbitrary long pauses as the result of cascading deletions (i.e. where object deletions trigger other object deletions). You can work around that (by deferring deletions), but then you don't have any guarantees about the timeliness of deletions anymore. As far as I know, this is still an open issue for Swift. 3. Without a compaction scheme, you risk memory fragmentation. While this is a rare occurrence in practice, there are workloads where it can happen. 4. Reference counting cannot reclaim cycles without a mechanism for detecting cycles; such a cycle detector (e.g. trial deletion) poses pretty much the same challenges as tracing GC. Obviously, tracing garbage collectors pose their own challenges; my point is merely that whether performance and memory usage are more consistent has to be judged on a case by case basis.
  - iainmerrick 9y ago