курсы программирования (Киев)Нет, я не противник Си. Я его уважаю и очень люблю. Будучи студентом, я посещал курсы программирования, потратил большое количество время на изучение  POSIX и WinAPI, написание своих драйверов для Windows XP и архиваторов. Даю ссылку на учебный центр, где проходил курсы, вот она: http://itstolytsa.ua/nashy-kursy/web-design/web-programing

Но, сделать карьеру в сфере Си мне так и не удалось. Работодатели по какой-то причине боялись, что в коде, который напишет молодой студент, переполнится стек или утечет память. Вот по этой причине мне пришлось заниматься программированием на языках более высокого уровня. Так вот после изучения их я и хотел бы объяснить, почему в программах следует избегать использования Си.

История повторяется вновь и вновь.

Так вот, придя в новый коллектив специалистов, дают задание поддерживать проект на Erlang. Радости нет предела! Функциональщина! Честная сборка мусора, неизменяемы переменные, акторы и все такое. Компьютер сам делит между огромным количеством легковесных процессов время.  Можно не работая головой обслуживать колоссальное количество ТСР соединений. Как у Erlang так просто все получается? Да легко! Просто у того что делает виртуальная машина есть некоторая стоимость в редукциях. Так вот когда процесс выполнил около 2000 редукций, управление на себя берет очередной процесс. Но, минусом является то, что процесс продвигается медленно. Точно уже не скажу, но приблизительно декодирование 50 мегабайт JSON’а на чистом Erlang будет выполнятся несколько минут. Получается, если обрабатывать самый простой HTTP запрос, то это займет около минуты, из-за декодирования. Печально. Но что же делать? Так может, просто используем либу, которая была написано на Си. Он ведь быстрый!! Вроде все должно пройти отлично. И действительно он умудряется обработать один запрос за 5 секунд!! Жизнь полна приятных моментов!

Но мы рано радуемся! И тут случается страшное! К вам начинает приходить огромное количество запросов и сервер, не справляясь, просто перестает отвечать. Как это произошло? Просто то, что написано на Си, виртуальная машина Erlang внутри кода не контролирует. Нет ни распределения времени между процессами ни редукций. Вы имели некоторое количество ниток операционной системы. В тот момент, когда пришло такое же количество запросов, все нитки занялись декодированием JSON. Ну а те процессы, которые отвечают за работу системы, которая осталась, спят. Звонят среди ночи, поднимают, срочная отладка, курение логов, кода, метрик, невозможно разобраться, много хотфикса, кишки , кровь, содомия. Но все-таки сейчас появился метод обойти такую проблему в Erlang R17. Но раньше-то его не было!

Тогда ты переходишь в следующую команда. Поддерживаешь проэкт на Scala. Слава Богу! Строгая типизация!! Не нужно накладных расходов на то, что бы копировать данные с одного места в другое, огромное количество готовых библиотек, JIT компилятор, акторы, в общем, все отлично! Просто сиди, преумножай матрицы и работает это очень даже быстро. Но, к моему сожалению, почему-то команде захотелось воспользоваться в данном проекте новой модной библиотекой, которая вышла в свет буквально недавно- — года два назад. Я ничего не имею против, она шикарна! Вот только есть одна небольшая проблемка – написана то она на Си  и, естественно, под JVM до сих пор не переписана.

Как же быть? Можно стоит взять не настолько новую библиотеку, которая все-таки проверенна временем, и переписана на любые языки? Только какой в этом смысл, если можно использовать JNI. Ну вот теперь по любому все будет хорошо и все должно пойти как по маслу. И точно, библиотека легко прицепилась к сервер сайду, все прекрасно, работа налажена.  Жизнь прелестна!

И тут начинается ужас!!! Разработчики клиент сайда совершают попытки перекрутки библиотеки. Но основная загвоздка в тоом, что клиент слайд – это приложения для Android, iOS и десктопа. Огромнейшее количество какой-то непонятной ругани Clang, неправильные пути к сеошникам, вобщем, уйма потерянного времени, кишки, кровь, содомия!

В общем, при возможности, отказаться от использования Си, лучше не использовать. Сколько я проработал, то ни один проект нормально не закончился.  Лучше написать отдельно сервис на Go или Scala, завести отдельно кэш, пользователя убедить, что его запрос в обработке, а еще лучше выпросить у начальства купить парочку серверов. В любом случае Си остерегайтесь. Сэкономьте нервы, время и ресурсы свои и своей компании.

В дополнение, хочу отметить, что в главе XII прекрасного издания Java Performance: The Definitive Guide категорически не рекомендуется автором пользоваться  JNI, так как тогда программа будет работать медленнее, чем обычный код  на Java. Но ведь есть еще JIT! Так как тратятся накладные расходы на то чтоб скопировать данные между нативным кодом и JVM. В принципе это истина не только о JVM.

Автор статьи: Евгений Дзюда (Компьютерные курсы «Столица»).