5 ms·

Writing a web application in C sounds like a good trigger for an utterance from the Jargon File: "You could do that, but that'd be like kicking dead whales down

Writing a web application in C sounds like a good trigger for an utterance from the Jargon File: "You could do that, but that'd be like kicking dead whales down the beach." We've advanced the state of the art quite a bit with dramatically more expressive languages than C that are sufficiently efficient in terms of memory and CPU. This is especially true when communications are occurring over HTTP and not direct socket-to-socket comms. Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...? I didn't miss C++, it just seems a worse alternative than C.

nulltype 11y ago
Thank god it's written in C and not C++
- CountSessine 11y ago
  Yeah. Thank God. I love broken string implementationsssssdd##%^$*$#@@#$%$$$###ludvik^0knox^0shamen^0password^0pass^012345^0qwerty^0dreamdevil^0 C is just awesome.
  - nulltype 11y ago
    We got that solved. https://github.com/antirez/sds https://github.com/antirez/sds
    - pjmlp 11y ago
      Except it isn't neither part of ANSI C, nor is used by any relevant third party C library, but it is solved....
    - CountSessine 11y ago
      This seems to be an adaptation of the earlier SafeStr lib. SafeStr is nice except that the C community is still too busy arguing about their awful lstr* and str*_s functions to take any notice and incorporate something genuinely secure like SafeStr into the standard lib. And the NVD just keeps growing... So... you guys added something random and silly like <complex.h> to the standard, but still couldn't get around to a working string implementation? OK. Well, good luck with all that. Not solved yet.
      - faragon 11y ago
        Easy strings for C, with Unicode support (and as fast as std::string): https://github.com/faragon/libsrt https://github.com/faragon/libsrt
        CountSessine 11y ago
        libsrt, sds, SafeStr... How many times will this problem be solved independently before something like this makes it into the standard lib? Libsrt looks nice, but if you can't use it to interface to libraries that use the same types, you're still futzing around with char buffers. What does Kore use? libsrt? Let's have a look at how you're supposed to program a web app in its examples: int serve_file_upload(struct http_request *req) { int r; u_int8_t *d; struct kore_buf *b; u_int32_t len; char *name, buf[BUFSIZ]; b = kore_buf_create(asset_len_upload_html); kore_buf_append(b, asset_upload_html, asset_len_upload_html); if (req->method == HTTP_METHOD_POST) { http_populate_multipart_form(req, &r); if (http_argument_get_string("firstname", &name, &len)) { kore_buf_replace_string(b, "$firstname$", name, len); } else { kore_buf_replace_string(b, "$firstname$", NULL, 0); } if (http_file_lookup(req, "file", &name, &d, &len)) { (void)snprintf(buf, sizeof(buf), "%s is %d bytes", name, len); kore_buf_replace_string(b, "$upload$", buf, strlen(buf)); } else { kore_buf_replace_string(b, "$upload$", NULL, 0); } } else { kore_buf_replace_string(b, "$upload$", NULL, 0); kore_buf_replace_string(b, "$firstname$", NULL, 0); } d = kore_buf_release(b, &len); http_response_header(req, "content-type", "text/html"); http_response(req, 200, d, len); kore_mem_free(d); return (KORE_RESULT_OK); } Uh oh. So Kore invented yet another safe string/buf type? Why didn't they use libsrt? What's all this kore_buf stuff? Strings in C are NOT a solved problem. They're a hot mess.
        faragon 11y ago
        Yes, Kore don't use libsrt, although you could use it in your Kore user-modules (not all services are going to be trivial operations). And I agree, C strings is far from being a solved problem. In the case of libsrt strings, in addition to have embedded length (fast concatenation, search, etc.), it does support UTF-8 operations, include case conversion, without requiring OS support (i.e. without "locale", nor using custom hash tables, but in-code efficient hardwired character range selection), and most typical string operations. P.S. Before implementing libsrt strings I did a wide study of many string and generic C libraries, implementing the best from all, and adding things that were not still covered (I'll investigate the Kore string/buffer implementation, too): https://github.com/faragon/libsrt/blob/master/doc/references.md https://github.com/faragon/libsrt/blob/master/doc/references...
  - sdevlin 11y ago
    You're breaking the tables.
perdunov 11y ago
> I didn't miss C++, it just seems a worse alternative than C. This is such a retarded opinion. A person expressing it probably doesn't know shit about C++ or just plainly an idiot.
vidarh 11y ago
> Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...? Because C runs pretty much anywhere? There are plenty of platforms where C is available where I doubt you'd find any of the others above (e.g. C64; yes there are C compilers for them; yes, I'm mentioning it tongue in cheek) Because you can generate small, compact static executables? E.g. I used to write network monitoring software and an accompanying SNMP server for a system with 4MB RAM and 4MB flash, the latter of which had to include the Linux kernel and a shell on top of the application in question. The system was so limited we did not run a normal init, and couldn't fit bash - instead we ended up running ash as the init... There are plenty of use-cases where "web application" == "user interface for a tiny embedded platform".
- snarfy 11y ago
  > Because C runs pretty much anywhere? I always hear this argument, but as time has progressed, for better or worse 'anywhere' has become a much smaller target. If your language runs on Intel and ARM then it's good enough. There are a lot of reasons I might choose C for a project, but 'run anywhere' is not one of them.
  - aninteger 11y ago
    I'd say Intel, ARM, Power, and Sparc is good enough.
xamuel 11y ago
C is a good solution for things like realtime multiplayer with lots of state, lots of side effects, etc. A lot of the modern abstractions actually get in the way, for example: * List traversal order matters a lot when it's something like a list of monsters getting struck by a spell and the spell has complicated side effects. Brushing it under the rug with abstract iterators or functional Array.map's is a recipe for not knowing how your own game works. * Realtime is an illusion, it really means "fast turn-based", you don't want players with fast connections to get an advantage by spamming commands and having them executed the instant they're received. You want to queue commands and execute them fairly at regular pulses. So much for all your abstract events infrastructure!! * Certain object-oriented idioms become eye-rollingly silly when your application actually involves _objects_ (in the in-game sense). Suppose it's a game where players build in-game factories, suddenly the old "FactoryFactory" joke just got a million times worse. I'm not saying C is the best for those sorts of applications, but it's certainly not bad, and a lot of modern language features just aren't appropriate.
csomar 11y ago
Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...? C and Rust are not in the same play field of Ruby, Python or PHP. These languages are typed, compiled and MUCH faster. You'll obviously build 99% of your application in Ruby, but you might need C or Rust for high-volume calculations. An example that happened to me a few weeks ago. Scaling a financial application to make millions of calculations. The core App is made with PHP, and the difference between 0.1sec and 0.000764sec gets important here.

nulltype 11y ago

Thank god it's written in C and not C++

CountSessine 11y ago
Yeah. Thank God. I love broken string implementationsssssdd##%^$*$#@@#$%$$$###ludvik^0knox^0shamen^0password^0pass^012345^0qwerty^0dreamdevil^0 C is just awesome.
- nulltype 11y ago
  We got that solved. https://github.com/antirez/sds https://github.com/antirez/sds
  - pjmlp 11y ago
    Except it isn't neither part of ANSI C, nor is used by any relevant third party C library, but it is solved....
  - CountSessine 11y ago
    This seems to be an adaptation of the earlier SafeStr lib. SafeStr is nice except that the C community is still too busy arguing about their awful lstr* and str*_s functions to take any notice and incorporate something genuinely secure like SafeStr into the standard lib. And the NVD just keeps growing... So... you guys added something random and silly like <complex.h> to the standard, but still couldn't get around to a working string implementation? OK. Well, good luck with all that. Not solved yet.
    - faragon 11y ago
      Easy strings for C, with Unicode support (and as fast as std::string): https://github.com/faragon/libsrt https://github.com/faragon/libsrt
      - CountSessine 11y ago
        libsrt, sds, SafeStr... How many times will this problem be solved independently before something like this makes it into the standard lib? Libsrt looks nice, but if you can't use it to interface to libraries that use the same types, you're still futzing around with char buffers. What does Kore use? libsrt? Let's have a look at how you're supposed to program a web app in its examples: int serve_file_upload(struct http_request *req) { int r; u_int8_t *d; struct kore_buf *b; u_int32_t len; char *name, buf[BUFSIZ]; b = kore_buf_create(asset_len_upload_html); kore_buf_append(b, asset_upload_html, asset_len_upload_html); if (req->method == HTTP_METHOD_POST) { http_populate_multipart_form(req, &r); if (http_argument_get_string("firstname", &name, &len)) { kore_buf_replace_string(b, "$firstname$", name, len); } else { kore_buf_replace_string(b, "$firstname$", NULL, 0); } if (http_file_lookup(req, "file", &name, &d, &len)) { (void)snprintf(buf, sizeof(buf), "%s is %d bytes", name, len); kore_buf_replace_string(b, "$upload$", buf, strlen(buf)); } else { kore_buf_replace_string(b, "$upload$", NULL, 0); } } else { kore_buf_replace_string(b, "$upload$", NULL, 0); kore_buf_replace_string(b, "$firstname$", NULL, 0); } d = kore_buf_release(b, &len); http_response_header(req, "content-type", "text/html"); http_response(req, 200, d, len); kore_mem_free(d); return (KORE_RESULT_OK); } Uh oh. So Kore invented yet another safe string/buf type? Why didn't they use libsrt? What's all this kore_buf stuff? Strings in C are NOT a solved problem. They're a hot mess.
        faragon 11y ago
        Yes, Kore don't use libsrt, although you could use it in your Kore user-modules (not all services are going to be trivial operations). And I agree, C strings is far from being a solved problem. In the case of libsrt strings, in addition to have embedded length (fast concatenation, search, etc.), it does support UTF-8 operations, include case conversion, without requiring OS support (i.e. without "locale", nor using custom hash tables, but in-code efficient hardwired character range selection), and most typical string operations. P.S. Before implementing libsrt strings I did a wide study of many string and generic C libraries, implementing the best from all, and adding things that were not still covered (I'll investigate the Kore string/buffer implementation, too): https://github.com/faragon/libsrt/blob/master/doc/references.md https://github.com/faragon/libsrt/blob/master/doc/references...
- sdevlin 11y ago
  You're breaking the tables.

perdunov 11y ago

> I didn't miss C++, it just seems a worse alternative than C. This is such a retarded opinion. A person expressing it probably doesn't know shit about C++ or just plainly an idiot.

vidarh 11y ago

> Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...? Because C runs pretty much anywhere? There are plenty of platforms where C is available where I doubt you'd find any of the others above (e.g. C64; yes there are C compilers for them; yes, I'm mentioning it tongue in cheek) Because you can generate small, compact static executables? E.g. I used to write network monitoring software and an accompanying SNMP server for a system with 4MB RAM and 4MB flash, the latter of which had to include the Linux kernel and a shell on top of the application in question. The system was so limited we did not run a normal init, and couldn't fit bash - instead we ended up running ash as the init... There are plenty of use-cases where "web application" == "user interface for a tiny embedded platform".

snarfy 11y ago
> Because C runs pretty much anywhere? I always hear this argument, but as time has progressed, for better or worse 'anywhere' has become a much smaller target. If your language runs on Intel and ARM then it's good enough. There are a lot of reasons I might choose C for a project, but 'run anywhere' is not one of them.
- aninteger 11y ago
  I'd say Intel, ARM, Power, and Sparc is good enough.

xamuel 11y ago

C is a good solution for things like realtime multiplayer with lots of state, lots of side effects, etc. A lot of the modern abstractions actually get in the way, for example: * List traversal order matters a lot when it's something like a list of monsters getting struck by a spell and the spell has complicated side effects. Brushing it under the rug with abstract iterators or functional Array.map's is a recipe for not knowing how your own game works. * Realtime is an illusion, it really means "fast turn-based", you don't want players with fast connections to get an advantage by spamming commands and having them executed the instant they're received. You want to queue commands and execute them fairly at regular pulses. So much for all your abstract events infrastructure!! * Certain object-oriented idioms become eye-rollingly silly when your application actually involves _objects_ (in the in-game sense). Suppose it's a game where players build in-game factories, suddenly the old "FactoryFactory" joke just got a million times worse. I'm not saying C is the best for those sorts of applications, but it's certainly not bad, and a lot of modern language features just aren't appropriate.

csomar 11y ago

Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...? C and Rust are not in the same play field of Ruby, Python or PHP. These languages are typed, compiled and MUCH faster. You'll obviously build 99% of your application in Ruby, but you might need C or Rust for high-volume calculations. An example that happened to me a few weeks ago. Scaling a financial application to make millions of calculations. The core App is made with PHP, and the difference between 0.1sec and 0.000764sec gets important here.