The main reason why server-side stuff is slow is poor use of the database. Doing e.g. nested loops in a compiled language uses way less CPU than a scripting language, but it should be done in the DB in the first place.
I used XMonad for about 1 year. Back at FVWM since ca. 8 years, but XMonad influenced the setup quite a bit. The WM is barely noticeable, it manages 2 full screen rxvt/ssh/screen windows, Firefox, Zoom and little else. Keybindings + integration with a self written Plan9 plumber-like tool (edit/modify selection, link to bug db, jira, ... based on selection contents) are the real productivity boosters.
21 years ago, I joined a young team that wrote an ERP, with all business logic in PL/SQL. Customers are still amazed how fast these guys are going. 10 years ago I joined Oracle to work on APEX (created in 1999), which is a web app development and runtime environment, written in PL/SQL. We estimate that there are about 260K developers world-wide who are developing apps with APEX. All of their business logic is also on the server. Call me biased because I am working for the man, but my data points are completely different.
I worked with two other ERP class systems that did this, one using Oracle (with an Oracle Forms/Reports front-end), the other PostgreSQL.
I can confirm your experience. There's no doubt that stored procedure/function based business logic requires a certain discipline, knowledge set, and the ability to get a team in marching in the same direction. But if you can achieve the organizational discipline to make it work there are definite advantages, especially in the ERP space.
And that may well be differentiator... those of us working with more traditional business systems have trade-offs that you won't find in a startup. For example, a COTS ERP system is more likely to not really be a single "application", but a bunch of applications sharing data. This means a lot of application servers, integrations, etc., not all from the people that made the ERP, needing access to the ERP data. The easiest integration is often at the database, especially since you can have technology from different decades (and made according to the fashions of their time) needing to access that one common denominator. Since many ERP systems are built on traditional RDBMSs, and talking to those doesn't change much over long periods of time... having the logic be there to make these best of breed systems work sensibly with the ERP can be very helpful. All that said, in this context I'm an advocate of the approach.
Now, take a team that maybe has a high churn, sees the database as some dark and frighting mystical power that can only safely be approached with an ORM, or a team that thinks their "cowboy coding" is their core strength (if perhaps not that thought directly) and database based business logic certainly has many foot-guns. But, there are really few technologies that don't suffer without a good well-rounded, consistent approach.
It's posts like this that make HN great (again). Thank you.
I want to add that your talent pool will also influence where to create a hardened boundary: inside the database server (if you have lots of SQL people), or inside the application server (if you have lots of C#/Java/Python people).
Back in 2009 I helped to put together a small app in APEX, which then was quite new, in the two days, or day and a half, before the lead developer left for an overseas vacation. I had never before used APEX, she had been introduced to it an an Oracle tech day, but that was the extent of either's experience with it. The application is long gone, but got a lot of use over several months.
PL/SQL is an excellent tool for implementing business logic, and I really like APEX largely because I can call PL/SQL at any of several points.
I agree, Apex is awesome. Oracle Apex being written in stored procedures was actually a big inspiration for a low code tool project I did myself, which while not being written in stored procedures took alot of other ideas from Apex (I was an Oracle Apex developer for 4 years)
Oracle used to push the idea that there is no need for an application layer, just use the database. Then they stopped being silly. I used APEX as a user, while at Oracle. It was a decent reporting tool but was only really used because the CRM had terrible latency.
That has been in 2017, when there was also this famous discussion between Hancock, Carlson and Shermer on the JRE. Shermer is the publisher of Skeptic Magazine, which you quoted. He recently tweeted this: https://twitter.com/michaelshermer/status/123755946996742144...
Some of his claims are quite far-fetched and esoteric. However, even Michael Shermer, head of Skeptic magazine, recently admitted (https://twitter.com/michaelshermer/status/123755946996742144...) that there is some plausibility for the younger dryas impact hypothesis, which is currently an important part of Hancock's lost civilization claims. Such a major catastrophe would of course have a reset effect on any existing advanced civilization. This alone is not proof that there was one, of course.
That's not entirely correct. A hard parse causes the optimizer to do bind variable peeking, i.e. it chooses the execution plan based on the bind variable value.
Very nice proof of concept. Just a word of warning: In practice you want to sanitize your input. The code in "Serving static files" allows to break out of document-root with "..".
Have you tried to actually exploit that? I don't currently use Racket myself, but I would expect request-uri to prevent ".." and if it didn't surely url-path would.
; extract the URI from the request:
(define uri (request-uri req))
; extract the resource from the URI:
(define resource
(map path/param-path (url-path uri)))
; find the file location:
(define file (string-append
document-root
"/"
(string-join resource "/")))
