Pourquoi n'utilisez-vous pas le C pour vos applications web ?

Question

Je jetais un coup d'oeil à différents serveurs web ce matin quand je suis tombé sur G-WAN . D'après ce que j'ai compris, il s'agit d'un serveur web écrit en C et vous devez l'utiliser en écrivant vos sites web/webapps en C. Un avantage évident est la vitesse, comme le suggère le site G-WAN.

Cependant, sur les forums, le créateur de G-WAN a demandé pourquoi ne pas utiliser le C pour les applications web et je ne peux pas penser à une seule raison en dehors de sa difficulté (pour moi en tout cas, je suis un novice en matière de C). Il doit y avoir d'autres raisons pour lesquelles nous utilisons tous PHP, Python, Ruby, etc. en dehors du fait qu'il est facile de développer dans ces langages. Je ne vois pas cela comme une bonne raison.

Alors je vous pose la question : Pourquoi n'utilisez-vous pas le C pour vos applications web ?

Answer 1

Il faut beaucoup de soin pour obtenir un programme C correct et sécurisé. Ce soin signifie que vous devez faire appel à des personnes très compétentes pour écrire vos programmes. Cela signifie que vous payez plus cher.

De plus, le C n'a pas l'avantage de pouvoir puiser dans une énorme bibliothèque standard de fonctionnalités, comme c'est le cas pour .NET (et les autres grandes plates-formes centrées sur le Web). Vous pouvez donc être amené à acheter des composants, à effectuer des opérations d'interopérabilité ou à développer votre propre fonctionnalité qui est fournie "gratuitement" avec un langage plus, disons, "centré sur le Web" comme PHP, C#, Ruby ou autre. Cela signifie que vous payez plus.

Ajoutez à cela le fait que la vitesse de calcul en mode single-thread n'est pas si importante sur le web. Si vous avez besoin d'une plus grande évolutivité, la plupart des organisations peuvent, d'un point de vue économique, se contenter d'ajouter des cœurs au problème et s'en sortir. Ce n'est pas vrai pour tout le monde, bien sûr. J'imagine que le cœur du moteur de Google est écrit en C ou dans un langage similaire, non seulement pour la vitesse, mais aussi pour économiser de l'argent sur les coûts d'énergie.

Answer 2

Hum...

Il semble que je sois un peu en retard dans cette discussion - mais je viens juste de la découvrir. Et je vous suis reconnaissant à tous pour vos nombreuses contributions.

Je suis l'auteur du G-WAN, ce qui indique clairement que j'ai sérieusement travaillé sur le sujet : G-WAN est à la fois plus rapide que tous les autres serveurs Web (sans traitement). et tous les autres serveurs d'applications Web (tout traitement que vous pouvez imaginer).

Oui, l'ANSI C a également permis de traiter davantage de contenu statique - avec des processeurs moins puissants (l'ANSI C ne sert pas uniquement à faire voler les contenus dynamiques).

D'ailleurs, G-WAN utilise des scripts en C (pas besoin de compilateur et de linker en C) donc le cycle/retard de compilation/liaison n'existe pas.

En comparant le G-WAN à .NET Java et PHP, j'ai écrit similaire dans les 4 langues : http://gwan.ch/source/

Et, à mon grand désarroi, les langages de script modernes étaient pas plus facile à utiliser.

Une partie du travail qui est particulièrement frustrante est de chercher désespérément pour trouver l'appel API "magique" qui fera ce que vous voulez faire.

Réfléchissez à la manière de faire des "milliers de jolis" :

C#

String.Format("{0:n}"...

Java

new DecimalFormat("0.00"); ...

PHP

number_format($amount, 2); ...

ANSI C

sprintf("%'.2f", amount);

Les "..." signifient qu'une certaine pré-configuration, ou post-traitement, est nécessaire. Le C ANSI est clairement plus facile à utiliser et à mémoriser.

Lorsque PHP compte plus de 5900 appels d'API (C# et Java ne sont pas loin), trouver l'API la plus appropriée est une tâche difficile. droite L'appel API est un défi en soi. Le temps perdu pour trouver cela (et ensuite pour trouver à quel point l'appel de l indigène L'appel API est implémenté), le temps d'apprendre à cœur ouvert pour la prochaine fois que vous en aurez besoin, tout ce temps vous prive du temps nécessaire pour résoudre vos problèmes d'application.

J'ai lu (ci-dessus) que le PHP est plus concis que le C ANSI ? Pourquoi alors utiliser "//:: this is a comment ::" plutôt que "// this is a comment" ? Pourquoi avoir une syntaxe "pretty thousands" aussi stupidement complexe ?

L'autre argument habituel est que Java et ses semblables fournissent des appels dédiés aux applications Web.

Je n'ai pas réussi à trouver quelque chose pour échapper au HTML en Java, alors j'ai écrit ma propre version :

  // all litteral strings provided by a client must be escaped this way
  // if you inject them into an HTML page
  public static String escape_html(String Name) {
      int len = Name.length();
      StringBuffer sb = new StringBuffer(len);
      boolean lastWasBlankChar = false;
      int c;

      for(int i=0; i<len; i++) {
          c = Name.charAt(i);
          if(c == ' ')  sb.append("&#32;");  else
          if(c == '"')  sb.append("&quot;"); else
          if(c == '&')  sb.append("&amp;");  else
          if(c == '<')  sb.append("&lt;");   else
          if(c == '>')  sb.append("&gt;");   else
          if(c == '\n') sb.append("&lt;br/&gt;"); else {
             c = c&0xffff; // unicode
             if(c < 32 || c > 127) {
                sb.append("&#");
                sb.append(new Integer(c).toString());
                sb.append(';');
             } else
                sb.append(c);
          }
      }
      return sb.toString();
      //szName = sb.toString();
  }

Pensez-vous vraiment que le même code en ANSI C serait plus complexe ? Non, il serait à la fois immensément plus simple et plus rapide.

Java (dérivé du C) est nécessitant les programmeurs peuvent relier des chaînes de caractères de plusieurs lignes avec un '+'.
C# (dérivé de C) est nécessitant les programmeurs peuvent relier des chaînes de caractères de plusieurs lignes avec un '+'.
PHP (dérivé de C) est nécessitant les programmeurs peuvent relier des chaînes de caractères de plusieurs lignes par un ".".

L'ANSI C n'a pas cette exigence désormais complètement stupide (obsolète).

Alors, où est le so évident les progrès revendiqués par les langues vivantes ? Je suis toujours à la recherche de ces progrès.

Sincèrement,

Pierre.

Answer 3

La même raison pour laquelle nous n'utilisons pas le C pour la plupart des programmes. Les avantages (qui sont surtout des performances) ne compensent pas les coûts (temps de développement, absence de gestion automatique de la mémoire, absence de protection automatique contre les débordements de tampon, nécessité d'une étape de compilation entre les étapes d'édition et de test, etc.)

Answer 4

La plupart des applications réseau, notamment les serveurs Web, sont beaucoup plus "liées aux entrées/sorties", c'est-à-dire qu'elles sont capables d'envoyer des données beaucoup plus rapidement que le réseau ne peut les accepter. Par conséquent, une solution hautement efficace en termes de CPU n'est pas une grande victoire, alors qu'une solution évolutive et maintenable l'est. Il n'y a donc aucune raison d'accepter les inconvénients du C et de perdre les avantages d'un environnement géré comme Java, .NET, Python, Perl ou d'autres langages.

Answer 5

Le C n'est pas un langage pratique pour manipuler les chaînes de caractères.

Comparez C# :

string foo = "foo";
string bar = "bar";
string foobar = foo + bar;

Correspondant C :

const char* foo = "foo";
const char* bar = "bar";
char* foobar = (char*)malloc(strlen(foo)+strlen(bar)+1);
strcpy(foobar, foo);
strcat(foobar, foo);
//todo: worry about when/where the foobar memory
//which was allocated by malloc will be freed