6 ms·

Swift sucks at web serving or does it?

146 points by MBCook 2y ago

pjmlp 2y ago
Even the selection of frameworks is kind of weird, versus https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks This is what would be interesting to see Vapour/Swift on.
- keyle 2y ago
  Yeah and it leaves out a lot of details to be desired. For example, no debian build of Swift. And when I ported the ubuntu version to .deb, I ran into odd bugs, like when you kill it, it lives on! Apparently a known issue. Basic _big_ bugs that shows Apple's half assed commitment to open-source on any other platform than their own. I can't blame them, but Swift on linux, beware. Swift is a wonderful language, sadly I'm not seeing the commitment from Apple to make it ubiquitous. Also to note, Apple has basically killed macOS as a server, rendering Swift more towards a system/UI target language; which is a shame, because again, it's a wonderful, safe, language.
  - justahuman74 2y ago
    I find it kind of surprising that they don't put more effort behind swift-on-linux, it would make learning swift a generally more valuable skill. This increases the pool of people who would be willing to write mac software, and in particular, standalone libraries
    - Hamuko 2y ago
      I don't find it at all surprising that Apple is not putting any effort into Linux and is instead pooling their developer efforts behind other things. Hopefully things like SwiftUI, a framework that has existed for around five years and still feels a bit immature.
      - jamil7 2y ago
        Yes, SwiftUI, Swift Concurrency and to an extent SPM have been quite frustrating. SwiftUI on macOS in particluar is a major step backwards from AppKit as it is right now.
  - mannuch 2y ago
    Yeah I get that it's frustrating. But it is open source, and there isn't anything stopping you or anyone else from making contributions that bring the language to more places. Sure, various aspects of the project could be improved but that doesn't mean it is "half assed".
  - jamil7 2y ago
    Foundation is going through a gradual open-source rewrite by Apple and the Swift community, which is going to take a while but will eventually open up Swift more to other platforms.
    - jurip 2y ago
      Yeah I have high hopes for the new Foundation. The current open source Foundation is OK but it doesn't quite match what's there on Apple platforms and makes it all a bit difficult. Having one shared implementation should improve things.
    - frou_dh 2y ago
      By the time the Swift project eventually has a great message to share on that, there could well be hardly any non-iOS/macOS developers listening. Look at the last 5-10 years. The momentum gap between e.g. Rust and Swift in the wider development community is gargantuan. IMO if Swift had had a great multiplatform toolchain/developer-experience in the ~2015-2019 timeframe then it could have established itself as the no-brainer C++ successor. But that moment has passed and they squandered the opportunity.
      - pjmlp 2y ago
        It still has an opportunity to be so, but only in the context of Apple's kingdom. If nothing else, because the King says what tools are allowed.
    - neonsunset 2y ago
      It's still funny how this is positively encouraged by HN and yet .NET receives constant stream of FUD and criticism for already being what Swift wishes to be in some 5 to 10 years in terms of being platform agnostic (both the runtime and the tools).
  - __tmk__ 2y ago
    There's a project for using Swift to write GNOME applications, which is fascinating to me: https://github.com/AparokshaUI/adwaita-swift https://github.com/AparokshaUI/adwaita-swift I wish them success but realistically they won't have success.
  - deleted 2y ago
    [deleted]
- mannuch 2y ago
  I don't think this blog post ever intended to provide a comprehensive comparison between Swift/Vapor and other languages/frameworks. I think the bigger lesson from this writeup is that we should be careful when looking at these kinds of benchmark comparisons because there may be much more nuance to their results than there initially appears to be.
  - jamil7 2y ago
    I think so too, I also saw it as a lesson on careful and methodical debugging. I've been in situations like the one written up, trying to debug something tricky where each team member is coming up with multiple wrong hypotheses and missing something obvious.
- nbf_1995 2y ago
  Vapor is on that list, although it has not implemented all tasks (and thus has no composite score). It has results for JSON serialization, and database interop. It places near the bottom in each task it has completed.
deleted 2y ago
[deleted]
willio58 2y ago
I feel like comparing performance of Vapor against Node JS in May of 2024 isn’t all I want to see. Like yes Node JS still dominates but we know other runtimes like Bun run much faster. That part aside, I have to say Vapor kind of took over my brain for a year when I was in college. So much so that I actually built some freelance sites with it. A typed language for web development?! I loved the idea of using swift to make websites and honestly everything just worked so well—-until it didn't. Remember Heroku? Well there was a heroku buildpack to make a vapor site build with a push to a git repo. Worked great 4 years ago. Well I’ve been ignoring heroku emails (my email is a landfill) for about 3 years and little did I know they had completely end-of-lifed the Postgres version I had been using to the point where the entire build was bricked. I could have spent like 5 hours downloading Xcode and getting it updated and working through errors but instead I just spun up a next js TypeScript site and had a working solution with code ported over (yay for static small sites) and deployed live. Today TypeScript does the job that Swift did for me back then, enabling types for web dev. Anyway, thanks to everyone who worked on or currently works on Vapor!
- mannuch 2y ago
  Swift has a pretty good VSCode extension these days actually. Check out https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
  - truncate 2y ago
    Solid is pushing it. Its ok. Its still miles behind Go, Rust, C++. Partly because swift-lsp-server itself is lacking in functionality.
- wiseowise 2y ago
  > A typed language for web development?! What a novel idea.
  - deleted 2y ago
    [deleted]
poochkoishi728 2y ago
Is there a mistake in the Swift graph of 'Success rate (Y) over concurrent requests (X)'? It shows a near-constant 1.0 success rate, but the description says "[Swift] had higher throughput than PHP yet requests started failing much sooner as load increased". EDIT: Nm, it must be referring to the slight dip that starts early in the Swift graph.
- bsaul 2y ago
  That's the pb OP is mentioning quite early : the benchmark didn't make sense.
tedunangst 2y ago
Are the kernel bugs bugs or just not as one assumed? Lots of socket behavior edge cases are unexpected, but also 30 years old.
- hanikesn 2y ago
  He's wrong about increasing somaxconn. That'll just increase 'bufferbloat' if you're service can't keep up processing requests and is overloaded. The upstream load balancer will notice far too late and keep sending you way too many requests.
zokier 2y ago
Sounds like macOS sucks at web serving :) I guess one lesson not explicitly mentioned is that doing benchmarking on something like macOS can have lot of pitfalls compared to systems more intended for this kind of workload (Linux...). But the mention of wrk immediately stood out as a red flag; there is notable problem with wrk called "coordinated omission": https://github.com/wg/wrk/issues/485 https://github.com/wg/wrk/issues/485 https://github.com/giltene/wrk2 https://github.com/giltene/wrk2 https://news.ycombinator.com/item?id=34148502 https://news.ycombinator.com/item?id=34148502 Benchmarking is difficult. And there is lot of subtlety on how you set up the client(s) and servers that can impact the results a lot.
- jeremyjh 2y ago
  People who read the entire article might have noticed many of these problems were reproduced on Linux.
- datadeft 2y ago
  The default limits of MacOS is not really web server benchmark friendly. ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Maximum size of files created by the shell (kB, -f) unlimited Maximum size that may be locked into memory (kB, -l) unlimited Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 256 Maximum stack size (kB, -s) 8176 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 5333 Maximum amount of virtual memory available to each process (kB, -v) unlimited Debian's limits are better: ~> ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Control of maximum nice priority (-e) 0 Maximum size of files created by the shell (kB, -f) unlimited Maximum number of pending signals (-i) 30744 Maximum size that may be locked into memory (kB, -l) 993336 Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 64000 Maximum bytes in POSIX message queues (kB, -q) 800 Maximum realtime scheduling priority (-r) 0 Maximum stack size (kB, -s) 8192 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 30744 Maximum amount of virtual memory available to each process (kB, -v) unlimited Maximum contiguous realtime CPU time (-y) unlimited For testing I always create an instance somewhere (mostly AWS) and configure the OS to have much higher performance limits to enable better performance outcomes.
norman784 2y ago
Swift could have been a big player in web development 9-10 years ago if they invested more in Linux support with a good standard library (and [0]package manager). Nowadays I would say Go is more an alternative rather than Node, maybe for some extreme cases Rust. I wanted to love Swift, but there was (maybe still is) low Apple investment outside the Apple ecosystem. [0] Still not sure to this day why Swift has a package manager if Xcode is not using it (or at least was not using it a few years ago), I just followed lightly Swift development the past few years.
- lukeh 2y ago
  Xcode projects can have Swift package dependencies, and Xcode can open Swift packages directly.
- jillesvangurp 2y ago
  Apple just did not care enough about server development to invest in it. There are plenty of languages and frameworks out there. I wouldn't say Go and Rust are particularly logical choices for web development though. Of course they are being used for that but it's not necessarily the best fit. Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development. People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction. Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it. Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc. On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.
tumetab1 2y ago
Wonderful travel down the rabbit hole.
deleted 2y ago
[deleted]
iraldir 2y ago
Interesting article (did not finish it), however the little apartes feel soooo condescending. It's impeding the reading in my case. Might just be me though, don't pay too much of a mind to it.
julienreszka 2y ago
I have no idea what I just read
neonsunset 2y ago
Benchmark comparison should have used most popular* Web framework for each respective platform and include .NET too. *I could write a Web micro-framework with U8String I'm working on or raw Span/Memory<byte> slices in C# with zero-copy request argument/body binding and beat all of these, would it be a representative experience compared to ASP.NET Core? No, because that's not would be used in an average scenario.
- hu3 2y ago
  Yeah one could use https://github.com/walkor/workerman https://github.com/walkor/workerman for PHP and it would probably beat all other frameworks in the graph. Would it be a representative experience compared to PHP? No, because that's not would be used in an average scenario.
  - neonsunset 2y ago
    It would still be slower :P At least once you start "gaming" benchmarks interpreted and/or dynamically typed languages have a strict ceiling they can't really surpass (just.js doesn't count as it's as thin wrapper on top of C as it can get) https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s... (all top entries are bottlenecked by DB driver implementation and its ability to multiplex queries, and context switching cost, so those frameworks which can do perfect static partitioning and query multiplexing win out)
donatj 2y ago
I am curious the full PHP setup because these benchmarks seem like very uncharitable stats.
lo_fye 2y ago
Makes me wonder how the other languages/frameworks would perform if experts were also looking into them and why they were so slow. Recent versions of pure native PHP, in particular, are incredibly fast and lightweight, and I'm quite surprised by its pokey showing here.
coldtea 2y ago
>A few folks asserted that the CPU-heavy nature of calculating Fibonacci numbers isn’t representative of web servers generally. Multiple people noted that – in the Swift implementation, at least – the majority of the CPU time was spent doing the Fibonacci calculation. Some felt this was therefore not a useful benchmark of Vapor itself. A lot of this boiled down to the “no true Scotsman” problem, which is very common in benchmarking, with a bit of perfect world logical fallacy peppered in, trying to identify the One True Representative Benchmark Well, it doesn't take any True Scotsman to understand that "busy calc of Fibonacci" is a crap web server benchmark. >Accusations were made pretty quickly that the benchmark is “unfair” to Swift because Swift doesn’t – it was asserted – have a properly-optimised “BigInt” implementation, unlike all the other languages tested. No real evidence was given for this. Even if it were true, it doesn’t invalidate the benchmark – in fact, it just makes the benchmark more successful because it’s then highlighted an area where Swift is lacking. This takes defensiveness to the next level. Sure, it might highlighted an area where Swift is lacking. Even lead to opportunity for improvement there. But an even more important question is: does is say anything about what it was supposed to say (and the conclusions they drew from it), that is: whether Swift is good for web serving? In that end, are BigInts a big part of web serving? I've used them maybe a couple of times in 20 years of web/APIs, in very specialized cases. Instead of finding various excuses why the benchmark is not crap, maybe write a decent benchmark to begin with? One can find stupid non-relevant bottlenecks for any language (e.g. nerf Node by blocking work, find some PHP operation that's hella slow and lean on that, etc).
- lukeh 2y ago
  From memory you do need BigInts for ASN.1 decoding which is used in PKIX and thus TLS. Not a bottleneck though.
  - coldtea 2y ago
    Maybe, but all the others are not compared with TLS - who serves web pages with Node or PHP or even Java to terminate TLS? So why would the Swift version need to handle it?
    - 2y ago

146 points by MBCook 2y ago

Even the selection of frameworks is kind of weird, versus https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks This is what would be interesting to see Vapour/Swift on.

keyle 2y ago
Yeah and it leaves out a lot of details to be desired. For example, no debian build of Swift. And when I ported the ubuntu version to .deb, I ran into odd bugs, like when you kill it, it lives on! Apparently a known issue. Basic _big_ bugs that shows Apple's half assed commitment to open-source on any other platform than their own. I can't blame them, but Swift on linux, beware. Swift is a wonderful language, sadly I'm not seeing the commitment from Apple to make it ubiquitous. Also to note, Apple has basically killed macOS as a server, rendering Swift more towards a system/UI target language; which is a shame, because again, it's a wonderful, safe, language.
- justahuman74 2y ago
  I find it kind of surprising that they don't put more effort behind swift-on-linux, it would make learning swift a generally more valuable skill. This increases the pool of people who would be willing to write mac software, and in particular, standalone libraries
  - Hamuko 2y ago
    I don't find it at all surprising that Apple is not putting any effort into Linux and is instead pooling their developer efforts behind other things. Hopefully things like SwiftUI, a framework that has existed for around five years and still feels a bit immature.
    - jamil7 2y ago
      Yes, SwiftUI, Swift Concurrency and to an extent SPM have been quite frustrating. SwiftUI on macOS in particluar is a major step backwards from AppKit as it is right now.
- mannuch 2y ago
  Yeah I get that it's frustrating. But it is open source, and there isn't anything stopping you or anyone else from making contributions that bring the language to more places. Sure, various aspects of the project could be improved but that doesn't mean it is "half assed".
- jamil7 2y ago
  Foundation is going through a gradual open-source rewrite by Apple and the Swift community, which is going to take a while but will eventually open up Swift more to other platforms.
  - jurip 2y ago
    Yeah I have high hopes for the new Foundation. The current open source Foundation is OK but it doesn't quite match what's there on Apple platforms and makes it all a bit difficult. Having one shared implementation should improve things.
  - frou_dh 2y ago
    By the time the Swift project eventually has a great message to share on that, there could well be hardly any non-iOS/macOS developers listening. Look at the last 5-10 years. The momentum gap between e.g. Rust and Swift in the wider development community is gargantuan. IMO if Swift had had a great multiplatform toolchain/developer-experience in the ~2015-2019 timeframe then it could have established itself as the no-brainer C++ successor. But that moment has passed and they squandered the opportunity.
    - pjmlp 2y ago
      It still has an opportunity to be so, but only in the context of Apple's kingdom. If nothing else, because the King says what tools are allowed.
  - neonsunset 2y ago
    It's still funny how this is positively encouraged by HN and yet .NET receives constant stream of FUD and criticism for already being what Swift wishes to be in some 5 to 10 years in terms of being platform agnostic (both the runtime and the tools).
- __tmk__ 2y ago
  There's a project for using Swift to write GNOME applications, which is fascinating to me: https://github.com/AparokshaUI/adwaita-swift https://github.com/AparokshaUI/adwaita-swift I wish them success but realistically they won't have success.
- deleted 2y ago
  [deleted]
mannuch 2y ago
I don't think this blog post ever intended to provide a comprehensive comparison between Swift/Vapor and other languages/frameworks. I think the bigger lesson from this writeup is that we should be careful when looking at these kinds of benchmark comparisons because there may be much more nuance to their results than there initially appears to be.
- jamil7 2y ago
  I think so too, I also saw it as a lesson on careful and methodical debugging. I've been in situations like the one written up, trying to debug something tricky where each team member is coming up with multiple wrong hypotheses and missing something obvious.
nbf_1995 2y ago
Vapor is on that list, although it has not implemented all tasks (and thus has no composite score). It has results for JSON serialization, and database interop. It places near the bottom in each task it has completed.

deleted 2y ago

[deleted]

willio58 2y ago

I feel like comparing performance of Vapor against Node JS in May of 2024 isn’t all I want to see. Like yes Node JS still dominates but we know other runtimes like Bun run much faster. That part aside, I have to say Vapor kind of took over my brain for a year when I was in college. So much so that I actually built some freelance sites with it. A typed language for web development?! I loved the idea of using swift to make websites and honestly everything just worked so well—-until it didn't. Remember Heroku? Well there was a heroku buildpack to make a vapor site build with a push to a git repo. Worked great 4 years ago. Well I’ve been ignoring heroku emails (my email is a landfill) for about 3 years and little did I know they had completely end-of-lifed the Postgres version I had been using to the point where the entire build was bricked. I could have spent like 5 hours downloading Xcode and getting it updated and working through errors but instead I just spun up a next js TypeScript site and had a working solution with code ported over (yay for static small sites) and deployed live. Today TypeScript does the job that Swift did for me back then, enabling types for web dev. Anyway, thanks to everyone who worked on or currently works on Vapor!

mannuch 2y ago
Swift has a pretty good VSCode extension these days actually. Check out https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
- truncate 2y ago
  Solid is pushing it. Its ok. Its still miles behind Go, Rust, C++. Partly because swift-lsp-server itself is lacking in functionality.
wiseowise 2y ago
> A typed language for web development?! What a novel idea.
- deleted 2y ago
  [deleted]

poochkoishi728 2y ago

Is there a mistake in the Swift graph of 'Success rate (Y) over concurrent requests (X)'? It shows a near-constant 1.0 success rate, but the description says "[Swift] had higher throughput than PHP yet requests started failing much sooner as load increased". EDIT: Nm, it must be referring to the slight dip that starts early in the Swift graph.

bsaul 2y ago
That's the pb OP is mentioning quite early : the benchmark didn't make sense.

tedunangst 2y ago

Are the kernel bugs bugs or just not as one assumed? Lots of socket behavior edge cases are unexpected, but also 30 years old.

hanikesn 2y ago
He's wrong about increasing somaxconn. That'll just increase 'bufferbloat' if you're service can't keep up processing requests and is overloaded. The upstream load balancer will notice far too late and keep sending you way too many requests.

zokier 2y ago

Sounds like macOS sucks at web serving :) I guess one lesson not explicitly mentioned is that doing benchmarking on something like macOS can have lot of pitfalls compared to systems more intended for this kind of workload (Linux...). But the mention of wrk immediately stood out as a red flag; there is notable problem with wrk called "coordinated omission": https://github.com/wg/wrk/issues/485 https://github.com/wg/wrk/issues/485 https://github.com/giltene/wrk2 https://github.com/giltene/wrk2 https://news.ycombinator.com/item?id=34148502 https://news.ycombinator.com/item?id=34148502 Benchmarking is difficult. And there is lot of subtlety on how you set up the client(s) and servers that can impact the results a lot.

jeremyjh 2y ago
People who read the entire article might have noticed many of these problems were reproduced on Linux.
datadeft 2y ago
The default limits of MacOS is not really web server benchmark friendly. ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Maximum size of files created by the shell (kB, -f) unlimited Maximum size that may be locked into memory (kB, -l) unlimited Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 256 Maximum stack size (kB, -s) 8176 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 5333 Maximum amount of virtual memory available to each process (kB, -v) unlimited Debian's limits are better: ~> ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Control of maximum nice priority (-e) 0 Maximum size of files created by the shell (kB, -f) unlimited Maximum number of pending signals (-i) 30744 Maximum size that may be locked into memory (kB, -l) 993336 Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 64000 Maximum bytes in POSIX message queues (kB, -q) 800 Maximum realtime scheduling priority (-r) 0 Maximum stack size (kB, -s) 8192 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 30744 Maximum amount of virtual memory available to each process (kB, -v) unlimited Maximum contiguous realtime CPU time (-y) unlimited For testing I always create an instance somewhere (mostly AWS) and configure the OS to have much higher performance limits to enable better performance outcomes.

norman784 2y ago

Swift could have been a big player in web development 9-10 years ago if they invested more in Linux support with a good standard library (and [0]package manager). Nowadays I would say Go is more an alternative rather than Node, maybe for some extreme cases Rust. I wanted to love Swift, but there was (maybe still is) low Apple investment outside the Apple ecosystem. [0] Still not sure to this day why Swift has a package manager if Xcode is not using it (or at least was not using it a few years ago), I just followed lightly Swift development the past few years.

lukeh 2y ago
Xcode projects can have Swift package dependencies, and Xcode can open Swift packages directly.
jillesvangurp 2y ago
Apple just did not care enough about server development to invest in it. There are plenty of languages and frameworks out there. I wouldn't say Go and Rust are particularly logical choices for web development though. Of course they are being used for that but it's not necessarily the best fit. Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development. People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction. Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it. Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc. On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.

tumetab1 2y ago

Wonderful travel down the rabbit hole.

deleted 2y ago

[deleted]

iraldir 2y ago

Interesting article (did not finish it), however the little apartes feel soooo condescending. It's impeding the reading in my case. Might just be me though, don't pay too much of a mind to it.

julienreszka 2y ago

I have no idea what I just read

neonsunset 2y ago

Benchmark comparison should have used most popular* Web framework for each respective platform and include .NET too. *I could write a Web micro-framework with U8String I'm working on or raw Span/Memory<byte> slices in C# with zero-copy request argument/body binding and beat all of these, would it be a representative experience compared to ASP.NET Core? No, because that's not would be used in an average scenario.

hu3 2y ago
Yeah one could use https://github.com/walkor/workerman https://github.com/walkor/workerman for PHP and it would probably beat all other frameworks in the graph. Would it be a representative experience compared to PHP? No, because that's not would be used in an average scenario.
- neonsunset 2y ago
  It would still be slower :P At least once you start "gaming" benchmarks interpreted and/or dynamically typed languages have a strict ceiling they can't really surpass (just.js doesn't count as it's as thin wrapper on top of C as it can get) https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s... (all top entries are bottlenecked by DB driver implementation and its ability to multiplex queries, and context switching cost, so those frameworks which can do perfect static partitioning and query multiplexing win out)

donatj 2y ago

I am curious the full PHP setup because these benchmarks seem like very uncharitable stats.

lo_fye 2y ago

Makes me wonder how the other languages/frameworks would perform if experts were also looking into them and why they were so slow. Recent versions of pure native PHP, in particular, are incredibly fast and lightweight, and I'm quite surprised by its pokey showing here.

coldtea 2y ago

>A few folks asserted that the CPU-heavy nature of calculating Fibonacci numbers isn’t representative of web servers generally. Multiple people noted that – in the Swift implementation, at least – the majority of the CPU time was spent doing the Fibonacci calculation. Some felt this was therefore not a useful benchmark of Vapor itself. A lot of this boiled down to the “no true Scotsman” problem, which is very common in benchmarking, with a bit of perfect world logical fallacy peppered in, trying to identify the One True Representative Benchmark Well, it doesn't take any True Scotsman to understand that "busy calc of Fibonacci" is a crap web server benchmark. >Accusations were made pretty quickly that the benchmark is “unfair” to Swift because Swift doesn’t – it was asserted – have a properly-optimised “BigInt” implementation, unlike all the other languages tested. No real evidence was given for this. Even if it were true, it doesn’t invalidate the benchmark – in fact, it just makes the benchmark more successful because it’s then highlighted an area where Swift is lacking. This takes defensiveness to the next level. Sure, it might highlighted an area where Swift is lacking. Even lead to opportunity for improvement there. But an even more important question is: does is say anything about what it was supposed to say (and the conclusions they drew from it), that is: whether Swift is good for web serving? In that end, are BigInts a big part of web serving? I've used them maybe a couple of times in 20 years of web/APIs, in very specialized cases. Instead of finding various excuses why the benchmark is not crap, maybe write a decent benchmark to begin with? One can find stupid non-relevant bottlenecks for any language (e.g. nerf Node by blocking work, find some PHP operation that's hella slow and lean on that, etc).

lukeh 2y ago
From memory you do need BigInts for ASN.1 decoding which is used in PKIX and thus TLS. Not a bottleneck though.
- coldtea 2y ago
  Maybe, but all the others are not compared with TLS - who serves web pages with Node or PHP or even Java to terminate TLS? So why would the Swift version need to handle it?
  - 2y ago