Everyone in this thread is going to call out issues with writing a Web application using C.
Refer to the newest Talk Python podcast where a core CPython developer was told that Python is memory safe and his response was “is it?”.
At some point we need to be more sophisticated about this, our hardware is fundamentally unsafe, anything we build on it is fundamentally unsafe and there are degrees to which things are better or worse and that’s it. All that matters is the love, rigour and care you put into your work.
Proceed as you wish, a backend in C is valid a backend in LISP is valid.
People don't realize how much performance they're leaving on the table by not using C/C++/Rust. Get uWebSockets and set up a demo server, it's going to be 10-50x faster than a Node.js server. Quite literally the performance delta is that drastic.
Objective-C is still a sweet spot for this, if you wield it right.
It can get you most of the Smalltalk (Python/Ruby) conveniences with most of C's speed. In fact, if you do it really well you can leverage them together to get better than both. Simultaenously.
Doesn't mean that people don't manage to wield it in such a way as to get all the convenience of C combined with the performance of Python/Ruby. Which always baffles me. You .... did .... WAT?
To me the Right Thing™ here always seemed the obvious and simple thing to do, as in: just don't spend extra effort to mess it up and you'll be fine. YMMV.
Plug: my book gives fairly detailed instructions on how to achieve the positive combination. [1]
Other plug: Making it easier to get this right is the 2nd of the four stages of Objective-Smalltalk. [2][3]
People do actually realize. It's just that people have decided it's not the most important thing when it comes to delivering software. There's a reason Node and Python are the most popular ecosystems.
You would be surprised how fast Node/Bun can be if you scale them properly. If you use Bun, you are using uWebSockets already. If what you are doing in your application is database queries and some template rendering, you might not actually gain that much from these compiled languages.
Most people don't need to care about that. If you're writing something that's gonna be used by a fixed number of real humans a few times (or a even a few 1000) times a day the overhead isn't gonna matter
It used to be the way before Java, .NET took off, only to be replaced by slow interpreted languages, because who cares, the database is the bottleneck.
Note that PHP and Perl also had enough C code, and Apache/IIS plugins, with enough C and C++ extensions.
Now all those "who cares scripting languages" are getting JIT compilers, or being rewritten into Go and Rust.
I play with c some but I just could not stand the libraries I could find to work with fast cgi, just totally opaque and I would get hung up on things like handling some socket a doohicky would hand over and I'm supposed to work with it and I could never figure it out.
Once I ditched the library idea and just coded to the spec things went much nicer lol it turned out to be a relatively normal socket coding project. Just hobby code tho.
Yep, me. In fact, I wrote a whole netstack in C++, meaning everything from opening sockets to the web server to the tls crypto code to the sse/middleware layer of the framework. Quite literally, there is _ZERO_ externally used third-party code anywhere in the netpath. Performance is amazing, I can serve effectively ~600k full HTTPS requests per second on a single Skylake core.
How fast does it go when you do a few PostgreSQL queries per request?
Look at https://www.http-arena.com/. For raw throughput on keep-alive requests, low-level languages are going to win without a question. But once you put database roundtrip into the mix, the distance gets much smaller.
And I'm saying this as an author of another HTTP server in a low-level language.
Refer to the newest Talk Python podcast where a core CPython developer was told that Python is memory safe and his response was “is it?”.
At some point we need to be more sophisticated about this, our hardware is fundamentally unsafe, anything we build on it is fundamentally unsafe and there are degrees to which things are better or worse and that’s it. All that matters is the love, rigour and care you put into your work.
Proceed as you wish, a backend in C is valid a backend in LISP is valid.
It can get you most of the Smalltalk (Python/Ruby) conveniences with most of C's speed. In fact, if you do it really well you can leverage them together to get better than both. Simultaenously.
Doesn't mean that people don't manage to wield it in such a way as to get all the convenience of C combined with the performance of Python/Ruby. Which always baffles me. You .... did .... WAT?
To me the Right Thing™ here always seemed the obvious and simple thing to do, as in: just don't spend extra effort to mess it up and you'll be fine. YMMV.
Plug: my book gives fairly detailed instructions on how to achieve the positive combination. [1]
Other plug: Making it easier to get this right is the 2nd of the four stages of Objective-Smalltalk. [2][3]
[1] https://www.amazon.com/Cocoa-Objective-C-Performance-Tuning-...
[2] https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
[3] https://objective.st/
All hail TIMTOWTDI! :)
Note that PHP and Perl also had enough C code, and Apache/IIS plugins, with enough C and C++ extensions.
Now all those "who cares scripting languages" are getting JIT compilers, or being rewritten into Go and Rust.
Once I ditched the library idea and just coded to the spec things went much nicer lol it turned out to be a relatively normal socket coding project. Just hobby code tho.
Look at https://www.http-arena.com/. For raw throughput on keep-alive requests, low-level languages are going to win without a question. But once you put database roundtrip into the mix, the distance gets much smaller.
And I'm saying this as an author of another HTTP server in a low-level language.