сначала назвали всех, кто выбирает не C++ недопрограммистами
Я такого не говорил. Просто многие пишут о C++ и <своем любимом ЯП, который отлично подходит под данную задачу> без аргументов, да иногда еще не прочитав статью полностью. Вообще, странно писать что-то в статье про библиотеку, написанную на C++ , не зная C++ на хоть каком-то уровне.
а потом C++ программистов выставляете какими-то тугоумами, которым тяжело другой язык освоить.
Опять же, я такого не говорил. Я считаю, что если взять программиста, который лет 5, или может 10, писал в основном на C++, и пересадить его на Java, то в 90% случаев он будет писать так, как привык на C++, особенно если учесть, что синтаксис очень похож. И пройдет какое-то время, пока он освоится. А если посадить целый отдел, который писал на C++, писать на Java, то тут может ничего хорошего не выйти, в любом случае нужна подготовка и/или помощь более опытных в этом ЯП коллег.
Поэтому по первому вопросу - да, я считаю, что сеньору легко взять и перейти на другой язык.
Это не вопрос, и речь не про инженера, а про компанию, где миллионы строк кода написаны на <ЯП X>.
Что касается аргументов "ЗА", они зависят от конкретной ситуации.
Почему же тут каждый второй пишет : а почему вы не использовали ЯП X, хотя в статье явно указаны проблемы некоторых ЯП, с которыми не хотелось мириться? В моем понимании, такие люди свой ЯП то до конца не изучили (хотя бы на 50%, до конца навряд ли хоть кто-то знает какой-нибудь ЯП).
С++ имеет смысл рассмотреть для отдельных сервисов в проектах с целевой нагрузкой более 10k rps.
Если мы говорим именно про сервисы и компания, которая делает что-то новое, без собственной кодовой базы, то вероятно, это так.
И да, на нём действительно сложно писать. Я вполне осознанно его забросил, потому что мне не нравится отвлекаться на ручное управление памятью и помнить 100500 случаев, когда возможно UB.
Сложно возразить без примеров. На C++ не так сложно писать, как лет 10 назад.
А я и не говорил, что другие языки неудобные и неэффективные. Просто почему-то многие думают, что
а) вот так вот легко взять, и перейти на другой ЯП
б) не приводят никаких аргументов ЗА
в) думают, что на С++ ОЧЕНЬ сложно писать, хотя сами его в глаза не видели
И так сложилось, что в яндексе, да и в некоторых других компаниях есть люди, которые знают С++ лучше, чем другие языки, которые тоже могут подходить под данные задачи. И по опыту, если посадить плюсовика писать код на той же Java (хотя этот язык без хаков не подходит под данные задачи, как было описано в статье), то он все равно будет писать по плюсовому, и пройдет неизвестно сколько месяцев-лет, пока он не "перестроится".
Антон, спасибо за статью и новую классную библиотеку.
Когда-то Хабр был просто нереальным кладезем интересных вещей, как и людей. А сейчас я вижу в комментах кучу недопрограммистов, которые вообще ничего не смыслят в программировании, им бы лишь новомодные библиотеки/языки использовать. Куча вопросов : а почему не язык Н? А вы, товарищи, хотя бы подумайте о том, зачем использовать ваш язык, если есть C++, есть программисты, которые лучше знают этот язык, он удобен и эффективен. Подумали теперь? Все еще нет? Тогда удосужьтесь, хотя бы, написать в чем удобство предлагаемого языка, желательно со сравнением времени time-to-market и производительности в любых задачах, которые не только предполагают складывать 2 числа.
По-моему, вы утрируете и я такого не писал.
Я такого не говорил. Просто многие пишут о C++ и <своем любимом ЯП, который отлично подходит под данную задачу> без аргументов, да иногда еще не прочитав статью полностью. Вообще, странно писать что-то в статье про библиотеку, написанную на C++ , не зная C++ на хоть каком-то уровне.
Опять же, я такого не говорил. Я считаю, что если взять программиста, который лет 5, или может 10, писал в основном на C++, и пересадить его на Java, то в 90% случаев он будет писать так, как привык на C++, особенно если учесть, что синтаксис очень похож. И пройдет какое-то время, пока он освоится. А если посадить целый отдел, который писал на C++, писать на Java, то тут может ничего хорошего не выйти, в любом случае нужна подготовка и/или помощь более опытных в этом ЯП коллег.
Это не вопрос, и речь не про инженера, а про компанию, где миллионы строк кода написаны на <ЯП X>.
Почему же тут каждый второй пишет : а почему вы не использовали ЯП X, хотя в статье явно указаны проблемы некоторых ЯП, с которыми не хотелось мириться? В моем понимании, такие люди свой ЯП то до конца не изучили (хотя бы на 50%, до конца навряд ли хоть кто-то знает какой-нибудь ЯП).
Если мы говорим именно про сервисы и компания, которая делает что-то новое, без собственной кодовой базы, то вероятно, это так.
Сложно возразить без примеров. На C++ не так сложно писать, как лет 10 назад.
А я и не говорил, что другие языки неудобные и неэффективные. Просто почему-то многие думают, что
а) вот так вот легко взять, и перейти на другой ЯП
б) не приводят никаких аргументов ЗА
в) думают, что на С++ ОЧЕНЬ сложно писать, хотя сами его в глаза не видели
И так сложилось, что в яндексе, да и в некоторых других компаниях есть люди, которые знают С++ лучше, чем другие языки, которые тоже могут подходить под данные задачи. И по опыту, если посадить плюсовика писать код на той же Java (хотя этот язык без хаков не подходит под данные задачи, как было описано в статье), то он все равно будет писать по плюсовому, и пройдет неизвестно сколько месяцев-лет, пока он не "перестроится".
Антон, спасибо за статью и новую классную библиотеку.
Когда-то Хабр был просто нереальным кладезем интересных вещей, как и людей. А сейчас я вижу в комментах кучу недопрограммистов, которые вообще ничего не смыслят в программировании, им бы лишь новомодные библиотеки/языки использовать. Куча вопросов : а почему не язык Н? А вы, товарищи, хотя бы подумайте о том, зачем использовать ваш язык, если есть C++, есть программисты, которые лучше знают этот язык, он удобен и эффективен. Подумали теперь? Все еще нет? Тогда удосужьтесь, хотя бы, написать в чем удобство предлагаемого языка, желательно со сравнением времени time-to-market и производительности в любых задачах, которые не только предполагают складывать 2 числа.