Плюсы и минусы переписывания на golang

конкретно Go был задуман как замена C++, а не как замена Python или Ruby

История о том, как делался Go.

История о том, как делался Go.

Cat++, the cat with the seven legs and the wing, is a better cat :-)

плюсы и минусы при переписывании легаси

Если у тебя серьезно возникают такие вопросы, пока не начинай этим заниматься.

Ого, расскажи-ка мне о сложном процессе деплоя шелл-скриптов на подкроватный локалхост.

Могу предложить такой алогритм:

1. Ставишь daemon1
2. /etc/init.d/daemon1 start
3. /etc/init.d/daemon1 status

   daemon1 running

4. Ставишь daemon2
5. /etc/init.d/daemon2 start
6. /etc/init.d/daemon2 status

   daemon2 running

7. $ sudo reboot
8. /etc/init.d/daemon2 status

   daemon2 running

9. /etc/init.d/daemon1 status

   daemon2 not running

10. echo ЗА ЧТО?!

Scala

Фу. Слишком франкенштейново.

Не попрёшь. Но в связке с wartremover-ом становится вполне юзабельно.

Зачем вообще что-то _переписывать_?

Невозможно эффективно модифицировать.

Нужно написать новый софт/скрипт?

Да, но с сохранением функций старого.

Глянул бегло на гитхаб-страницу, не очень понял, чем он делает Скалу более юзабельной. Разве он сделает так, чтобы в Скале исчезла дихотомия функции-с-одним-аргументом-кортежем vs функции-с-несколькими-аргументами-и-даже-не-каррированными. Это что больше всего выбесило.

А также: отсутсвтие нормального синтаксиса для определения АДТ, вместо этого уродские case-классы.

Вот почему разработчики F# смогли всё сделать правильно, а разработчики Скалы — нет?

начинай этим заниматься.

Да, как раз собираюсь.

Акцент во фразе в «на golang».

в Go массово переходят со всяких Python-ов

Можно десяток примеров?

Можно десяток примеров?

Во-первых, полагаю, что Пайк говорил про то, что творилось в Google.

Во-вторых, пример Dropbox-а, который перешел с Python-а на Go, достаточно показателен.

Ну, например, убивает мину замедленного действия под названием «==». Которая вообще нифига не типизированная, и работает для всего.

А кортеж вместо аргументов функции... от этого, боюсь, вывод типов станет ещё хуже (он и так испорчен наследованием, а будет вообще никуда).

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

Не пиши на баш, пиши на посикс шел :-)

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

Вот почему разработчики F# смогли всё сделать правильно, а разработчики Скалы — нет?

Разработчики F# шли от ФП к ООП. В scala - наоборот. Кроме того, ещё пытаясь экспериментировать со всякими разными концепциями. Про откровенную дурь в духе поддержки xml я вообще молчу.

Хотя F# мне тоже не сильно нравится, ибо не очень понятно, где и зачем его применять.

Обычный web

А почему не Java? Отказоустойчивость, масштабируемость, высокая производительность благодаря JIT (даже быстрее нативок). И докер можно прикупить. Фреймворки, библиотеки - тоже всё есть, проверенное временем.

https://i.kym-cdn.com/photos/images/original/001/167/690/e55.png

высокая производительность благодаря JIT (даже быстрее нативок)

Откуда вы берётесь?

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

Ну, пока что, до конца не понятно что.
Но точно не Java. Хрен его знает почему, но нет.

А вот gopher-ы говорят норм, не проблема.

Чтобы потом ещё переписывать? Не, ну если тебе за это платят, то вперёд конечно. Не всё ли равно чем заниматься? Вообще, логично легаси говно переписать на питон (если это скрипты), а не на гопарашу.

Так трудно разобраться в технологии? Информация открытая же. И ынтырпрайз весь на джаве. Вот даже ЛОР на джаве, потому то здесь страницы моментально открываются.

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

Что за бред? Вот много ли здесь тех, у кого стоит Alexa Toolbar? Оказывается много - 4.8к уников, 19к просмотров в сутки. Это уже совсем не низкая посещаемость, а реальные цифры в разы выше. А ведь тут и посты моментом отправляются, чуть ли не каждую минуту.

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

Майнкрафт показательный пример возможностей джавы. Теперь сравните с майнтестом (с модами не отличишь). Это там где примитивная игрушка с миром 100 в 100 блоков на 8 клиентов хочет 64 гигабайта памяти и топовый процессор на много ядер. Так и везде.

Я не понимаю, вы предлагаете приложения, которые 100000 раз отработают за время пока рантайм джавы загрузится в память, писать на ней?

Пока что всё не связанное с обслуживанием пользователей в браузере (т.е. куча кешируемых данных) в джаве сосёт. У меня есть несколько игрушек (Wakfu скажем), IDE на джаве, несколько клиентов коммерческого софта, глючно-примитивный менеджер загрузок с 100000 кривоватых плагинов, который вечно сам себе на уме... Дотнет может и более тормозной местами, да только он не оставляет стойкого послевкусия говна во рту после использования.

Софт на джаве, это убожество. Слава богу Runescape на плюсы переписали, а то больно было. Больше боли только от Wakfu.

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

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

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

И Java - это не быстрый старт, для быстрого старта как раз таки нужно использовать другие языки. Java - это долгая и эффективная работа, что отлично подходит для серверов. Потому то весь ынтырпрайз и сидит на Java. Дело не только в самом языке, но и в экосистеме - для веба в ней есть всё, что может понадобится. Причём вылизанное за многие годы. А в Go далеко не факт что так.

Иди погугли про то о чём споришь, не позорься.

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

Для веба основная польза от +- эффективного кеширования и относительно нормальных батареек, а не от жита.

19k раз в сутки достать из базы данные и наложить на текстовый шаблон. С этим справился бы даже тормозной питон, ты бы и разницы не заметил.

Зачем мне в ней разбираться, если я ей напрямую пользуюсь. И всё до чего я дотрагивался было полным УГ по всем параметрам. Тем более по производительности.

Какие плюсы и минусы при переписывании легаси на golang?

+ переписано на golang

- переписано на golang

С уважением всегда ваш и.о. К.О.

Сколько не переписывай всё равно потом еще раз переписывать. Думай лучше над архитектурой.

Обвинять технологию, потому что её использует плохой софт - шикарная логика.

За всё время хорошего так и не встретил. А песни про то, что Java быстрее C слышу постоянно.

Спасибо кэп!

Нравится как ты используешь golang вместо go, сразу тролишь нужную аудиторию

Дело не только в скорости. Ты предлагаешь человеку делать веб на C?

Нет конечно. Но лучше го, чем джава.

Там бы прибавилось дополнительное время на чтение скриптов с диска и инициализацию. Между запросом и выдачей страницы - цепочка из вызова тысяч функций и создания хрен знает сколько объектов, поэтому скорость исполнения тоже важна. Если делать ЛОР на PHP/Python, потребуются дополнительные ухищрения с RAM диском, memcached и чем-нибудь ещё. Сомневаюсь, что такое решение потребляло бы меньше серверных ресурсов и было бы проще в разработке.

В контексте данной темы понятно, что автор всего этого уже наелся. Потому вполне логично советовать ему Java, он может взять какой-нибудь Spark и поехать. Или сервлеты + EE сервер, где из коробки горизонтальная масштабируемость без потери транзакций. А потом просто купит докер, через 5 минут его веб-штука будет работать. На любую свою хотелку он найдёт решение.

Конечно можно и на ассамблере писать. Увы, тс не озвучил задачи, поэтому трудно судить насколько обдуманно он подбирает себе инструменты и насколько подходит Go. Может оказаться так, что там будет какое-нибудь специфичное ограничение или не найдётся нужная библиотека. За неимением более подробной информации приходится советовать проверенные временем решения.

чем конкретно лучше, можно обоснованное сравнение?

Быстрее, проще, жрёт в 10-100 раз меньше ОЗУ.

PS: из недавнего https://www.reddit.com/r/rust/comments/8xuv0i/rust_vs_java_for_rest_services/

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

Это нифига не обосновано и там вообще Rust. Вот нормальные бенчи: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html

Как видишь, Go в некоторых задачах проигрывает. А ещё важно сравнить инструментарий: как я уже говорил, для Go может не оказаться каких-нибудь фреймворков/библиотек, или там будут специфические ограничения. ТС подробности не говорит, так что тут пальцем в небо.

Вот как там с кластерами, например? Поверхностное гугление говорит что не очень. А в Java эта технология с лохматых готов обкатана.

Забавный тест.
Но уж оооочень синетический

Соперничать с Си по размеру бинаря не смогли, теперь в сравнении с жирной Жабой будем выдавать это как ПОБЕДУ.
Типичные фанатики раста, лол.

Вот нормальные бенчи

Мы же про веб, а значит «нормальные» бенчи - это https://www.techempower.com/benchmarks/ Но они не учитывают RAM, что выгодно для джавы.

или там будут специфические ограничения

Каких-то специфических ограничений нет