(NOTE: I'm using the term "framework" here, some people think since Ktor isn't a Rails or Spring-style framework, it's not the correct term, but for the purposes of this post, please look past that, call it a library for connected code, whatever) Surface level tutorials, including the Ktor ones, that show how to implement a simple rest API or client in a given framework are great. I've had a look at a bunch of them and they do a good job of explaining basic Ktor concepts like plugins etc. But they don't really showcase or go into detail about the thought process behind, or how, the framework was built and how it works under the hood. The main differences I can see so far seems to be that Ktor (unsurprisingly) makes heavy use of Kotlin features such as coroutines, DSL, extension functions etc. ## Coroutines In a traditional synchronous framework, there's a thread pool of N threads, and each request will occupy (block) and live in a thread until the service responds, and if you mark an endpoint or service method called as part of that endpoint as async, what that means is the framework will spin up a piece of work in a different thread to do that work, but respond before that work has generated a result. Obviously, this isn't what is being referred to with async in Ktor, because then Ktor would always just respond immediately before any work has been done. My understanding is, rather, using Ktor with a simple scheduler, there will only be one thread per core in your machine, but those threads be able to spin up lots of coroutines which do things like accept a request, perform computations, io like storing to db or calling other services etc, and those coroutines while eg waiting for a response from the db or other service will be paused until they have a result. So eg a request to an endpoint that does three things before responding, the request will result in a parent coroutine, and each of those three things that get done (if they're suspend funs) would be child coroutines, and the three things will execute asynchronously and in parallel, and then when all of them have results there will be a response. Because coroutines are lighter weight than threads, you spin up many times more coroutines than threads, increasing performance, which ultimately means you can serve more traffic with less cloud resources. Is my understanding roughly correct? ## Dsl and extension functions Can someone explain the thoughts behind Ktors use of DSL and extension functions? I'm not looking for answers like "Ktor uses it because it's written in Kotlin" or "Ktor uses it because it's nicer than annotations"... A framework could be written from the ground up in Kotlin that is designed completely differently from Ktor - eg, it could eschew DSL completely and rely on just instantiating endpoints like eg val getUser : Get = Get(Url(/users)) as objects that get attached to resource objects that get attached to an app objects etc etc. Why is Kotlin designed the way it is, what was the thought process behind it? Or is its design kind of an accident? The history of the framework seems semi accidental to me - it seems like it was originally mostly an internal experimental framework that happened to catch on, which took the development team kind of by surprise a bit. ## Misc By all means any other ways you can think of that Ktor is different and explain in more detail how it's built and how it works under the hood vs other frameworks would be super useful.