Dear C folks… is it a good idea to write web backends in C? A honest question.

Besides that it's a lot of fun, seriously nope. Do you plan on using a framework for it?

I'd say yes, it's bad design, for the following reasons:

1. Memory management bugs being exposed to the world
2. Time to market. C stacks would take longer to develop for
3. Maintenance. More complicated stacks and more obscure stacks are harder to maintain.

A good C dev team might not worry too much however, but what happens when you need to replace engineers?

@retoor I will obviously have to…

@lungdart wow. Point 1 is exactly what I was preaching to my colleagues who wanted to write SQL queries in a client-side JavaScript. Exposing a Turing-complete (and thus unpatchable) language to the world.

Nginx is in C, and speed was one of the main design priorities. I've not heard that Nginx servers are being hacked left and right because memory management is too hard.

@Fast-Nop hmmm fair point too. But Pavel Sysoev and all the other people who joined later are unquestionably better programmers than I am 😅

@kiki Remember why Git is in C? Because Torvalds wanted to attract only contributors who think on raw byte level.

The main question is whether the speed of the backend is really that critical. I mean, avoiding dumb shit is perfectly valid in other languages as well, and that buys you most of the bang.

Sure, when you start cludging together shit like WP, with Gutenberg formatting slapped in as HTML comments in a database, then it's game over for speed anyway, and it wouldn't be fast even if ported to C.

Given how fast Hugo is, I'd probably consider Go over C for that use case.

@Fast-Nop I'm not saying that its impossible to prevent, I'm also not saying that doing a backend in a scripted language can't suffer from the same issues.

I'm saying that with all other things being equal, C developed apps will have more memory management bugs vs scripted apps, UP TO A POINT.

If you have a rock solid C team, you're fine. Just never let any of them move on, retire, or pass away, because that pool of talent is smaller than it ever was.

Im playing around with a C backend framework lately, my main reasons being that Im trying to prototype something that can run with a reasonable speed and throughput on a RPi3B or lower. Most solutions of interesting self hosted services are done in Node or PHP and It's just slow.

I mean obviously, low powered PC like the Rasp are gonna perform badly, but my area of Research is "do they have to, really?"

So far it seems extremely fast, close to 0ms responses on local network through a router serving currently only static content. Im interested to see these C backend frameworks with highly dynamic content eventually, so I can insult devs that write shit code that eats 2Gigs of memory to perform absolutely awfuly on anything slower that i5

If you're just a dev who happened to get that task, i'd say no.

If you're a C Wizard, who eats their meals in raw bytes, the answer is always yes.

Well, it's the rollercoaster of programming. 70s programmers lived by the byte because it was so scarce, it was a luxury they couldn't afford.

Nowadays, it's accepted to take 100 MBs of RAM just to serve a static file.

But I lived the beginnings of VR and ultra high resolution video, and we also had to get really creative to make shit run where they asked it to.

So, in the end, given the cost of 100 MB of RAM, I wouldn't bother. It doesn't make sense from a business PoV.

But for fun/learning? Absolutely. You'll come off smarter than when you went in. (And as lungdart said, you get to join the ever shrinking pool of people able to maintain what essentially runs 99% of things in the world)

Also, purists will hate me for it, but you can go with modern C++, get the same performance as C, and barely expose any mem management bugs with RAII and smart pointers.

Guys, about that memory management thing… what about rust then?

Pick your poison, I guess XD.

The main thing that really deters me from rust nowadays, versus c++, is that, in essence, and without indulging in their recent "direction" drama, Rust is not actually supported by any kind of standardization, which, business-wise, is a big red flag.

Then again, you mentioned C. C is a whole different beast than both C++ and Rust.

C++ has equal runtime performance as C because it enforces zero cost abstractions in the language and STL.

I think they strive to do the same in rust, but there's no actual mandate for it.

AFAIK, in rust, in order to do the same kind of magic C++ allows you to, you have to go unsafe anyway, which essentially voids any additional guarantee they might make.

This is straight from rust docs.

"Wrapping unsafe code in a safe abstraction prevents uses of unsafe from leaking out into all the places that you or your users might want to use the functionality implemented with unsafe code, because using a safe abstraction is safe."

This is my main gripe about Rust.

This is blatantly *false*.

Using a safe abstraction is *never* safe when it eventually calls unsafe code.

The whole point of unsafe is "things static analysis can't determine", so why do they think that because you use an abstraction with "safe" code it magically becomes safe?

You aren't adding any extra static analysis guarantees, just compile time sugar.

I hate void pointers so much 😂
GDb server crashes all the time. When debugger works， all info is hidden behind void pointers. Would not recommend.

@CoreFusionX The idea is, if you have, say, 10% unsafe code, then you only need to review these 10%. The compiler will do the other 90%. From that perspective, it makes sense.

@Fast-Nop

Yes, it does, and I know that.

However, rust fanboys tend to forget things like valgrind (which is what guarantees their so vaunted safety) also exist in C++.

So yeah, I'm all up for explicitly marking unsafe code (C# beat them to it, btw), but don't try to sell it as something it isn't.

@kiki rust is good, as long the libraries you use don't actually practice unsafe rust.

Most probably no

@kiki SQL queries in javascript??? I applaud that concerns separation 😬

@CoreFusionX and yes i agree, actually use the C++ tools on my rust binaries aswell, and some of the crates are no saints either. HOWEVER, the culprits that have memory leaks are almost always because of poorly written C/C++ dependencies, that these rust crates wrap, and otherwise due to ignorant use of unsafe rust.

@thebiochemic

Then you'd agree with me that the good and bad do not come from the language but from bad programmers.

You can not bash C/C++ for bad implementors just like I can not bash rust for bad documentos (or implementors, though wrapping something does not really mean implementor)

@CoreFusionX yeah,
yeah i guess that's true. However Languages make it particularly easy or hard to do certain types of mistakes. To be honest, i like C more than rust, but the reality is, that it is easy to do unsafe code in C. Simple things like forgetting a return, or forgetting to initialize a variable and shit like that.

@thebiochemic The latter are not valid arguments. Just switch on the compiler warnings and -Werror gets you pretty much the Rust behaviour in these examples - it won't even compile.

@Fast-Nop not true.

C Compilers don't have to warn you about a missed return for example. It's undefined behaviour. In rust there is no way to not return something if it needs to (unless you're actively using unsafe code blocks in rust, with which you would open a safety contract that you need to satisfy) or Panic

that's a difference.

@thebiochemic Yeah, the C standard doesn't specify what a compiler should warn about. However, that's how you use a C toolchain, with warnings enabled, and it does work.

Also, Rust doesn't even have a standard and instead is whatever the Rust compiler happens to do, so arguing with defined standards is a bit disingenuous. If you care about standards, you don't use Rust in the first place.

@Fast-Nop yeah i guess that's fair.