Running an example main with the route '/' mapped to return "Hello World"
ab -n 10000 http://127.0.0.1:8080/
I get 1400 requests/s in debug mode and 1900 requests/s in release mode.
With wrk, I actually get between 3000-4000 requests/s with default parameters. Most of the time. Sometimes it just hangs. Trying to increase the number of requests with the -r parameter made the hangs consistent, I was not able to get wrk to finish in more than a dozen attempts, so there appears to be a problem with it dying under load.
For comparison, the built-in Apache gets 15000-20000 requests/s, my own web-framework based on libmicrohttpd + an Objective-C/Objective-Smalltalk wrapper gets around 25000-32000. None of these would be classified as "insanely" fast, and they are around an order of magnitude faster than this. It's actually a lot closer to Ruby/Sinatra (~600 requests/s).
EDIT: project readme says "insanely", not "blazingly", so updated.
At least the insanely fast speed of Vapor also goes well on the client side with Vapor.JS, the world's smallest and fastest JavaScript library: https://github.com/madrobby/vapor.js/tree/master
I also really have great hopes for Swift as a modern, x-platform, general purpose, compiled language. Go is not general purpose; Rust is too low level. Haskell has a too steep learning curve.
Ur/Web is really great, but not at all general purpose.
Why am I hung up over "general purposeness"? Well when I learn a language, it takes quite a bit of my time; then I want to be able to apply it broadly.
There is no arguing with Turing equivalence of Go and most other languages but there are practical limitations which prevent more complete general purposeness.
I like Go since the beginning. However, Go cannot be easily used for kernel development, soft or hard real-time or embedded systems (no linker script support and porting runtime is weighty) and there are few transpilers.
Rust is slightly better, because PoC kernels have been put together with fewer hacks. Haskell, C, Ada, assembly are much more general purpose in terms of being able to build something like seL4, an F-15 cockpit, an engine management system or compiling code as ASIC circuitry. (Perl's supposed use in nuclear armaments notwithstanding.)
PS: I would like to see some geninuses come up with a back-back-end to LLVM or a disassembler which could formally prove binary satisfiability of program correctness without mind-bending, gibberish, over-mathematized, incantations inaccessible to us mere, stupid mortals.
Which language doesn't have "practical limitations"? And it's no doubt more "general purpose" than assembly. How much webdev are you going to do with assembly?
I'd say a language is general-purpose when it has not been tailored to a specific scenario or area of problems, but to work well for most. Isn't that, to a great extent, true for go?
Why would you compare it to Dylan? Swift will be the most popular iOS language within 18 months. If you look at the new iOS books that are released, most use Swift. I count over 3 dozen books within 18 months of Swift's release:
It's weird how little qualifies for 'type-safe' nowadays. The templating language is not typesafe for example. The parameters in the request aren't either. Take a look at http://haskell-servant.github.io/ if you want to see what type-safe means.
We are working hard to make all aspects of Vapor totally type safe. But, just by merit of being Swift, it's already infinitely more type safe than something like PHP.
A key goal of the project is to avoid the use of `Any` anywhere possible, and to move any run time safety checks to compile time.
Many of them are for JVM, but one cool thing about JVM, is that you don't have to use Java (Kotlin is often compared to Swift for example) while still using frameworks written in Java, like Undertow or Rapidoid.
Is there documentation I'm missing? Based just on the readme I don't think I understand how this works. For instance, the section on the Request object omits HTTP headers, then the Async section shows sending response headers manually. But they're sent asynchronously for some reason? There's a .Hash method that apparently does SHA-1 hashing, though I don't know why. At the point I stopped reading because I didn't understand what the examples were telling me.
I don't mean to be negative or try to poke holes in your hard work. I'd just like to know how to use it. "Insanely fast, beautiful syntax, type safe" are super alluring features! But let me know how I can build a real application with it.
The server isn't single threaded. It uses the dispatch concurrent thread pool for processing. The (granted, ugly) line you've linked is for blocking and keeping the main thread alive so the process doesn't end. However, the requests are processed on the dispatch "Background" queue. See "boot" here:
Do you realize that node.js is single threaded?
Having more than one process works fine for most purposes. Because the bottlenecks are more IO driven than CPU time.
I saw it. It's just a function to keep the main thread, ie. main() alive while the worker threads process the async events. Nothing out of the ordinary..
This line is just meant to keep the process alive. The actual implementation of the ServerDriver uses threads. It's also worth mentioning that Vapor is totally protocol-based and modular, so you can easily plug in any class that conforms to ServerDriver and replace this logic.
I suppose most who do Swift at the moment also use it on front-end, since this advertises being "type-safe" what is their preferred method to connect to this JSON server from the Swift front-end in type safe manner?
Also, the Fluent is clearly not type-safe, it's stringly typed ORM to database. Since many backends are just fancy wrappers to database, this part should be most important for type-safety. It's nowhere as type safe as Quill, Slick or JOOQ.
Honest question: what's the appeal of Swift outside of iOS/OSX development? I can understand the need for an Objective-C replacement, but after more than two decades of evolution, web dev doesn't lack of good and modern languages running on top of very performant and mature platforms, with rich ecosystems. Swift brings absolutely nothing to the table.
I'll admit my total naivete up front: isn't Swift already a typed language? Is there something about being a web framework that necessitates some other kind of type safety?
The more advanced a type system is, the more it depends on what you do with it when designing an API. A well designed API in a language with a rich, expressive type system can make higher-level guarantees. On the opposite side of the spectrum you could just use Strings for most of the types (it’s web after all!) and it would still be type safe, although the type guarantees wouldn’t be of much use.
You define a closure to handle requests matching paths with type-safety. You are passed the correct parameter types and the correct amount of parameters directly to your closure. This gives you compile type safety.
// Handle GET requests to path /users/{username}
get("users", *) { (request, username: String) in
return "Hello \(username)"
}
In contrast, without this compile-time safety you will most likely be passed an array of Strings and you will have to pull items out.
Route.get("users/:username") { request in
if let username = request.parameters["username"] {
// Return something with username
} else {
// TODO Return 404
}
}
Here you have to manually validate these parameters, there is also the lack of compile time safety in the way you are writing a hard-coded string for each parameters. There is a string "username" twice, both the path and when you pull out the parameter from the array. There is a large room for user error or typos here.
Thanks for the clarifications. As soon as web text-based protocols were mentioned, I said "oh duh" to myself. There's nothing about the availability of a type system that forces a plain-data wrapper library to use it.
The mistake most of these make is they are both web frameworks and they have their own build in web server. We should learn from mistakes in previous communities such as in Python (https://www.python.org/dev/peps/pep-0333/#rationale-and-goal...) and not tightly coupling these things together.
A user should be free to choose their favourite web framework and then choose the best web server for their needs.
Running an example main with the route '/' mapped to return "Hello World"
I get 1400 requests/s in debug mode and 1900 requests/s in release mode.With wrk, I actually get between 3000-4000 requests/s with default parameters. Most of the time. Sometimes it just hangs. Trying to increase the number of requests with the -r parameter made the hangs consistent, I was not able to get wrk to finish in more than a dozen attempts, so there appears to be a problem with it dying under load.
For comparison, the built-in Apache gets 15000-20000 requests/s, my own web-framework based on libmicrohttpd + an Objective-C/Objective-Smalltalk wrapper gets around 25000-32000. None of these would be classified as "insanely" fast, and they are around an order of magnitude faster than this. It's actually a lot closer to Ruby/Sinatra (~600 requests/s).
EDIT: project readme says "insanely", not "blazingly", so updated.