LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

Давайте я вам поясню про язык Go, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

Но дело вот в чем. В гугле, на самом деле, над каждой командой гошников стоит тимлид, или целая группа, который/которая вот этим взаимозаменяемым роботам-гошникам расписывает всю систему, чуть ли не вплоть до состояния конечного автомата, до if-ов, и показывает куда и что писать. Поэтому же Go на корню режет всю креативность, поэтому там нет практически никаких средств абстракции, и поэтому он не дает делать вообще ничего сложного. Дабы программисты на нем вообще ничего лишнего не думали, а кодировали все чуть ли не побуквенно по указаниям умных людей.

Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

Если у вас в компании такой «модели управления» нет, и более того, у вас нет возможности нанимать крайне высококвалифицированных людей за крайне много денег, единственное назначение которых будет расписывать стаду гошников(которые тоже стоят немало денег просто из-за количества) систему до уровня конечного автомата, то вам этот язык и вся его экосистема нахрен не сдалась.

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

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

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

★★
Ответ на: комментарий от hateyoufeel

Собсна не подумай, что я защищаю JS. Если ты вдруг задумаешь завтра начать разрабатывать «нормальную альтернативу js» - с удовольствием присоединюсь к команде, вот только:

  • кто убедит команды разработчиков браузеров интегировать наше решение?
  • кто убедит разработчиков сайтов/приложений использовать нашу безывестную фичу вместо популярного и поддерживаемого всеми js?

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

Aswed ★★★★★
()
Ответ на: комментарий от den73

Нет противоречия.

Противоречия чего с чем?

Вы мне приписываете проблемы с логикой утверждая что: «ты не разделил понятия целевой ниши и реально занимаемой ниши»

Я вам говорю, что таки разделил, т.к.: «то, что C++ подходит для задачи X, не означает автоматически, что C++ будет выбран для задачи X. Хотя бы потому, что всегда есть конкуренты»

Именно это и говорит о том, что целевая ниша вот эта, но в ней C++ не один, поэтому он и не занимает ее всю.

На что вы говорите, что противоречия нет. Т.е. если я прав, то как быть с вашими обвинениями «у тебя с логикой нелады»

Что там такого «сложного» именно на первом этапе, когда мы меняем язык?

Смена стиля мышления.

Бл*дь, вопросы для человека, у которого «достаточные представления» о C++, просто феерические.

eao197 ★★★★★
()
Ответ на: комментарий от thesis

Моя библиотека (которая входит вообще говоря как в топ рекомендуемых библиотек для CL https://awesome-cl.com/ так и в дефолтный репоризторий дефолтного пакетного менеджера - quicklisp)

https://github.com/Lovesan/bike/tree/master/src

используется в проде на западе, в частности для автоматизации работы с микроконтроллерами (там своеобразная херня, требуется дотнетные приблуды), но и не только в этом(в основном все в личку и на мыло приходят как что)

щас люди хотят на основе ее сделать GUI на основе Avalonia(там даже в issues ко мне приходили)

den73 пишет специфический код это раз, хз какое тут сообщество лисперов в РФ это два, непонятное оно, и вообще РФ это сельпо в плане технологий, и три - success stories надо брать с запада и с соответствующих ресурсов, а не со срачей на лоре, я уже скидывал сто раз

https://planet.lisp.org/

https://franz.com/success/

libera#commonlisp (IRC, и другие каналы впрочем - https://www.cliki.net/irc )

https://www.reddit.com/r/Lisp

https://www.reddit.com/r/Common_Lisp (в правой панельке есть почти все что надо прочитать)

и далее там по ссылкам

самое «видное» что написано среднему русскоязычному человеку на CL это Grammarly - украинская компания

Короче, я бы не ориентировался по неудачам человека который со строками работать не умеет и еще вкручивает в лисп какую-то непонятную п[уе]ргу, дак и плюс вдобавок отрицает все западное сообщество вообще

lovesan ★★
() автор топика
Ответ на: комментарий от Elidee

Надо брать CL.

Технически, даже если потом работать на Clojure - учить и втыкать надо сначала все-равно в CL.

Scheme/Racket - это все учебные языки для ресерча в академии и студентоты. Накрайняк - для мелкого скриптинга (gnu guile).

Кстати, тут еще вспомнил - один знакомый лиспер делает видео про CL на русском языке, для начинающих

https://www.youtube.com/@40Ants/videos

lovesan ★★
() автор топика
Ответ на: комментарий от eao197

Вот уж не думал что мне, как C++нику, придется защищать производительность JVM. Но таки вы сильно недооцениваете производительность оной после «прогрева».

Проблема в JVM в том, что на ней «производительно» работает только Java. И то, после тюнинга(сказывается проблема засирания ООП повсюду, отсутствие value-типов и нормального FFI). Остальные косо прилепленные там языки, особенно функциональные (Scala, Clojure и даже ABCL - реализация CL) - работают там хреново.

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

lovesan ★★
() автор топика
Ответ на: комментарий от Elidee

Есть ли на схеме библиотеки для AWS?

Вот чето есть, я не пробовал правда. Но вроде это известный лиспер писал

https://github.com/pokepay/aws-sdk-lisp/tree/master

Плюс, смотри вот тут: https://awesome-cl.com/

там есть некоторые библиотеки.

Как из схемы работать с базой данных? Тот же Postgres?

Куча ORM и всякого есть

итд

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

lovesan ★★
() автор топика
Ответ на: комментарий от Forum0888

у меня иногда тоже такое ощущение возникает

lovesan ★★
() автор топика
Ответ на: комментарий от ugoday

CL и Clojure (которая сама может использовать все Java библиотеки, куда уж больше?).

Clojure сильно урезанный и неудобный, объективно. Хотя, конечно с чем сравнивать. С Java? наверное поудобнее. Но куча проблем есть, все-равно.

Касательно Java библиотек - вон благодаря моему проекту - у тебя есть дотнет библиотеки. Не сильно много то отличий в этих экосистемах. И при это не надо мириться с костылями JVM и писать recur и терпеть тормоза итд.

lovesan ★★
() автор топика
Ответ на: комментарий от eao197

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

Да нет у C++ вообще нахер никакой области, кроме поддержки говнокода на C++.

Даже вон гей-дев постепенно с крестов слезает, на Unity всякие

lovesan ★★
() автор топика
Ответ на: комментарий от Aswed

Аааа, то есть ты знаешь но не рассказываешь? А то вдруг санитары заберут? Разумно с твоей стороны.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

у тебя есть дотнет библиотеки.

Наверное это замечательно, я просто про дотнет ничего не знаю, никогда его не видел и не работал. А Java — она вокруг (меня) и повсюду.

ugoday ★★★★★
()
Ответ на: комментарий от Nervous

SICP таки да лучше читать после хотя бы небольшой практики. Чтобы понимать, о чём они там вообще.

Есть русский перевод HTDP.

tt
()
Ответ на: комментарий от lovesan

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

https://madnight.github.io/githut/#/pull_requests/2023/3

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

Опять нахер «миллионы мух не могут ошибаться».

Про Golang там выше выяснили - это изобретение велосипедов и колеса(квадратного).

Про C++ - ну посмотрим че там из популярного. Какие-то лабы, велосипеды и подобное. Чуть не каждая либа - изобретение std. Охерительный показатель. Зато СкОлЬкО ЗвЁзДоЧеК

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Посмотрел тут еще сайтик: https://awesomecpp.com/

Это просто обосраться - тут практически всё - это изобретение квадратного колеса, которое допустим в дотнете просто нахер не нужно, оно там есть из коробки, буквально. Некоторое даже в CL есть из коробки(вообще в стандарте языка - pretty printer например, и я подозреваю он куда удобнее чем сракотна на крестах).

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

Но там даже есть вещи которые никто вменяемый вы прод на крестах пихать не будет

Drogon - A C++14/17 based, high-performance HTTP application framework

Это фейспалм просто.

Ровно как и всякие boost, за которые по большей части надо руки отрывать и выгонять из профессии с вольчим билетом

lovesan ★★
() автор топика
Последнее исправление: lovesan (всего исправлений: 1)
Ответ на: комментарий от lovesan

Это фейспалм просто.

Да, это просто фейспалм.

Но как у вас пригорает, это любо-дорого. В C++ не разбираетесь, на любимом CL для вас работы нет. Вот и приходится на форумах исходить на говно. Еще и бухаете, небось.

У нас есть инструмент, который проще drogon и не такой известный, но его в проде под нагрузкой используют, в том числе и выбрасывая Java.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

У нас есть инструмент, который проще drogon и не такой известный, но его в проде под нагрузкой используют,

ВеБсЕрВиСы ПоД НаГрУзКоЙ

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

IRL вся нагрузка в вебе или даже в микро/макро сервисных архитектурах, короче там где всякое HTTP и прочая херня - это

  1. база

  2. сеть

Всё. Причем когда реально нагрузки, это все масштабируется а не переписывается на C++, если в конторе не шизофреники зашоренные работают - хотя бы потому что ни в плане ускорения СУБД ни в плане снижения нагрузки на сеть - кресты не помогают вообще никак от слова совсем (зато сколько геморроя приносят это обосраться можно)

lovesan ★★
() автор топика
Последнее исправление: lovesan (всего исправлений: 2)
Ответ на: комментарий от eao197

Какая смена стиля мышления? По сути на вопрос можешь ответить или будешь переводить исключительно о моей личности? Переход от обсуждения вопроса по существу на личность собеседника не говорит о тебе и твоих знаниях ничего хорошего.

Ладно, я сам, раз тебе о программировании нечего сказать: https://stackoverflow.com/questions/5399467/are-there-any-guidelines-on-migrating-from-c-to-c

«Языки программирования и С++, в свою очередь, тесно связаны, но имеют много существенных различий. C ++ начинался как форк раннего, предварительно стандартизированного C, и был разработан так, чтобы быть в основном совместимым с компиляторами C того времени по исходным кодам и ссылкам.»

И далее там есть ссылка на списки отличий C от C++. Там перечень грабель, да, он не такой уж маленький, но для языка, который состоит из граблей чуть менее, чем полностью, особо страшным не выглядит. В частности, кто-то написал, что если в современном компиляторе C у вас всё компилируется без предупреждений, то больших проблем в целом не будет, хотя есть список того, что нужно проверить. Особого криминала (на уровне той катастрофы, которую в целом из себя представляет вообще написание программ на Си) я не увидел.

В любом случае это на порядок-два проще, чем переход с Perl на Python или с Python на Go. Код не нужно переписывать, нужно лишь его прочесать на предмет заранее известного списка проблем, многие из которых лечатся чисто формальными методами. Если бы овчинка стоила выделки, все бы уже перешли на C++. Поскольку, хотя языки и расходятся дальше со временем, C++ тоже развивается и якобы становится лучше (попробуем в это поверить, не может же он в ходе развития становиться ещё хуже).

Про логику я уже тебе всё объяснил выше, что факт клеветы зафиксирован, дальше бодаться на эту тему скучно.

den73 ★★★★★
()
Ответ на: комментарий от lovesan

они на C++ пишут потому что по-другому не умеют

Мы однажды (лет 10 назад) бухали с одним из Яндекса - они и на C++ не умеют - их программы падают и они не могут с этим справиться. Не знаю, может быть за прошедшие 10 лет научились.

den73 ★★★★★
()
Ответ на: комментарий от alysnix

70% кода на этой планете написано на Коболе. Во всяком случае, так было 20 лет назад, как меня заверяли на собеседовании в контору, где надо было на Common Lisp писать (точнее, дописывать) транслятор с Кобола на Яву. Наверняка Кобол за это время сдал, а другие языки подросли, но в любом случае статистика по гитхабу ни о чём не говорит, поскольку там нет проприетарного кода.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от den73

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

если предположить, что число людей, «увлеченных идеями», примерно пропорционально распространенности языка, то мы и видим, сколько людей предпочитают то или другое.

и судя по статистике, никто не любит общелисп. ну или любят, но предпочитают творить не выкладываясь в гитхабы, поскольку творят сокровенное.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Статистика по бездельникам или даже людям увлечённым всё-таки мало о чём говорит. Просто и когда я проходил то собеседование, если гитхаб уже был, то там явно не было 70% Кобола. Естественно, я не утверждаю, что где-то там есть такие залежи кода на лиспе, которые переломят всю картину, но лично я видел проект на нём где-то на миллион строк, и даже что-то там ковырял, и на гитхабе этого проекта нет, хотя он изрядно интересный. Понятно, что это ничто на фоне объёмов гитхаба.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от alysnix

Лол, да на CL там куча проектов. И пишут реально что-то интересное, в отличие от хероты типа изобретения STL

lovesan ★★
() автор топика
Ответ на: комментарий от den73

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

Может быть, я привёл источник, откуда она у меня. Но ведь и обратное фиг докажешь.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от alysnix

11 Shell 2.468% (-0.018%)

12 Nix 2.437% (+0.480%)

Вас не смущает, что язык конфигов для маргинального дистрибутива линукса получил тот же результат, что и язык всей юниксовой мелкоавтоматизации вообще?

ugoday ★★★★★
()
Последнее исправление: ugoday (всего исправлений: 1)
Ответ на: комментарий от lovesan

по ссылке, что я давал, общелисп вроде не входит даже в пятидесяточку призеров соревнований. емакс лисп на 29 месте. схема на 39.

вот и живите теперь с этим.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Ну и не так уж их и не видать, там три языка лисп-семейства присутствуют. И почему надо смотреть статистику именно по запросам на слияние? Common Lisp старый язык, который мало меняется, это не только недостаток, но и преимущество - не надо постоянно бежать за паровозом, когда у тебя под руками то одна, то другая библиотека отваливается. Поэтому активность проектов низкая. Т.е., CL и так в топы не вырвется, но картина будет лучше.

den73 ★★★★★
()
Ответ на: комментарий от alysnix

А, по-моему, если на проверяемых данных мы обнаруживаем лажу, то можно смело предположить лажу и в данных непроверяемых.

ugoday ★★★★★
()
Ответ на: комментарий от alysnix

Еще раз говорю, потому что на CL не переизобретают STL.

И CL не привлекает идиотов, которых как известно 95% населения.

lovesan ★★
() автор топика
Ответ на: комментарий от den73

Какая смена стиля мышления?

Та самая, про которую Алан Перлис говорил, что если язык программирования не меняет стиль мышления, то он не заслуживает внимания.

Касательно C++ и Си, к примеру:

  • нужно забыть про goto end;
  • нужно забыть про объявление констант и мелких функций через define;
  • нужно забыть про ручную очистку ресурсов – требуется следовать RAII;
  • нужно забыть про_длинные_имена_с_префиксом_для_уникальности, поскольку есть пространства имен.

И это мы еще не брали перегрузку операторов, нормальный ООП, исключения, обобщенное программирование и элементы функциональщины.

И это мне приходится разжевывать уникуму, который заявлял, что имеет представление о C++. ДБ, lavrov.jpg

По сути на вопрос можешь ответить или будешь переводить исключительно о моей личности?

С такой мнительностью валерьянку следует пить, а не на LOR-е сраться.

eao197 ★★★★★
()
Ответ на: комментарий от den73

И почему надо смотреть статистику именно по запросам на слияние?

ну там еще и по звездулям можно посмотреть и по issue. по звездулям плюсы вообще идут на 4. а по проблемкам на 2!

alysnix ★★★
()
Ответ на: комментарий от lovesan

IRL вся нагрузка в вебе или даже в микро/макро сервисных архитектурах, короче там где всякое HTTP и прочая херня - это

То-то на TechEmpower benchmark никто за C++ и Rust угнаться не может толком. Это потому, что lovesan здесь срач года разгоняет, а не делится с людьми опытом как надо.

eao197 ★★★★★
()
Ответ на: комментарий от alysnix

посмотреть и по issue

Вы в курсе, что issue — это проблема и их хотелось бы иметь как можно меньше? Вы бы ещё по базе CVE статистикой хвастались, уж там-то C и С++ навечно в абсолютных лидерах.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

я в курсе. но там в ноздрю с с++ идут java и typescript. что говорит о том, что на этих «безопасных» языках проблем примерно столько же.

alysnix ★★★
()
Ответ на: комментарий от den73

Мы однажды (лет 10 назад) бухали с одним из Яндекса - они и на C++ не умеют - их программы падают и они не могут с этим справиться.

В Erlang-е вон набор супервизоров для перезапуска упавших процессов прямо в стандартной библиотеке. Хотя казалось бы, безопасный язык, GC, функциональщина чистой воды, все дела. А процессы рестартовать приходится…

Как говорится, не можешь победить – возглавь!

ЗЫ. Смайлики даже ставить не буду, все равно не поймете.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Не обязательно ничего забывать, это лишь твои какие-то фантазии. Особенно не обязательно делать это сразу. Это если у кого-то в красном углу вместо Спаса висит книжка Страуструпа, то тогда да. А если своей головой думают, то необязательно. Дали инструмент, дали описание - дальше сам решай, что и как с ним делать. Если джун и страшно, то тогда читай книжку Страуструпа. Но я не думаю, что в перечисленных мной хотя бы тех трёх проектах кто-то настолько пуглив, чтобы спасаться только молитвами из молитвенника.

Я говорил про поэтапность перехода, которая критична для больших монолитных проектов. Она достижима. Это основное.

Т.е., если C++ лучше C, то в любом нормальном крупном проекте должны выполнить такой план:

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

  2. по мере возможности, надобности и желания внедряем «смену стиля мышления» в новых модулях, или рефакторим. Если для конкретного модуля (в организационном смысле слова «модуль») не нужно ничего менять, то пусть остаётся на Си.

При этом монолит не нужно дробить. Там, где важна эффективность, раздробить на микросервисы, как это сейчас модно, не всегда возможно, т.к. эффективность скажет «прощай».

Именно такой план снижает риски и делает переход возможным. Но почему-то в перечисленных мной проектах так делать не стали. Значит, C++ не так уж лучше С.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от eao197

Ой, такой умный. В Erlange философия «попробуй сделать и пусть не получится». А на C++ достаточно сложная программа падает в любом случае, если, конечно, её технический лидер - не мастер судовождения танкеров в шхерах.

den73 ★★★★★
()
Ответ на: комментарий от den73

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

Для любого нормального проекта это означает остановку в развитии ибо команда вместо развития будет тратить время на рефакторинг, поэтому к нему будут просто дописывать новые модули на плюсах, оставив ядро на голых сях.

ya-betmen ★★★★★
()
Ответ на: комментарий от eao197

Скорость работы неправильной программы не имеет значения. Но что такое TechEmpower benchmark? Надо глянуть.

den73 ★★★★★
()
Ответ на: комментарий от lovesan

Полагаю, значительное число кода на гитхабе составляют учебные проекты от университетских лаб (scheme) до курсов вайти-вайти (clojure). Так что может тут они и не соврали.

ugoday ★★★★★
()
Ответ на: комментарий от ya-betmen

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

den73 ★★★★★
()
Ответ на: комментарий от eao197

что если язык программирования не меняет стиль мышления, то он не заслуживает внимания

Но если он меняет, то это не значит, что он заслуживает внимания. Например, если он выносит мозг, то нафиг он вообще нужен.

den73 ★★★★★
()
Ответ на: комментарий от eao197

Это что ли?

https://www.techempower.com/benchmarks/#section=data-r21

  • Ну что, на первом месте что-то на C++ со 100%
  • На пятом месте что-то на JS с 87%
  • На девятом - aspcore-ado-pg с 74.4% на C#

Если это линейная шкала, то я бы взял C#. Заплатить лишь третью производительности за то, чтобы не иметь дела с C++ - это означает очень дёшево отделаться. JS, с учётом найденных за прошлый год-два в нём CVE, выглядит менее надёжным. Хотя уязвимости были конкретно в Chrome, может на серверной стороне всё не так криминально, там же не выполняется пользовательский код со странички. Но просто в целом C# - это адекватный ЯП и один из лучших, а JS - это такой своего рода C++ в мире веба.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от Virtuos86

Да мне не нужно с ним общаться, могу и не общаться. Главное, что он по сути-то дела ничего сказать не может. Но кажется, в прошлом он у меня даже бывал в игноре.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Но кажется в прошлом он у меня даже бывал в игноре.

Понимаю 🙂. Но на ЛОР игнор устроен таким паскудным образом, что является вирусным, то есть скрывает целые ветки обсуждения, в которых участвует игнорируемый. А хорошо бы, если бы скрывал исключительно его сообщения. Иначе зайдёшь на очередную страничку треда, а там пол-треда скрыто 🙁.

Virtuos86 ★★★★★
()
Ответ на: комментарий от den73

А если смотреть по задержке ответа, то там опять же JS хорошо выступает и golang. C# ожидаемо сильно отстал, ибо байткод и разогрев (хотя в c# уже 100 лет как есть AOT компиляция, но не знаю пределы применимости). Т.е. нет никакой причины вообще выбрать С++. Казалось бы, явное управление памятью должно снижать задержки, но мы не наблюдаем особо выдающихся результатов по задержке у C++ - оно не опережает ЯП со сборкой мусора.

C++ по параметру задержки даже в первую двадцатку не попал, а в первой двадцатке задержка увеличивается вдвое. Это - разгром.

Т.е. да, я вижу, что я действительно недостаточно знал про C++, чтобы его осуждать. Всё ещё хуже, чем я думал. Спасибо тебе, @eao197, что меня вразумил.

А вот Раст впечатлил своим быстродействием, но в общем-то там не в быстродействии беда. И на очень хороших местах Java (небось весь банкет за деньги Оракла, в чём я и computer languages benchmark game подозревал).

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 5)
Ограничение на отправку комментариев: