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.
> anything we build on it is fundamentally unsafe and there are degrees to which things are better or worse and that’s it.
This doesn't mean C is an equally valid choice for a web backend as Common Lisp when you care about development speed and don't want to get pwned. It's justified(ish) if you are Fossil SCM but much less so if you are a random website. When you need high performance, it's more justified, especially if it's 2006. When you can afford to use bindings for your C libraries, it's less. Etc.
To shift your perspective, replace C with x86-64 assembly.
AsmBB (https://board.asm32.info/) is undeniably a cool thing.
Is it valid to develop an e-commerce site the same way?
There is a general pattern of "there are degrees, so basically anything goes". It's important to recognize it and resist its siren song.
> The Sophisticate: “The world isn’t black and white. No one does pure good or pure bad. It’s all gray. Therefore, no one is better than anyone else.”
> The Zetet: “Knowing only gray, you conclude that all grays are the same shade. You mock the simplicity of the two-color view, yet you replace it with a one-color view . . .”
Even compared with C, assembly gives you minimal guardrails, which makes it harder to write correct programs at scale. An e-commerce web app is going to be a large program that's online and an attractive target for attackers. You will need more discipline, experience, and tooling to prevent bugs, including bugs only made possible by your choice of language. (For example, assembly opens up a category of control flow bugs that are prevented by structured control flow. Data corruption is easier because you don't work with named, scoped variables.)
It isn't a question of "could" but how likely you are to get good outcomes.
A big reason not to write enterprise web backends in raw C is that segfaults (the most common symptom of programmatic errors) abort the whole program. One person writes one bug, and when that bug is hit the whole backend crashes.
The risk of bugs goes up when lots of people (with different timelines/skill levels/expectations) are working on an enterprise codebase. Ergo, the risk of "entire backend vanished" crashes goes up over time. A huge benefit of HLLs is that they have a vastly reduced risk of whole-program-aborting bugs--even Erlang, with it's "let it crash" philosophy, is referring to letting the boundary of affected code within a larger program crash, not aborting every transaction/reinitializing all resources and restarting from scratch.
Things like CGI mitigate this a little bit by containing the blast radius to one request's handler (at a pretty severe complexity/performance/compute cost to things like shared connection pools/file handles/startup time), but they don't solve it. The same is true for things like autorestart services/orchestrators.
Sure, you can decline to abort in the event of a segfault, but that's .... ballsy, shall we say.
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]
Eh, if your Objective-C webservice segfaults due to someone not null-checking properly, all your requests/transactions get aborted and your program crashes. While Objective C (and C++ to some extent, depending on framework) do offer a lot of HLL conveniences over C, they still all have that pretty big downside.
On a very-few/very-skilled developer project, this might work. But on projects with large or changing teams, that downside bites hard.
Partially true, because ignoring messages to nil only works with Objective-C data types, any classical C style programming will segfault as in plain C.
Just like in C++, while there are high level abstractions that avoid traditional C memory corruption issues, there are always those that insist in sticking to the C subset.
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
A lot of the folks on hackernews have started to give me the stackoverflow vibes no-a-days... somehow such people think they own what others can and cannot use.
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.
Boatloads of http serving stuff at Google was (and probably still are) written in C++ when I was there. The web services part, though, not front-end, generally.
Things were shifting to Go gradually as I left though.
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.
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.
> anything we build on it is fundamentally unsafe and there are degrees to which things are better or worse and that’s it.
This doesn't mean C is an equally valid choice for a web backend as Common Lisp when you care about development speed and don't want to get pwned. It's justified(ish) if you are Fossil SCM but much less so if you are a random website. When you need high performance, it's more justified, especially if it's 2006. When you can afford to use bindings for your C libraries, it's less. Etc.
To shift your perspective, replace C with x86-64 assembly. AsmBB (https://board.asm32.info/) is undeniably a cool thing. Is it valid to develop an e-commerce site the same way?
There is a general pattern of "there are degrees, so basically anything goes". It's important to recognize it and resist its siren song.
> The Sophisticate: “The world isn’t black and white. No one does pure good or pure bad. It’s all gray. Therefore, no one is better than anyone else.”
> The Zetet: “Knowing only gray, you conclude that all grays are the same shade. You mock the simplicity of the two-color view, yet you replace it with a one-color view . . .”
> —Marc Stiegler, David’s Sling
https://www.greaterwrong.com/w/fallacy-of-gray
> Is it valid to develop an e-commerce site the same way?
Sure why not. If it can process my transaction cleanly and securely why not?
If.
Why couldn't it?
Even compared with C, assembly gives you minimal guardrails, which makes it harder to write correct programs at scale. An e-commerce web app is going to be a large program that's online and an attractive target for attackers. You will need more discipline, experience, and tooling to prevent bugs, including bugs only made possible by your choice of language. (For example, assembly opens up a category of control flow bugs that are prevented by structured control flow. Data corruption is easier because you don't work with named, scoped variables.)
It isn't a question of "could" but how likely you are to get good outcomes.
A big reason not to write enterprise web backends in raw C is that segfaults (the most common symptom of programmatic errors) abort the whole program. One person writes one bug, and when that bug is hit the whole backend crashes.
The risk of bugs goes up when lots of people (with different timelines/skill levels/expectations) are working on an enterprise codebase. Ergo, the risk of "entire backend vanished" crashes goes up over time. A huge benefit of HLLs is that they have a vastly reduced risk of whole-program-aborting bugs--even Erlang, with it's "let it crash" philosophy, is referring to letting the boundary of affected code within a larger program crash, not aborting every transaction/reinitializing all resources and restarting from scratch.
Things like CGI mitigate this a little bit by containing the blast radius to one request's handler (at a pretty severe complexity/performance/compute cost to things like shared connection pools/file handles/startup time), but they don't solve it. The same is true for things like autorestart services/orchestrators.
Sure, you can decline to abort in the event of a segfault, but that's .... ballsy, shall we say.
Because he claims you cannot. Pretty much.
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]
[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/
Ah, Web Objects!
Eh, if your Objective-C webservice segfaults due to someone not null-checking properly, all your requests/transactions get aborted and your program crashes. While Objective C (and C++ to some extent, depending on framework) do offer a lot of HLL conveniences over C, they still all have that pretty big downside.
On a very-few/very-skilled developer project, this might work. But on projects with large or changing teams, that downside bites hard.
> not null-checking properly,
Fortunately, the run-time does this for you: it ignores messages to nil.
And the framework provides container objects for "bags of bytes": NSData.
So it is actually surprisingly hard to dereference a null pointer, and surprisingly easy to avoid mechanically without being perfect.
Just make sure that you delegate any manipulation of raw data to methods of the object holding the data.
https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...
While it is certainly possible to circumvent this if you put your mind to it, it is remarkably safe in practice.
Partially true, because ignoring messages to nil only works with Objective-C data types, any classical C style programming will segfault as in plain C.
Just like in C++, while there are high level abstractions that avoid traditional C memory corruption issues, there are always those that insist in sticking to the C subset.
> any classical C style programming will segfault as in plain C.
As I wrote, you wrap those in an Objective-C container that manages that pointer, and delegate the C access to that container.
So not:
But rather: Which is, of course, how you should be doing things in OO style anyhow. So that works out just fine.But yes, some people do insist on doing things the hard, slow, nasty way. They get punished.
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.
Because that's simple, and quality doesn't matter?
performance ≠ quality
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
If you are writing something that will be used that infrequently then I'd suggest (at least in a web dev context) that you are not "most people".
The assumptions I'm making here:
* Most sites/projects are internal to an organization
* Most public facing websites/apps/projects won't be successful
Or Go, OCaml, Haskell, Java, C#, D, Ada,....
A lot of the folks on hackernews have started to give me the stackoverflow vibes no-a-days... somehow such people think they own what others can and cannot use.
I say fck u to them :mid-finger: emoji.
In case anyone missed it, there was an HN post about writing a web application in C using CGI a day or two ago.
https://news.ycombinator.com/item?id=50058528
(In this pseudo-resurgence of common sense, somebody ought to at least have a passing memory in mention, of perl, the OG CGI language ...)
All hail TIMTOWTDI! :)
Ahh, the ideas Perl let me inflict on the web before 2000.
Most of them were terrible. Many were insecure. Nearly all were written in total obfuscation, because who wrote Perl so other people could read it?
It was terrible.
It was glorious.
Hear ya. Yes, it was.-
(Both) :)
This reminds me a bit of when I implemented TodoMVC in C, though I used fcgi for that: https://github.com/julian-goldsmith/todomvc-c
Anyone brave enough to write a webapp in C++?
Yes, earned my living with that for most of my career. Would do again tomorrow.
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.
Boatloads of http serving stuff at Google was (and probably still are) written in C++ when I was there. The web services part, though, not front-end, generally.
Things were shifting to Go gradually as I left though.
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.
OkCupid did it back in the day...
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.
404
sure. https://substrata.info/
In a heartbeat.
[dead]