5 ms·

Important question: Why would anyone develop a web application in C? Typically web applications lean heavily on garbage collection and memory safety, because th

Important question: Why would anyone develop a web application in C? Typically web applications lean heavily on garbage collection and memory safety, because their bottlenecks are very rarely CPU/memory issues. The ROI on manually managing memory just isn't there for a typical web application.

warothia 2y ago
I could say speed, but the main reason for me is because it is fun. And I like to see what I can make C do. :D
- mst 2y ago
  "Because I can" remains an entirely legitimate reason for a hobby project. If anything, you've gone further along the "also (at least sort of) practical" scale than I expected. Given as mentioned elsewhere a per-request arena + bump allocator system, it might actually be -genuinely- practical (to the extent that writing application logic in C is at all ;) Bravo.
  - warothia 2y ago
    Thanks! Yes, an arena allocator for each request is on my todo list. Just didn’t get to implementing it yet. :D
- kaba0 2y ago
  The second point is absolutely fair and your project is very cool and impressive, but the speed one is misleading. I am fairly sure you actually leave a fair bit of performance on the table simply by how convoluted parallelism and async IO are in C, and something like Java might easily outperform it in standard CRUD backend use cases.
  - warothia 2y ago
    You’re absolutely right, I have not tried very hard to optimize for speed either yet. To comment was more directed at the fact most just say that “speed” is the main reason to use C, but for me it’s almost exclusively for the fun and “cool” factor.
SvenL 2y ago
On the other hand memory management in web applications is quite easy. Most of the stuff is only required for the lifetime of a request. Some stuff needs to be available the whole application life time.
- smt88 2y ago
  You can do this with other languages (C# for example) as well. Memory is so cheap, though, that most companies should spend their money on increasing memory rather than on paying programmers to optimize memory usage.
  - HexDecOctBin 2y ago
    Cheap for whom? American programmers with FAANG salaries, or an under-funded third world NGO?
    - kaba0 2y ago
      Both. My phone could easily serve thousands of concurrent users.
  - SvenL 2y ago
    Yes, for most use cases it doesn’t really matter which language is chosen. Regarding just spending more money on memory - I agree that it’s definitely cheaper but it’s not only about wasting bytes of memory. If the garbage collector has a lot of work to do it may also impact response time/throughput. And yes, C# did a pretty good job with implementing mechanisms for reducing allocations on a language level. This definitely helps to reduce garbage collection.
  - marginalia_nu 2y ago
    I don't think memory usage is the problem, but rather allocation costs and memory layout, i.e. performance. Serving web traffic simply isn't a very memory hungry task.
Aurornis 2y ago
Lightweight web frameworks are great for embedded applications.
- gwbas1c 2y ago
  Take a few minutes to read through the use case. This isn't something that I would use for an embedded application. The fact that it allows uploading a compiled binary implies that it's for developing a web application in C, as opposed to merely adding a web endpoint to an embedded application.
koito17 2y ago
Back then, C was one of a few viable choices. The original implementation of the 2ch BBS was written in C.[0] Later revisions used Perl. Between 1998 and 2001, the site was a widely-used BBS and written in C. [0] https://github.com/nekoruri/readcgi https://github.com/nekoruri/readcgi
williamcotton 2y ago
> The ROI on manually managing memory just isn't there for a typical web application. You can use a per-request memory arena built with a simple bump allocator and then free the entire block when the request has been handled.
- kaba0 2y ago
  Still, why would I want to write C? Then use a script language with similar memory semantics, PHP started out exactly that way, if I'm not mistaken.
_gabe_ 2y ago
I’m all for using C for native development (and because I find it fun to work in occasionally), but I agree with your sentiment here. Not only do you have to manage memory manually, but you also have to do a lot more work for basic string manipulation which is the vast majority of web work. I would much rather work with a language with built in support for string manipulation and well known 3rd party libraries with good ergonomics for working with JSON, which a lot of your APIs will most likely be using.
wwweston 2y ago
Speaking as someone who has done this back in the early wild days of the web: * if what you're vending is the software instead of the service (not what people usually do now, but there was a time), then this approach does provide for some obfuscation of IP and various secrets. * for some demand/resource profiles, CPU & memory issues are a lot easier to run into. The one I experienced with this project was targeting a serious e-commerce product to the context of 20-30 year old shared hosting environments (again, not what people would do now), but there may be different situational niches today. * familiarity. Sometimes you use what you know. And in the late 90s today's most popular web languages were still years away from being the convenient platform they'd become. The other popular options were Perl, maybe Java, possibly ColdFusion/VB/PHP. That said, you're correct: memory management was a pain, and by 2005 or so it was pretty clear that programmer cycles were as or more valuable than CPU and respectable frameworks were starting to coalesce in languages much better suited for string manipulation, so the ROI was not great. And of course, today you have other systems languages available like Go and Rust...
- smt88 2y ago
  > if what you're vending is the software instead of the service (not what people usually do now, but there was a time) I'm very curious what this means. Can you give an example?
  - Philpax 2y ago
    Giving the client the executable to run, not running it for them. This means you can't hide the artifact from the client; for an interpreted language, this means recovery of the source code would be much easier than with a compiled output. That being said, it's still possible to reverse engineer the code; it just makes it harder.
  - dsp_person 2y ago
    You could also run a limited demo of your desktop application in a browser, where people have to pay to get access to the full thing.
mariocesar 2y ago
The title "Hobby Project" makes the point right from the beginning
lelanthran 2y ago
> Typically web applications lean heavily on garbage collection and memory safety, because their bottlenecks are very rarely CPU/memory issues. I dunno about this assertion. Maybe it seems like the bottleneck is rarely CPU/memory when you're throwing 1GB RAM + dedicated instance at a webapp, but, for example Jenkins absolutely trashes any 1GB RAM instance because it runs out of RAM and/or CPU. My homegrown builder/runner CI/CD system, running the same `go build/test` commands, the same `git checkout` commands etc, written in C, peaks at a mere 60MB of RAM usage. I feel we are collectively underestimating just how much extra RAM is needed the popular languages that run a typical GC. [EDIT: I no longer even use my simple C app - I find a `make` cronjob for every 2m uses even less RAM, because there is no web interface anymore, I ssh into that machine to add new projects to the makefile]
cv5005 2y ago
Global warming. These days it should be considered immoral to write software that uses inefficient languages/runtimes/abstractions, we simply cannot afford to waste energy doing useless computations anymore.

warothia 2y ago

I could say speed, but the main reason for me is because it is fun. And I like to see what I can make C do. :D

mst 2y ago
"Because I can" remains an entirely legitimate reason for a hobby project. If anything, you've gone further along the "also (at least sort of) practical" scale than I expected. Given as mentioned elsewhere a per-request arena + bump allocator system, it might actually be -genuinely- practical (to the extent that writing application logic in C is at all ;) Bravo.
- warothia 2y ago
  Thanks! Yes, an arena allocator for each request is on my todo list. Just didn’t get to implementing it yet. :D
kaba0 2y ago
The second point is absolutely fair and your project is very cool and impressive, but the speed one is misleading. I am fairly sure you actually leave a fair bit of performance on the table simply by how convoluted parallelism and async IO are in C, and something like Java might easily outperform it in standard CRUD backend use cases.
- warothia 2y ago
  You’re absolutely right, I have not tried very hard to optimize for speed either yet. To comment was more directed at the fact most just say that “speed” is the main reason to use C, but for me it’s almost exclusively for the fun and “cool” factor.

SvenL 2y ago

On the other hand memory management in web applications is quite easy. Most of the stuff is only required for the lifetime of a request. Some stuff needs to be available the whole application life time.

smt88 2y ago
You can do this with other languages (C# for example) as well. Memory is so cheap, though, that most companies should spend their money on increasing memory rather than on paying programmers to optimize memory usage.
- HexDecOctBin 2y ago
  Cheap for whom? American programmers with FAANG salaries, or an under-funded third world NGO?
  - kaba0 2y ago
    Both. My phone could easily serve thousands of concurrent users.
- SvenL 2y ago
  Yes, for most use cases it doesn’t really matter which language is chosen. Regarding just spending more money on memory - I agree that it’s definitely cheaper but it’s not only about wasting bytes of memory. If the garbage collector has a lot of work to do it may also impact response time/throughput. And yes, C# did a pretty good job with implementing mechanisms for reducing allocations on a language level. This definitely helps to reduce garbage collection.
- marginalia_nu 2y ago
  I don't think memory usage is the problem, but rather allocation costs and memory layout, i.e. performance. Serving web traffic simply isn't a very memory hungry task.

Aurornis 2y ago

Lightweight web frameworks are great for embedded applications.

gwbas1c 2y ago
Take a few minutes to read through the use case. This isn't something that I would use for an embedded application. The fact that it allows uploading a compiled binary implies that it's for developing a web application in C, as opposed to merely adding a web endpoint to an embedded application.

koito17 2y ago

Back then, C was one of a few viable choices. The original implementation of the 2ch BBS was written in C.[0] Later revisions used Perl. Between 1998 and 2001, the site was a widely-used BBS and written in C. [0] https://github.com/nekoruri/readcgi https://github.com/nekoruri/readcgi

williamcotton 2y ago

> The ROI on manually managing memory just isn't there for a typical web application. You can use a per-request memory arena built with a simple bump allocator and then free the entire block when the request has been handled.

kaba0 2y ago
Still, why would I want to write C? Then use a script language with similar memory semantics, PHP started out exactly that way, if I'm not mistaken.

_gabe_ 2y ago

I’m all for using C for native development (and because I find it fun to work in occasionally), but I agree with your sentiment here. Not only do you have to manage memory manually, but you also have to do a lot more work for basic string manipulation which is the vast majority of web work. I would much rather work with a language with built in support for string manipulation and well known 3rd party libraries with good ergonomics for working with JSON, which a lot of your APIs will most likely be using.

wwweston 2y ago

Speaking as someone who has done this back in the early wild days of the web: * if what you're vending is the software instead of the service (not what people usually do now, but there was a time), then this approach does provide for some obfuscation of IP and various secrets. * for some demand/resource profiles, CPU & memory issues are a lot easier to run into. The one I experienced with this project was targeting a serious e-commerce product to the context of 20-30 year old shared hosting environments (again, not what people would do now), but there may be different situational niches today. * familiarity. Sometimes you use what you know. And in the late 90s today's most popular web languages were still years away from being the convenient platform they'd become. The other popular options were Perl, maybe Java, possibly ColdFusion/VB/PHP. That said, you're correct: memory management was a pain, and by 2005 or so it was pretty clear that programmer cycles were as or more valuable than CPU and respectable frameworks were starting to coalesce in languages much better suited for string manipulation, so the ROI was not great. And of course, today you have other systems languages available like Go and Rust...

smt88 2y ago
> if what you're vending is the software instead of the service (not what people usually do now, but there was a time) I'm very curious what this means. Can you give an example?
- Philpax 2y ago
  Giving the client the executable to run, not running it for them. This means you can't hide the artifact from the client; for an interpreted language, this means recovery of the source code would be much easier than with a compiled output. That being said, it's still possible to reverse engineer the code; it just makes it harder.
- dsp_person 2y ago
  You could also run a limited demo of your desktop application in a browser, where people have to pay to get access to the full thing.

mariocesar 2y ago

The title "Hobby Project" makes the point right from the beginning

lelanthran 2y ago

> Typically web applications lean heavily on garbage collection and memory safety, because their bottlenecks are very rarely CPU/memory issues. I dunno about this assertion. Maybe it seems like the bottleneck is rarely CPU/memory when you're throwing 1GB RAM + dedicated instance at a webapp, but, for example Jenkins absolutely trashes any 1GB RAM instance because it runs out of RAM and/or CPU. My homegrown builder/runner CI/CD system, running the same `go build/test` commands, the same `git checkout` commands etc, written in C, peaks at a mere 60MB of RAM usage. I feel we are collectively underestimating just how much extra RAM is needed the popular languages that run a typical GC. [EDIT: I no longer even use my simple C app - I find a `make` cronjob for every 2m uses even less RAM, because there is no web interface anymore, I ssh into that machine to add new projects to the makefile]

cv5005 2y ago

Global warming. These days it should be considered immoral to write software that uses inefficient languages/runtimes/abstractions, we simply cannot afford to waste energy doing useless computations anymore.