4 ms·

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over an

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours more than makes up for the slow down in productivity rates we’ve seen across advanced economies lately!

kika 4y ago
It's not a language, because why do you need language for that. But it's called Hasura, written in Haskell. It's a server which translates Postgres into GraphQL.
candiddevmike 4y ago
You just described any modern language paired with Sqlite.
- williamcotton 4y ago
  I mean, I’ve written C that listens on port 80 and parses HTTP requests directly into SQLite op code but that is definitely not how it is working when you glue together a bunch of npm modules. Just like how SQL gives you a faster way to not only store and search through binary trees but also to write the instructions to do so means that we should be able to do the same for web applications. I’m not sure that most parts of a web application need to be Turing complete. User permissions? Data validation? Can’t we have GUI tools with a 1:1 mapping to more declarative code, ala SwiftUI? Why are we using a garbage collector for an HTTP request when we could just be freeing up memory after the response is sent?
jcmontx 4y ago
I don't get the downvotes. What you say makes sense to me. A web-first programming language. Wasn't that the origin of PHP?
bbkane 4y ago
I haven't tried this, but I think you can get fairly close by generating the HTTP/SQL serialization code. When I get time I want to write an openapi schema amd generate the server code, write a db schema and generate the db code (I want to try https://github.com/ariga/atlas https://github.com/ariga/atlas with Ent for this), then write the business logic between them and see how well it all works
nephanth 4y ago
Isn't that the problem that the backend framework + orm combination aim to solve? Like django, or flask+sqlalchemy
- williamcotton 4y ago
  If you squint your eyes, sure, but if you’re looking at the details of something like Django or Rails you’re still having to wire up your own analytics, A/B testing, user permissions, headless browser testing… first, why not make all of these language features? Second, when you wire up a web server module with a SQLite module with a JSON module and translate between them in Ruby or Python you’re taking a really big performance hit. Just think about how many times something is being translated into an unused intermediate state because that just happens to be how the ready-made pipes are sized. I’m saying, let’s build a bunch of ready-made pipes that are built specifically for SQL backed HTTP servers and with the features that we all seem to use on every project. The end result should make it easier and faster to build a more performant web application.
pjmlp 4y ago
PHP, Java and .NET have been doing it for 20 years, more or less.
- rockisch 4y ago
  Go as well.
  - pjmlp 4y ago
    Note the 20 years, and Go still lacks good quality database drivers for big enterprise databases.
mike_hearn 4y ago
Modern OpenJDK comes with a built-in HTTP server, and you can also embed a relational database like H2 or of course SQLite. You can use it from many different languages, of course. Actually it sounds from the article like Kotlin or Java would have been a better fit than Rust for what they were doing. There are also things like Postgrest which turns postgres tables into REST APIs automatically. But here's something to really chew on. Do we need the HTTP server at all? Consider: why exactly do we need so much middleware plumbing for ordinary database driven web apps? A lot of this is to do with a winding evolutionary path rather than what you'd design with a clean slate. Something I've been experimenting with lately is writing apps that connect directly to an RDBMS using its native protocol, over the internet, from a desktop app. Obvs the next step after is to try the same with a mobile app. Historically we've relied on web browsers and written translation layers for a few different reasons, but tech has been improving over time and some of those reasons are becoming obsolete: 1. Free relational databases were really rough back then and the commercial DBs often had weird limitations around distributing DB drivers. These days it's easier and postgres is a lot better. 2. You needed to slather lots of caches and other stuff in front of the RDBMS if you had high traffic. Modern DBs are a lot better at materialized views, cached query plans, read replicas etc. Postgres has a variety of load balancers that can sit in front of it and work around its per-connection overhead. 3. Security wasn't good enough. Nowadays you have features like row level security, security-definer views etc in the free DBs. 4. People translate everything to HTML/HTTP partly because it was too hard to distribute and update apps to Windows desktops/laptops in the 2000s, due to MS just generally losing the ability to execute and being distracted by stuff like Longhorn/WinFS. Browsers solved the basics of caching and refreshing of code for you. Now there's https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/ which makes distributing desktop apps way easier. It's a lot more feasible now to just knock out a quick desktop app and upload to an S3 bucket, with built in online updates. Also the next release will support force-update-on-start, so you can get a web like experience where the user is always up to date so the schemas and client can be evolved in parallel. If you could just write your UI using a 'real' UI toolkit and invoke directly to the DB from the UI code, you wouldn't need a lot of the microservices plumbing anymore, you wouldn't need to serialize stuff to JSON or HTML. You could just use the underlying DB protocol as an RPC layer and let the DB enforce business logic. It can be done for common kinds of enterprise apps today: there are only a few problems to solve, none of them especially hard. For instance a little service that turned OAuth SSO into client side certificates would make it easy to connect to a DB without needing to manage usernames or passwords. A tunnelling solution to get through awkward firewalls would also be useful (websockets etc). For consumer apps there's more complexity. You wouldn't try to implement twitter that way for instance. But still, for the kind of SaaS-y thing that the article is about it could have saved a lot of complexity and improved iteration speed.
roryokane 4y ago
Some languages that integrate with an HTTP server and a database: Ur/Web: http://impredicative.com/ur/ http://impredicative.com/ur/ Dark (Darklang): https://darklang.com/ https://darklang.com/
- tandijthrows 4y ago
  Oh no, please no Ur. Sounds good first, but so far from production-readiness. Research? Inspiration? Check. Use in production? No.
- williamcotton 4y ago
  Thank you for the introduction!

kika 4y ago

It's not a language, because why do you need language for that. But it's called Hasura, written in Haskell. It's a server which translates Postgres into GraphQL.

candiddevmike 4y ago

You just described any modern language paired with Sqlite.

williamcotton 4y ago
I mean, I’ve written C that listens on port 80 and parses HTTP requests directly into SQLite op code but that is definitely not how it is working when you glue together a bunch of npm modules. Just like how SQL gives you a faster way to not only store and search through binary trees but also to write the instructions to do so means that we should be able to do the same for web applications. I’m not sure that most parts of a web application need to be Turing complete. User permissions? Data validation? Can’t we have GUI tools with a 1:1 mapping to more declarative code, ala SwiftUI? Why are we using a garbage collector for an HTTP request when we could just be freeing up memory after the response is sent?

jcmontx 4y ago

I don't get the downvotes. What you say makes sense to me. A web-first programming language. Wasn't that the origin of PHP?

bbkane 4y ago

I haven't tried this, but I think you can get fairly close by generating the HTTP/SQL serialization code. When I get time I want to write an openapi schema amd generate the server code, write a db schema and generate the db code (I want to try https://github.com/ariga/atlas https://github.com/ariga/atlas with Ent for this), then write the business logic between them and see how well it all works

nephanth 4y ago

Isn't that the problem that the backend framework + orm combination aim to solve? Like django, or flask+sqlalchemy

williamcotton 4y ago
If you squint your eyes, sure, but if you’re looking at the details of something like Django or Rails you’re still having to wire up your own analytics, A/B testing, user permissions, headless browser testing… first, why not make all of these language features? Second, when you wire up a web server module with a SQLite module with a JSON module and translate between them in Ruby or Python you’re taking a really big performance hit. Just think about how many times something is being translated into an unused intermediate state because that just happens to be how the ready-made pipes are sized. I’m saying, let’s build a bunch of ready-made pipes that are built specifically for SQL backed HTTP servers and with the features that we all seem to use on every project. The end result should make it easier and faster to build a more performant web application.

pjmlp 4y ago

PHP, Java and .NET have been doing it for 20 years, more or less.

rockisch 4y ago
Go as well.
- pjmlp 4y ago
  Note the 20 years, and Go still lacks good quality database drivers for big enterprise databases.

mike_hearn 4y ago

Modern OpenJDK comes with a built-in HTTP server, and you can also embed a relational database like H2 or of course SQLite. You can use it from many different languages, of course. Actually it sounds from the article like Kotlin or Java would have been a better fit than Rust for what they were doing. There are also things like Postgrest which turns postgres tables into REST APIs automatically. But here's something to really chew on. Do we need the HTTP server at all? Consider: why exactly do we need so much middleware plumbing for ordinary database driven web apps? A lot of this is to do with a winding evolutionary path rather than what you'd design with a clean slate. Something I've been experimenting with lately is writing apps that connect directly to an RDBMS using its native protocol, over the internet, from a desktop app. Obvs the next step after is to try the same with a mobile app. Historically we've relied on web browsers and written translation layers for a few different reasons, but tech has been improving over time and some of those reasons are becoming obsolete: 1. Free relational databases were really rough back then and the commercial DBs often had weird limitations around distributing DB drivers. These days it's easier and postgres is a lot better. 2. You needed to slather lots of caches and other stuff in front of the RDBMS if you had high traffic. Modern DBs are a lot better at materialized views, cached query plans, read replicas etc. Postgres has a variety of load balancers that can sit in front of it and work around its per-connection overhead. 3. Security wasn't good enough. Nowadays you have features like row level security, security-definer views etc in the free DBs. 4. People translate everything to HTML/HTTP partly because it was too hard to distribute and update apps to Windows desktops/laptops in the 2000s, due to MS just generally losing the ability to execute and being distracted by stuff like Longhorn/WinFS. Browsers solved the basics of caching and refreshing of code for you. Now there's https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/ which makes distributing desktop apps way easier. It's a lot more feasible now to just knock out a quick desktop app and upload to an S3 bucket, with built in online updates. Also the next release will support force-update-on-start, so you can get a web like experience where the user is always up to date so the schemas and client can be evolved in parallel. If you could just write your UI using a 'real' UI toolkit and invoke directly to the DB from the UI code, you wouldn't need a lot of the microservices plumbing anymore, you wouldn't need to serialize stuff to JSON or HTML. You could just use the underlying DB protocol as an RPC layer and let the DB enforce business logic. It can be done for common kinds of enterprise apps today: there are only a few problems to solve, none of them especially hard. For instance a little service that turned OAuth SSO into client side certificates would make it easy to connect to a DB without needing to manage usernames or passwords. A tunnelling solution to get through awkward firewalls would also be useful (websockets etc). For consumer apps there's more complexity. You wouldn't try to implement twitter that way for instance. But still, for the kind of SaaS-y thing that the article is about it could have saved a lot of complexity and improved iteration speed.

roryokane 4y ago

Some languages that integrate with an HTTP server and a database: Ur/Web: http://impredicative.com/ur/ http://impredicative.com/ur/ Dark (Darklang): https://darklang.com/ https://darklang.com/

tandijthrows 4y ago
Oh no, please no Ur. Sounds good first, but so far from production-readiness. Research? Inspiration? Check. Use in production? No.
williamcotton 4y ago
Thank you for the introduction!