I’ve been thinking about this very carefully, and I’ve realized that my personal opinion has changed, so I’m wondering how everyone else feels about this.
I think web servers should now just be part of language libraries. I think languages that lack a server as part of their library are hobbled. These days, a web server fills the same void that, a couple decades ago, stdin and stdout did. Within reasonable bounds, every production app either has a mobile GUI, or is a website–much as, a decade ago, I’d have said that apps were either GUIs or command-line tools. Since most languages can’t do a mobile GUI out-of-the-box, they owe it to themselves to do a web server. Thus, while it might be “web people” who ought to write this, I think we’re all web people now.
Thoughts? Am I crazy? If I am crazy, why? If I’m not, what’s the solution here? Maybe we need some hybrid of something like inetd plus stdin/stdout such that web servers no longer need to be a special framework in the first place? What would that look like?
Every single service that I’ve written in the past 4 years has had an HTTP listener as part of it, for one reason or another. Either it was actually a web application, or I was monitoring it by connecting to it over HTTP.
There’s a reason for this. HTTP out of the box has things like authentication, encryption via HTTPS, etc. And, there’s a million different, already built clients that I can use to check on things. It’s a no brainer. It just works.
So, yeah, I agree with you here. Should be part of the stdlib.
There is a tension between how fast such a library must move and how fast people want their language to move. You can sometimes ship library updates as “minor” updates, but people looking for long term languages still don’t want to see that.
Mentioned before, but once more, For a long time Python 2 didn’t support SNI for https requests. “Try Python 3” wasn’t really what people wanted to hear either. It would have been better to decouple this feature from the language lifetime. (There were also several other ways things could have gone better.)
every production app either has a mobile GUI, or is a website
I think this is only true in a pretty specific part of the world. There are a lot of production applications in my part of the world (AI) that touch neither a GUI nor HTTP, at least not directly. They may produce data that is later used by something else that has a GUI or speaks HTTP, but that’s different from every application doing those things. Lots of stuff runs purely command line, either classic batch-mode, or more “cloud-style” deployment in containers. I/O is to and from either files, or a database. If interactive use is needed, the UI story often comes through embedding the application in a separate existing environment, e.g. make a version that runs as a Matlab plugin or R package.
i think ORM is just the generic term for that, without necessarily referring to objects in the OOP sense. here we’d likely want something that seamlessly generated all the boilerplate to convert between a database row and an ocaml record.
Of these, I’d suggest multicore and namespaces are the only fundamental bits. The rest are kind of web dev moans, and if they are important, can be built by people who want them.
[Comment removed by author]
I’ve been thinking about this very carefully, and I’ve realized that my personal opinion has changed, so I’m wondering how everyone else feels about this.
I think web servers should now just be part of language libraries. I think languages that lack a server as part of their library are hobbled. These days, a web server fills the same void that, a couple decades ago,
stdinandstdoutdid. Within reasonable bounds, every production app either has a mobile GUI, or is a website–much as, a decade ago, I’d have said that apps were either GUIs or command-line tools. Since most languages can’t do a mobile GUI out-of-the-box, they owe it to themselves to do a web server. Thus, while it might be “web people” who ought to write this, I think we’re all web people now.Thoughts? Am I crazy? If I am crazy, why? If I’m not, what’s the solution here? Maybe we need some hybrid of something like
inetdplusstdin/stdoutsuch that web servers no longer need to be a special framework in the first place? What would that look like?Every single service that I’ve written in the past 4 years has had an HTTP listener as part of it, for one reason or another. Either it was actually a web application, or I was monitoring it by connecting to it over HTTP.
There’s a reason for this. HTTP out of the box has things like authentication, encryption via HTTPS, etc. And, there’s a million different, already built clients that I can use to check on things. It’s a no brainer. It just works.
So, yeah, I agree with you here. Should be part of the stdlib.
There is a tension between how fast such a library must move and how fast people want their language to move. You can sometimes ship library updates as “minor” updates, but people looking for long term languages still don’t want to see that.
Mentioned before, but once more, For a long time Python 2 didn’t support SNI for https requests. “Try Python 3” wasn’t really what people wanted to hear either. It would have been better to decouple this feature from the language lifetime. (There were also several other ways things could have gone better.)
I think this is only true in a pretty specific part of the world. There are a lot of production applications in my part of the world (AI) that touch neither a GUI nor HTTP, at least not directly. They may produce data that is later used by something else that has a GUI or speaks HTTP, but that’s different from every application doing those things. Lots of stuff runs purely command line, either classic batch-mode, or more “cloud-style” deployment in containers. I/O is to and from either files, or a database. If interactive use is needed, the UI story often comes through embedding the application in a separate existing environment, e.g. make a version that runs as a Matlab plugin or R package.
i think ORM is just the generic term for that, without necessarily referring to objects in the OOP sense. here we’d likely want something that seamlessly generated all the boilerplate to convert between a database row and an ocaml record.
Of these, I’d suggest multicore and namespaces are the only fundamental bits. The rest are kind of web dev moans, and if they are important, can be built by people who want them.
namespaces would be huge. i would also love to see a solid, “just works” cross-compiler toolchain; golang got that one right.