Почему вы не используете C для своих веб-приложений? - PullRequest
94 голосов
/ 20 июня 2010

Этим утром я просматривал несколько разных веб-серверов, когда наткнулся на G-WAN .Как я понимаю, это веб-сервер, написанный на C, и вы должны использовать его, написав свои веб-сайты / веб-приложения на C. Одним из очевидных преимуществ является скорость, как предполагает сайт G-WAN.

Однако нана форумах создатель G-WAN спросил, почему бы не использовать C для веб-приложений, и я не могу придумать ни одной причины, кроме как трудной (для меня, во всяком случае, я новичок, когда речь идет о C).Должно быть больше причин, по которым мы все используем PHP, Python, Ruby и т. Д., Кроме того, что их легко разрабатывать на этих языках.Я не вижу в этом веской причины.

Поэтому я говорю вам: почему вы не используете C для своих веб-приложений?

Ответы [ 24 ]

76 голосов
/ 20 июня 2010

Требуется много усилий, чтобы получить правильную и безопасную программу на Си.Эта забота означает, что вам нужны действительно хорошие люди, пишущие ваши программы.Это означает, что вы платите больше.

Кроме того, C не имеет возможности использовать огромную единую стандартную библиотеку функциональных возможностей, как в .NET (и других основных веб-ориентированных платформах).Таким образом, вам, возможно, придется либо покупать компоненты, либо выполнять взаимодействие, либо реализовывать свои собственные функции, которые «бесплатны» с более, скажем, «веб-ориентированным» языком, таким как PHP или C # или Ruby или любым другим.Это означает, что вы платите больше.

Добавьте все это к тому факту, что однопоточная скорость вычислений не так важна в Интернете.Если вам нужна большая масштабируемость, большинство организаций могут экономично просто добавить больше ядер для решения проблемы и все будет в порядке.Конечно, это не так для всех.Я полагаю, что ядро ​​движка Google написано на C или аналогичном языке не только для скорости, но и для экономии реальных затрат на электроэнергию.

46 голосов
/ 15 июля 2010

Гул ...

Кажется, я немного опоздал в этом обсуждении - но я только что открыл это сейчас.И я благодарен всем вам за столь большой вклад.

Я являюсь автором G-WAN, что дает понять, что я серьезно работал над этим вопросом: G-WAN работает быстрее, чем все другие веб-серверы.(без обработки) и всех других серверов веб-приложений (любая обработка, которую вы можете себе представить).

Да, ANSI C также позволял обрабатывать больше статического контента - с менее мощными ЦП (ANSIC - это не только создание динамического содержимого).

Кстати, G-WAN использует сценарии C (компилятор и компоновщик C не требуются), поэтому цикл / задержка компиляции / компоновки не существует.

В процессе сравнения G-WAN с .NET Java и PHP я написал похожих приложений на всех 4 языках: http://gwan.ch/source/

И, к моему ужасу, современныйязыки сценариев были не проще в использовании.

Одна часть работы, которая особенно расстраивает, - это отчаянный поиск магического вызова API, который будет делать то, чтоВы хотите сделать.

Подумайтео том, как сделать «милые тысячи» в:

C #

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

Java

new DecimalFormat("0.00"); ...

PHP

number_format($amount, 2); ...

ANSI C

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

«...» означает, что необходима некоторая предварительная настройка или постобработка.Очевидно, что ANSI C проще в использовании и запоминании.

Когда PHP имеет более 5900 вызовов API (C # и Java не далеко), поиск вызова right API является сложной задачей.своя.Было потрачено время, чтобы найти это (а затем выяснить, насколько плохо реализован вызов API native ), время, чтобы изучить его в следующий раз, когда оно вам понадобится, все это время лишает вас возможностивремя, необходимое для решения проблем вашего приложения.

Я прочитал (выше), что PHP более лаконичен, чем ANSI C?Зачем тогда использовать "//:: this is a comment ::" вместо "// this is a comment"?Почему такой тупо сложный синтаксис «милых тысяч»?

Другой обычный аргумент - это то, что Java и тому подобное обеспечивают выделенные вызовы для веб-приложений.

Я не смог найти ничего, что могло бы сбежатьHTML в Java, поэтому я написал свою версию:

  // 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();
  }

Вы действительно верите, что тот же код в ANSI C будет более сложным?Нет, это было бы и намного проще и быстрее.

Java (производная от C) - это , требующая от программистов связывать многострочные строки с помощью '+'
C # (производный от C) - это , требующий от программистов связать многострочные строки с '+'
PHP (производный от C) - , требующий от программистов для связывания многострочныхстроковые строки с символом '.'

ANSI C не имеет этого ныне совершенно глупого (устаревшего) требования.

Итак, каков был очевидный прогресс, заявленныйсовременные языки?Я все еще ищу это.

С уважением,

Пьер.

45 голосов
/ 20 июня 2010

По той же причине, по которой мы не используем C для большинства программ.Преимущества (в основном это производительность) не перевешивают затраты (время разработки, отсутствие автоматического управления памятью, отсутствие автоматической защиты от переполнения буфера, наличие этапа компиляции между этапами редактирования и тестирования и т. Д.).

27 голосов
/ 20 июня 2010

Большинство сетевых приложений, особенно веб-серверы, гораздо более «привязаны к вводу / выводу» - т.е. они способны откачивать данные намного быстрее, чем сеть может их принять. Поэтому то, что является высокоэффективным процессором, не является огромным выигрышем, в то время как то, что является масштабируемым и обслуживаемым. Таким образом, нет причин признавать недостатки C и терять преимущества управляемой среды, такой как Java, .NET, Python, Perl или других языков.

15 голосов
/ 20 июня 2010

C - не удобный язык для работы со строками.

Сравните C #:

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

Соответствующий 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
10 голосов
/ 20 июня 2010

Если бы сложность и сложность не были проблемой вообще (ха!), То я не остановился бы на C. Я бы написал сборку x86. Прошло много лет с тех пор, как я использовал любой веб-сервер, который не был x86, и с каждым днем ​​он выглядит все менее и менее вероятным.

Использование C (вместо сборки или чего-то более высокого уровня) означает, что C - это лучшее место для программистов и компьютеров.

Для программ, которые я пишу, это не так: C плохо подходит для тех программ, которые я хочу написать, и его преимущества перед приличным макроассемблером не так уж и значительны. Программа, которую я пишу сейчас, не сложна в моем выборе HLL, но ее сложность в сборке или в C будет настолько высокой, что она никогда не закончится. Я признаю, что достаточно умный программист с достаточным количеством времени может заставить его работать быстрее на ассемблере или в C, но я не тот программист.

7 голосов
  • это небезопасно
  • это трудно читать
  • трудно поддерживать, время разработки медленнее на порядоквеличина
  • большая часть вашего веб-контента, вероятно, связана с вводом / выводом, поэтому ускорение даже не имеет значения, особенно если вы используете быстрый язык, такой как Java или C #
6 голосов
/ 20 июня 2010

Я знаю, что на этот вопрос уже был дан смертельный ответ, но есть еще две вещи, не упомянутые до сих пор, которые чрезвычайно важны для успеха в любой парадигме программирования, особенно в веб-разработке, где есть множество людей, которые не обязательно программисты, работающие с кодом.

  1. Вовлеченное, полезное сообщество, или Люди, которые уже решили мою проблему. Даже для самого новичка в Google довольно легко понять, почему в PHP появляются ошибки «заголовки уже отправлены», в то время как эта информация может быть недоступна для фреймворка или языка, которые являются новыми для сцены, или иным образом не имеет критическая масса.
  2. Фреймворки, позволяющие большинству программистов решать бизнес-задачи, а не взламывать код вместе.

Если бы у меня было критическое приложение, которое требовало бы предельной производительности, я бы использовал C, но для написания этого потребовалось бы намного больше времени, и я бы никогда не вышел на рынок. Пока не будет № 1 или № 2, я не смогу его использовать.

6 голосов
/ 20 июня 2010

C - это довольно низкоуровневые языки для многих целей: no-OOP, много ручного управления ресурсами.

Существует ограниченное использование C для веб, например Klone . Он в основном используется для случаев применения встроенных приложений с низким ресурсом.

Однако существуют C ++ веб-фреймворки, такие как CppCMS , которые используются для разработки высокопроизводительных веб-приложений.

C ++ позволяет вам наслаждаться высокой абстракцией и мелкозернистым доступом к тому, что вы делаете, в точности предоставляя гораздо лучший вариант для развертывания и разработки больших приложений.

Но вы используете их в случае, когда производительность и использование ресурсов намного более критичны затем время выхода на рынок и затраты на разработку, как правило, веб-разработка быстрее используя хорошие веб-фреймворки для таких языков, как Java, Python или PHP. Также в целом есть менее компетентные программисты для C ++, чем Java / P * языки для той же зарплаты.

Так что это вопрос приоритетов, и там меньше инструментов для веб-разработки на C ++, чем для PHP / Python / Perl или Java.

5 голосов
/ 16 июля 2010

@ Joeri Sebrechts

F.U.D. в действии:

PHP, Python и т. Д. Легко масштабируются, бросая аппаратные средства на проблему.

Ну, вообще-то нет. Они совсем не масштабируются по вертикали и очень плохо масштабируются по горизонтали. См .: http://gwan.ch/en_scalability.html, где объясняется, сколько неприятностей впереди плохие-исполнители.

Предположим, что разработка приложения на PHP стоит 1 человеку 1 год, и это стоит им 3 года, чтобы сделать это в C (поскольку C требует больше усилий, чтобы сделать то же самое).

снова не так. Если PHP библиотеки были написаны на C, то они могут использоваться напрямую от C - постоянно обеспечивает «уникальную производительность», которую, как вы утверждаете, имеет PHP.

Это означает, что уменьшенная потребность в оборудовании кода C должна составлять 2 года стоимость заработной платы для C, чтобы стать привлекательным. На практике этого (почти) никогда не бывает.

Чистый Ф.У.Д. (см. ответ выше).

Масштаб Фейсбука настолько велик, что затраты на его обслуживание достаточно велики. Вот почему они разработали HipHop, который кросс-компилирует PHP в C ++. Это приносит лучшее из обоих миров: простота программирования на PHP, и сырая производительность C ++. Facebook все еще разрабатывается на PHP, но когда вы используете его, это все нативный код.

HipHop намного быстрее, чем PHP, в этом нет сомнений. Но если вы сравните В HipHop с реализацией обычного C у вас есть два уровня накладных расходов:

  • интерфейсы PHP к C ++ (которые используют раздутые библиотеки C ++);
  • Сам раздувной C ++ (что делает C ++ в 2-10 раз медленнее, чем обычный C)

Плюс, HipHop был написан в невежественном неэффективном академическом режиме (оторванный от любой реальности реального мира). конечно, это может впечатлить PHP-кодеров но покажите этот код встроенному программисту, и ему будет жалко Facebook.

"Язык, на котором нет всего, на самом деле легче программировать в чем некоторые из них "- Денис М. Ричи

В отличие от (большей части) языка программирования END-USERS, Деннис знал пару кажется, о вещах по этому поводу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...