hatefulheart
2 days ago
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.
networked
2 days ago
> 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
doublerabbit
2 days ago
> 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?
networked
2 days ago
If.
doublerabbit
2 days ago
Why couldn't it?
networked
2 days ago
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.
zbentley
2 days ago
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.
hatefulheart
2 days ago
Because he claims you cannot. Pretty much.
rfgplk
2 days ago
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.
mpweiher
2 days ago
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...
pjmlp
2 days ago
Ah, Web Objects!
zbentley
2 days ago
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.
mpweiher
2 days ago
> 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.
pjmlp
a day ago
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.
mpweiher
8 hours ago
> 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:
c_pointer = [container getPointer]
<munge on pointer>
[container doSomeMungingOnYourCData];
But yes, some people do insist on doing things the hard, slow, nasty way. They get punished.
thevillagechief
2 days ago
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.
lukaslalinsky
2 days ago
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.
nightfly
2 days ago
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
6031769
a day ago
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".
nightfly
a day ago
The assumptions I'm making here:
* Most sites/projects are internal to an organization
* Most public facing websites/apps/projects won't be successful
pjmlp
2 days ago
Or Go, OCaml, Haskell, Java, C#, D, Ada,....
freakynit
2 days ago
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.