Сегодня мы поговорим на тему «C против C++». Некоторые читатели данного блога уже знакомы с моей точкой зрения по этому поводу. Когда встает вопрос с формулировкой вроде «похоже, мы решаем задачу, где очень важна скорость выполнения кода, и нужно выбрать между языками C и C++», в последнее время я склонен рекомендовать C. Многие программисты при этом недоумевают, мол «как же так, ведь С++ новее и имеет больше фичей, и вообще C входит в него как подмножество». Поэтому я хотел бы подробно объяснить свою точку зрения один раз в данном посте, так как каждый раз объяснять ее заново занимает ощутимое количество времени.
Я тут недавно решил послушать 86-ой выпуск подкаста «Разбор Полетов». Помимо прочего, в выпуске обсуждался пост Фаулера MonolithFirst, в результате чего разгорелась довольно длительная дискуссия на тему «монолиты против микросервисов». Большая проблема с микросервисами заключается в том, что многие вещи, которые с их помощью пытаются решить, либо успешно решаются и без микросервисов, либо к микросервисам и монолитам отношения вообще не имеют. Если вам интересны мои размышления по этой теме, добро пожаловать под кат.
Не уверен, рассказывал я об этом, или нет, но вот эти любимые некоторыми товарищами строгое доказательство корректности программ/алгоритмов, Agda, зависимые типы и так далее видится мне довольно бесполезной затеей. А также я давно перестал внимать рассуждениям таких же товарищей в стиле «MongoDB плохая база данных, потому что читай Афира» или «Ай-яй-яй, в Cassandra таймстэмпы вместо CRDT». Далее я постараюсь объяснить, почему так. А вы, как обычно, прочитаете по диагонали, выдерите слова из контекста и напишет в комментариях, что я ничего не понимаю :)
Фреймворки бывают разные. Если, например, мы рассмотрим веб-фреймворки, то можно легко заметить их разделение на две большие группы — легковесные фреймворки (например, Scotty, Cowboy, Finagle) и тяжеловесные (Yesod, Play, Catalyst). Первые по сути предлагают собой встраиваемые веб-серверы, возможно, с поддержкой вебсокетов. Во вторых поверх всего этого еще накручена валидация форм, конфиги, i18n, ORM, и так далее. Оборачиваясь назад, я понимаю, что тяжеловесные фреймворки меня всегда чем-то беспокоили, но я не мог четко сформулировать, чем именно. Так было до недавнего времени.
Вы, наверняка, знаете, как это бывает. Ой, у нас тут такие тяжелые вычисления / так долго тянутся данные из базы. А давайте просто прикрутим кэшик. Что может пойти не так? Так вот, опыт показывает, что пойти не так может очень и очень многое.
Я не мог не заметить, что читателей сего блога очень заинтересовала тема «нужно ли давать котикам играться с новыми клубочками». Поэтому хотелось бы поделиться еще кое-какими своими мыслями по связанной теме, в отношении языков Си и C++ и убьет ли их Rust. Тема, как вы сами понимаете, очень-очень холиварная, поэтому подумайте еще раз, хотите ли вы читать эту заметку дальше и тем более участвовать в «конструктивном обсуждении» поста при помощи комментариев.
Типичная ситуация. Программист читает книжку о новом, или не таком уж и новом, языке программирования, базе данных или иной технологии и сгорает от нетерпения поскорее ее попробовать. Возможно, он узнает о технологии или подходе не из книги, а из подкаста или доклада на конференции, не суть важно. Другая похожая ситуация — «в нашем проекте все очень плохо, потому что мы используем DynamoDB (пишем на Java), давайте все перенесем на PostgreSQL (перепишем на Erlang)». В этой заметке я собрал веские причины не поддаваться соблазну протащить новые игрушки в продакшн.
Велика колхозная доктрина — это квинтэссенция программистской мудрости. Десятилетиями доктрина передавалась членами тайного ордена колхозных программистов из уст в уста, из поколения в поколение. К великому сожалению, со временем учение стало додумываться и обрастать различными толкованиями. Мы видим появление новых те-еретиков, намеренно искажающих доктрину, чтобы поселить сомнения и ужас в наших сердцах. У ордена не осталось иного способа спасти истину, кроме как предать доктрину широкой огласке. Ниже представлена наиболее точное приближение к оригинальной доктрине, которое удалось по крупицам восстановить благодаря небольшой группе посвященных.
В любой команде рано или поздно появляется человек, который совсем недавно прочитал книжку по Lisp или осилил Template Haskell и потому ему не терпится применить метапрограммирование на практике. Однако проблема заключается в том, что в большинстве случаев макросы или шаблоны создают больше проблем, чем решают. В этой заметке будет показано, почему так.
За что мы любим языки с автоматической сборкой мусора? За то, что нам с вами приходится меньше думать. Мы просто создаем новые объекты, а когда они оказываются ненужны, RTS сама освобождает память. Проблема утечки памяти решена, жизнь прекрасна и удивительна! Вот только, к сожалению, это неправда.
