https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query
Rust is finally nailing it.
Never heard of https://vertx.io/ before.
H2O is the fastest C project submitted : https://h2o.examp1e.net/
I wonder how Woo (https://github.com/fukamachi/woo) compares to these.
It's written in Common Lisp and according to the developer it "aims to be the fastest web server written in any programming language."
Would be interesting to see how they stack up.
Where's MIT Scheme? This site is by far the fastest I've ever visited.
This site is by far the fastest I've ever visited.
Try posting in a three digit post count thread from inside the thread, not from the front page, and see how long the thread rebuild takes.
Fastest loading because it loads two small text files per request, most "slow" pages are not because the server is slow or the implementation, but because your browser has to wait for some pictures, js, css or other assets to load before rendering the page.
I'm actually quite amazed how little this can be optimized apparently, for example GitHub which surely have a lot of resources to throw at frontend development takes a very noticeable time to load in comparison to any cgit instance.
>>2
also jfremlin's teepeedee2, which unlike Woo doesn't rely on a C library, but is instead linux/sbcl specific. we don't have correspondingly fast SQL libraries though, which is what benchmark above is also testing.
This year's "Round 19" https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query has some chinese C++11 framework pulling ahead by a crazy 24k margin
>>6
How do they even achieve such differences? I would have assumed that writing webservers is a more-or-less solved problem.
Recently stumbled upon https://learnbchs.org/ which I guess is kinda relevant to this trend.
I'm kinda annoyed by their attitude generally and claim of CGI scripts written in C being "secure" — writing a secure web application from scratch without something saving you from yourself already requires diligence, here with the added problem of most people being incapable of writing secure and correct C code.
The potential for certain use cases is there though. Just look at stuff like cgit which is just very fast thanks to low startup time and server side rendering.
I guess BCHS is BSD people wanting to be relevant and cool, trendy, whatever?!
>>8
~~It's a satire of excess,
Incomprehensibility;
A reminder for sparseness:
Do not pollute the medium.~~
That page not mentioned security about C; That page, at the top, pointed to https://learnbchs.org/tools.html, whose first paragraph's first three sentences were:
Anybody can write crappy, bug-ridden and insecure code. In any language. Good news: with C, it's even easier!
>>9
Broken spoiler?
>>9
I think it doesn't do multi-line?
~~testing
it
now~~
>>11
bold, italics, code and spoiler (<del>) are inline elements. They were only intended to highlight a word in a sentence. Only code blocks are multilines. All the BBCode fun has been slaughtered.
It literally says:
Get used to minimalism and security
HTML inline elements can contain <br> afaik, so I guess the question is why SchemeBBS stops parsing at newlines…
why SchemeBBS stops parsing at newlines
By design.
Users cannot be trusted for typography. They'll separate paragraphs with several lines (but SchemeBBS won't allow that) or they'll use typographical abominations such as text that's both bold and italic (super emphasis?)
Spoilers didn't even exist in the first version of the markup language (years ago, in the Erlang implementation). It's a concession made for the hypothetical poster from /prog/ who really can't live without them and a pain in the ass for those of us who don't use a mouse. You get to hide a word or two but you don't nest spoilers, you don't implement a Pong game in spoilers. No fun's allowed.
Nowadays you have only HTML generation, but that wasn't always the case. S-exp were translated to roff pages at one point. In a man page you have bold and underline but spoilers don't really exist (I know there's an ANSI escape code for invisible text). I digress. Try to do this in Markdown:
**
lol
**
What do you get? The rule of least surprise was followed, I guess.