Live data from Hacker News

Web development in C: Crazy?

medium.com

101–110 of 213 posts

Re: Web development in C: Crazy?

#101

Earlier quoted context omitted.

Seems like the rules for C web development are the same as for any other language: don't trust user input, and delegate the sanitization to vetted library functions. It's not like it's 1991 and you have to use plain arrays and strcmp; there are really good, safe libraries for these things. That said, doing web development in a language with neither a REPL nor built-in unicode support sounds like a Bad Time.

Still an order of magnitude easier not to shoot yourself in the foot in most higher level language. Pretty sure you still have to use plain arrays and strcmp, what are these "safe" libraries you were going to use? Unless we are talking about C++ here? Also C supports unicode fine (to the extent it supports strings) and REPL can't hardly be considered a requirement for web development considering Java, .NET and PHP* d…

For strcmp, the safer strncmp version?

Also you should compile your app with apparmor and run it under grsecurity.

REPL like behaviour you can get with gdb. :)

Re: Web development in C: Crazy?

#102
post #97

Earlier quoted context omitted.

Seems like the rules for C web development are the same as for any other language: don't trust user input, and delegate the sanitization to vetted library functions. It's not like it's 1991 and you have to use plain arrays and strcmp; there are really good, safe libraries for these things. That said, doing web development in a language with neither a REPL nor built-in unicode support sounds like a Bad Time.

You mean like this? https://github.com/tyler/Bogart/blob/master/bogart.c#L53 I'm sure nothing could possibly go wrong there...

To be fair, it looks like a "get it working" proof of concept, but I certainly wouldn't take that into production :)

Re: Web development in C: Crazy?

#103

WHYYYYYYYYY No, seriously, why ? As far as I can tell, his entire argument is "web development in C is terrible and limiting, but not as quite as terrible and limiting as you might think." I guess that's good news if terrorists are forcing you to write websites in C, but I don't see even an attempt at explaining why you would choose to do this.

Maybe your problem is CPU-bound. Maybe there are good C libraries that solve your problem. Maybe you just want to learn C better. Maybe you have latency limits you need to work within. Maybe you just want to be contrary. Sometimes "why not" is worth more than "why."

> Maybe your problem is CPU-bound. Maybe you have latency limits you need to work within.

Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.

> Maybe there are good C libraries that solve your problem

Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C".

> Maybe you just want to learn C better.

If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).

Re: Web development in C: Crazy?

#104
Sure, cool stuff and probably great fun doing it.

However what matters in web development is not performance, nor that it is bug free and not even security. All of those things can fixed one way or the other on the server with more hacks.

The one thing that matters is speed of development, that is why PHP rules so hard.

"Let's argue about whether Haskell or Clojure is better while somebody else ships products using PHP and duct tape."

https://twitter.com/agentdero/status/174965036928868352

Re: Web development in C: Crazy?

#105
post #85

Earlier quoted context omitted.

C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for perf…

> C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. This is an implementation issue. Nothing prevents a compiler vendor to offer the same capabilities to their language compilers. Vectorization is not part of ANSI/ISO C or ANSI/ISO C++. For the time being, do you want vectorization in Go? Write a…

It's an implementation issue that matters if you're writing a system that needs to offer high performance today.

Regarding writing assembly - that's fine, you could also write a routine in C and call it. The thrust of my comment is that it is untrue to argue that native Go and Java match the performance of C/C++. They don't. They might in the future.

Re: Web development in C: Crazy?

#106

There are hardly any benefits in writing your web app in C ove r Java or Go. That 1% speed increase is nothing compared to the huge amount network wait these apps will be doing. If you really consider it, what 95% of people write these days is glue between various services, and the parts that do matter, where you need the most performance, are already written in C. The reason why Redis, MongoDB and Postgres have good…

C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for perf…

Modern JVMs do support SIMD vectorisation now and I've seen at least one example where JVM outperformed GCC 4.5 in loop vectorisation by 2x. There is no reason JIT compilers cannot do all the same SIMD optimisations that static compilers do.

If you want really top performance for non-trivial cases, e.g. matrix multiplication, I guess you need to probably vectorise by hand and go down right to assembly level.

Re: Web development in C: Crazy?

#107
post #80
post #20

Earlier quoted context omitted.

I once wrote a website (a search engine for a specific set of websites) in C. It actually worked, once I spend 20 hours in valgrind. I've grown since then, in two important ways. First, I'd probably do a better job now, and not have to spend any time in valgrind at all (I still use C quite frequently). Second, I'd never, ever, try to pull that stunt again.

> It actually worked, once I spend 20 hours in valgrind Thia is exactly the main problem with C. You need to rely on tolling outside the language to be able to write safer code. While languages like Ada and Modula-2 and their descendents, offer the same hardware capabilities as C with stronger type checking.

We use C# which allows you to write safe code. However, people still manage to fuck it up at an implementation level often enough for it to cause high risk problems.

Re: Web development in C: Crazy?

#108
post #85

Earlier quoted context omitted.

> C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. This is an implementation issue. Nothing prevents a compiler vendor to offer the same capabilities to their language compilers. Vectorization is not part of ANSI/ISO C or ANSI/ISO C++. For the time being, do you want vectorization in Go? Write a…

It's an implementation issue that matters if you're writing a system that needs to offer high performance today. Regarding writing assembly - that's fine, you could also write a routine in C and call it. The thrust of my comment is that it is untrue to argue that native Go and Java match the performance of C/C++. They don't. They might in the future.

In the majority of cases they do. For a few minor cases where they don't (but they are close to) you can drop to C or assembly.

Re: Web development in C: Crazy?

#109
post #85

Earlier quoted context omitted.

C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for perf…

> C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up. This is an implementation issue. Nothing prevents a compiler vendor to offer the same capabilities to their language compilers. Vectorization is not part of ANSI/ISO C or ANSI/ISO C++. For the time being, do you want vectorization in Go? Write a…

sumatra is for parallelizing mainly on GPU, not for SIMD - current C/C++ compilers neither do that. Java has SIMD support for quite a long while now, probably since Java 6 or even earlier and generally C-like Java code using raw arrays and primitives is as-fast-as-C these days. I'd be more afraid of lack of true value types in Java. This one thing makes C still a better choice for high performance stuff.

Re: Web development in C: Crazy?

#110
No, not crazy. Just really tedious. I've been there and even webdev in C++ was magnitudes more comfortable than webdev in C.

But webdev is a solved and trivial problem. More so it is an I/O-bound problem. So you can use the slowest language in the world as long as it boosts your productivity or makes your life super easy. (Sure, there are edge cases but 99.9% of webdevs never will be in the situation of having thousands of requests a second.)

Post reply on HN