@Scott What you want sounds very similar to what's been done over at GitHub - reswifq/reswifq: Simple, reliable, background processing for Swift
Improved debugging and logging tools are definitely a great starting point. Both myself and my colleague have hit issues this past week that were caused by differences Swift Foundation and Darwin Foundation. Being able to track down those issues more easily would help reduce dev time spent trying to hunt them down.
Is WebAssembly support in the purview of the server group? It would be a huge advantage for Swift if projects can write code that runs both on the server and web frontend.
What I really miss from the lists is server side caching.
Is it like Google Web Tolkit for Java which cross-compiles Java code to JavaScript? Well, there are a lot of shortcomings of this approach.
I'd rather choose Google's approach. Closure Templates is a language neutral templating that can be rendered both on client and server side.
No, WebAssembly is the optimised binary instruction set that are compiled artefacts of systems languages. The idea is to increase performance of web applications by adopting WebAssembly instructions over JavaScript.
Rust has supported it for a while. Go has just added it. I use it with Rust regularly now rather than using JavaScript (or TypeScript in my case).
As WebAssembly is essentially a lower-level optimised systems language for the web, it makes sense for Swift to support compilation to the instruction set.
This is also more analogous to Closure Templates: Swift could support the DOM, allowing it to support performant coding of templating languages for server-side Swift that would compile down to client-side WebAssembly, enabling a naturally isomorphic engine for web developers in Swift.
This would perform much better than a JavaScript transpilation.
While I'd like to see that as well (a wasm toolchain, clang already supports it as a target), I really do not think that this belongs into this particular effort. Nothing to do with server, all to do with client ;-)
I suggest splitting webasm support into another thread
Sounds great but according to wasm penetration it may need more years to gain adoption across browsers. My primary concern of this approach is debuggability. Once a language gets transpiled to say, JavaScript the more complex the transpiled code the harder to find the bug in it and the original code.
Front-End experts prefer the dead simple approach: always write client-side code in JS. In larger projects involving more developers and 3rd party JS libs it could become a nightmare if some parts are written in like TypeScript or transpiled from Java and those parts needs to adopt some other libs.
But I welcome a templating solution like Closure Templates that is easy to adopt by web developers and can be rendered both on server side (full page render) and client side (partials).
Agreed. This is a subject in its own, and as @Helge_Hess1 pointed out, it's predominantly client-side, not server-side. The WASM compilation is during build, and not (like some isomorphic frameworks) at run-time.
Briefly @Gabor_Sebestyen: it's not transpiled. It's not JavaScript. It's WASM. As for debugging, the tools are already pretty solid for debugging the instructions.
And since when does a language wait for penetration before adopting a concept? No one's stopping front-end developers using Closure, TypeScript, CoffeeScript, etc. These are unrelated. However, isomorphic approaches to web development are becoming more prevalent due to the more singular skillset necessary and ability to combine two tiers with a common code-base. Current isomorphic approaches depend on NodeJS predominately.
The ideas behind Rust supporting WASM is to enable Rust to be a more obvious language for server-side and, inherently, web development.
If this conversation is to continue, let's move it to a new thread separately from the server group. FYI: this subject has been raised multiple times already, and I believe it's very relevant and timely to discuss it now. Just not here.
I don't know a lot about how NIO is designed but I want to highlight two things:
Thus, it would be great if this common database access layer could be useful for both worlds.
We've recently discussed internally about the option of switching an eco system. Swift is obviously one of the candidates. We've composed a list of stuff that are of interest regarding our use case.
I'd like to share the list here.
How we should go forward in stabilising and improving our execution.
- Good typing system
- Python interoperability / (Protobuf | Avro | Thrift) interoperability
- Something like this https://github.com/apple/swift-protobuf
- MongoDB support
- Good way for working Mongo and GCP eco system (ORM / ODM / Active Record & co..)
- Concurrency and easy async-await-ish programming.
- Web Framework:
- with user input type casting
- with function like (req) ⇒ res
- Good practices enforced by tooling and automation
- REPL and IDE >> Fast Iterations (as possible)
- Package Management
- Eco System
fucking greatunit test frameworks
- Hopefully something like Jest
- FP
- Good CLI framework
- If no perfect primitives for everything at least easy meta programming
- Intuitive readable syntax
Bonus Points
Works with VSCode
I'm not sure if that library will play nicely with asynchronous database drivers, but yeah that is the type of library i was thinking of.
I'm sure the SwiftNIO team would welcome new codecs and protocols being implemented - NATS sounds like a very useful addition.
That's great to hear. There is a logging thread underway - it would be great if you could share your logging API and discuss its design there.
Are these already open-source? Can you provide a link to them?
Forgive me - what's DAT?
I take your points, but want to highlight that SwiftNIO is not limited to Web Services - it is a low-level async networking framework. You could, for example, use SwiftNIO to write a DNS server, or an AMQP broker, or an SMTP client, or......
... an IRC Server or a Redis server (to support the point ;-)
Great.
I'll take a look. 
Some are. The mirrors on GitHub for others are 3 to 5 months old – waiting for the latest milestone pushes, but they can be done quickly enough. I'm just tidying up the documentation to match the code.
Same projects as we discussed by email, but the milestones slipped, twice. I'll be demoing them all next month & I'll share a URL with them all on next week with the new docs and links to GitHub.
DAT is a decentralized hypermedia protocol for web sites. I'm currently supporting both HTTP (via Kitura) and DAT on all projects, with DAT being in an experimental branch.
It's one of several emerging protocols for building decentralized web applications.
Absolutely, the more protocol implementations with SwiftNIO the merrier. If you do get stuck anywhere or hit any NIO bugs, please do let us know we're happy to help 
.
Great: I'll take a look at how SwiftNIO can be applied to the codebase this weekend.
I need to take a closer look at this. Anyway agreed, let's move this to a separate topic.
Adding more to the Wishlist feedback
Under Develop Experience category:
Edit:
More on scheme evolution, and big data. The ultimate solution would be a columnar storage format, that carries schema within, that can be represented in both on disk and as response from an API call. The would support complex types, compression and have an optional schema.
Avro comes the closet (but not perfectly) https://databaseline.bitbucket.io/an-overview-of-file-and-serialization-formats-in-hadoop/
Also should the format allow 0 memory copying operations such as FlatBuffers: FlatBuffers or https://arrow.apache.org that would truly be the holy grail of data serialisation and IPC formats.