Refactor the Why Swift on Server section and add page on concurrency. #496
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tachyonics
requested review from
0xTim,
alexandersandberg,
daveverwer,
dempseyatgithub,
parispittman,
kaishin,
mschinis,
shahmishal,
TimTr,
tomerd and
cthielen
as code owners
|
@swift-ci test |
0xTim
requested changes
Jan 26, 2024
| title: Why Swift on Server - Performance | ||
| --- | ||
|
|
||
| For the same reasons that make Swift is a fantastic choice for embedded and constrained environments such as watches and phones, Swift makes it possible to write simple, elegant server-side applications that are also highly efficient. |
There was a problem hiding this comment.
This paragraph needs reworking. There's a couple of grammar errors and the flow is a little off
|
|
||
| ## Small footprint | ||
| One of the main goals of a modern cloud platform is to maximize resource utilization by efficiently packing services into a single machine. | ||
| Cloud services built with Swift have a small memory footprint (measured in MB)--especially when compared to other popular server languages with automatic memory management. |
There was a problem hiding this comment.
Suggested change
| Cloud services built with Swift have a small memory footprint (measured in MB)--especially when compared to other popular server languages with automatic memory management. | |
| Cloud services built with Swift have a small memory footprint (measured in MB) - especially when compared to other popular server languages with automatic memory management. |
There was a problem hiding this comment.
Is it worth having something on safety here as well? It might end up being a separate section though
|
|
||
| ## Deterministic performance | ||
| Swift’s use of ARC (instead of tracing garbage collection) and its lack of JIT gives it an important edge in the cloud services space. | ||
| While tracing garbage collection technologies have vastly improved in the last few years, they still compete with the application for resources which triggers non-deterministic performance. |
There was a problem hiding this comment.
Suggested change
| While tracing garbage collection technologies have vastly improved in the last few years, they still compete with the application for resources which triggers non-deterministic performance. | |
| While tracing garbage collection technologies have vastly improved in the last few years, they still compete with the application for resources when triggered which results in non-deterministic performance. |
|
|
||
| Swift utilizes a built-in "async/await" style syntax that by default hides the complexity of concurrent programming. Similar to how Swift uses the explicit `try` keyword at function call sites to indicate that a function might throw, the `await` keyword is used to indicate that a function may suspend its processing to asynchronously wait on some future event or completion of another task. | ||
|
|
||
| ~~~ swift |
There was a problem hiding this comment.
Have you verified that ~~~ produce a code block? I thought it was only three backticks that worked
| 1. [`swift-log`](https://github.com/apple/swift-log)'s Metadata Providers: Swift's unified logging API, swift-log, provides the ability to retrieve log metadata from Task Locals and incorporate them into any logs emitted. In http request/response applications for example, this allows any logs - including those emitted from libraries with no knowledge of how the top-level application works - to include log metadata such as requestIds and other information about the incoming request. | ||
| 1. [swift-distributed-tracing](https://github.com/apple/swift-distributed-tracing): Swift's unified distributed tracing API allows specific tracing implementations to set tracing context from incoming requests and to then set it on any outgoing requests made in that task or any child task. | ||
|
|
||
| For most server-side use cases, the [ServiceContext](https://github.com/apple/swift-service-context) type, modeled after the concepts explained in [W3C Baggage](https://w3c.github.io/baggage/) and built on top of Task Locals, will be a convenient mechanism to transport task-specific information. This type easily allows for custom attributes to be stored and retrieved in a type-safe manner. This type is also the basis for `swift-distributed-tracing`'s trace identifier propagation. |
There was a problem hiding this comment.
modeled
Cries in British English 😆
|
|
||
| ## Thread Safety | ||
|
|
||
| Server-side applications are often highly concurrent, often with many hundreds or even thousands of requests executing in parallel within the same application. In these cases it is critical for correctness - and potentially even availability - that these requests can all run in parallel without unexpectedly affecting each other. Failing to make applications thread safe often results in unpredictable and difficult-to-debug race conditions. |
There was a problem hiding this comment.
Remove extra often
Suggested change
| Server-side applications are often highly concurrent, often with many hundreds or even thousands of requests executing in parallel within the same application. In these cases it is critical for correctness - and potentially even availability - that these requests can all run in parallel without unexpectedly affecting each other. Failing to make applications thread safe often results in unpredictable and difficult-to-debug race conditions. | |
| Server-side applications are often highly concurrent, with many hundreds or even thousands of requests executing in parallel within the same application. In these cases it is critical for correctness - and potentially even availability - that these requests can all run in parallel without unexpectedly affecting each other. Failing to make applications thread safe often results in unpredictable and difficult-to-debug race conditions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor the "Why Server on Swift?" section, adding content on concurrency features and provide room for further expansion.
Motivation:
The "Why Server on Swift?" has not been updated for a significant time and doesn't reflect a lot of features that could be considered advantages for using Swift for server-side applications.
Modifications:
Result:
The "Why Server on Swift?" section will be expanded into an index page and an additional section on concurrency features.