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

расширшу вопрос.
что будет, если я shell скрипты перепишу\начну писать на го? cast jollheef, вот в твоей appvm даже греп через os/exec делается, что если стопицот строк таких будет, а го только как удобный if else и человеческие хеш таблицы?
за такое будут бить?

Какие плюсы

Никаких

минусы

Твое go'вно соберется только там, где найдется go соответствующей версии.

что будет, если я shell скрипты перепишу\начну писать на го? cast jollheef, вот в твоей appvm даже греп через os/exec делается, что если стопицот строк таких будет, а го только как удобный if else и человеческие хеш таблицы?

Не могу сказать, что это хорошо, но как временное решение сойдет. В процессе переписывания с bash подобное и появилось, к слову.

за такое будут бить?

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

Твое go'вно соберется только там, где найдется go соответствующей версии.

Ты так говоришь, как будто код на python 2.7 будет работать на python 2.4, а код на c11 внезапно начнет собирать компилятор без его поддержки. Глупость в общем сказал.

Настоящий минус — это нестабильность библиотек в среднем. Нужно либо делать vendor, либо выбирать только из тех, разработчик которых поддерживает стабильные api (import "....com/...blabla.v4" и так далее).

Ты так говоришь, будто с кодом на баше могут быть проблемы. У него есть неоспоримое преимущество: он запустится и отработает быстрее, чем остальные. А что ещё от скриптов надо? Да к тому же если не злоупотреблять спавном процессов и использовать башизмы повсюду, то он ещё и быстрый и не требовательный до ресурсов.

если не злоупотреблять спавном процессов

нафига он тогда вообще нужен? это запускалка программ. шаг влево и привет write-only нетестируемый код бред на 500 строк.

С чего переписывать то?

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

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

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

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

У него есть неоспоримый недостаток: лапша на shell/bash является write-only.

А что ещё от скриптов надо?

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

а можно узнать почесу именно го? просто для shell скриптов раз уж переписовать то питон лучше подходит. ИМХО

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

Ты никогда не пробовал деплоить любой питонячий софт?

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

пробовала, у меенч всё проходило нормально

С чего?

Если, допустим, с Питона — то:

+) Проект будет написан на более приличном языке

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

Минусы: вы потратите на это время.

Плюсы: вы прикольно проведёте это время, а если за это ещё и платят, то совсем хорошо.

Как-то переписывал фильтры для postfix с python на go.

Плюсы: получил за это денег на upwork. Минусы: потратил деньги на пиво и сигареты.

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

Perl

Легаси на Perl. Устаревшая архитектура и платформа.
Уперлось в сложности развитием и сопровождением.
Так же говорят, что сложно искать участников.

c Perl5 родом из начала 00-х

приличный язык

боюсь спрашивать, но всё-таки, какой порекомендуешь?

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

В зависимости от того что за легаси.

Если с питона или перла - получишь компиляцию в бинарь, производительность и возможно чуть более причёсаную базу кода.

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

Граблей много, особенно если с динамически типизированного языка переписывать

Так точно. С динамического.

Граблей много,

А есть какие-нибудь примеры?

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

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

что будет, если я shell скрипты перепишу\начну писать на го?

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

Тогда уж руст. И заменить тебя будет не так просто.

Почему go? Единственная плюшка - неплохая концепция и реализации конкурентности(CSP на стероидах). А так язык очень бедный и сильно склоняет к копипасте.

Ну, в принципе, зависит от задачи, но, по умолчанию, предложил бы Scala. Или Haskell, если храбрые.

Из личного опыта:

Обработка json от 1с, но тут основная пробелма в 1с, конечно. ORM вот еще, если в случае с монгой не чувствуется, то с постгрисом не очень удобно.

Но это все очень субъективно, зависит от проекта и человека, который будет переносить. Может тебе в кайф писать километры кода, с 1ской ты не работаешь, только если в перчатках, а орм только все портит.

Но го - не плохой выбор, как по мне.

Если с цепепе - то плюсов больше, чем минусов :-) Ведь Go затем и был сделан, чтобы заменить собой цепепе :-)

А что не так с json и orm?

Личный опыт, что вызывало боль. Возможно, сам дурак и не разобрался, но orm под го нет, в общем-то и не нужно, но вдруг кому нужно. а json от 1с, может быть невменяемый и каждый раз разный, замапаить такое в струкруту - дело не тривиальное.

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

но orm под го нет

А где есть?

Обработка json от 1с, но тут основная пробелма в 1с, конечно

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

а json от 1с, может быть невменяемый и каждый раз разный, замапаить такое в струкруту - дело не тривиальное.

Не понял, ты лезешь в результат сериализации прикладных объектов?

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

Это неправда. Ничего, сейчас я тебе докажу обратное, что Go был задуман как замена C++:

In later interviews, all three of the language designers cited their shared dislike of C++ as a primary motivation for designing a new language.

Вот тебе ссылка, ознакомься.

строуструпу не понравился смалталк и он придумал С++ как замену ему?
то что кому то не нравится С++ и он придумал гоу еще ничего не доводит

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

Зачем вообще что-то _переписывать_? Оно работает? Пусть работает. Оно не работает? Почини. Нужно написать новый софт/скрипт? Вот тогда и бери новый хипстерский язык из топ-5 модных язычков и пиши на нём. А то по такой логике придется каждые полгода переписывать, сначала на Go, потом на Rust, потом на Dart, а потом, не довели б_г, и на javascript захочется!

строуструпу не понравился смалталк и он придумал С++ как замену ему?

Неверно. Страуструп захотел писать на C как на Simula. Так и был придуман C++.

то что кому то не нравится С++ и он придумал гоу еще ничего не доводит

Я не понял эту фразу, но конкретно Go был задуман как замена C++, а не как замена Python или Ruby, о чём всему миру сообщили сами создатели Go. Все остальные байки, легенды, догадки и домыслы анонимных пользователей не интересны.

Но почему-то получилось заменить только какую-то вебню нелепую типа rest api.

Я не понял эту фразу, но конкретно Go был задуман как замена C++, а не как замена Python или Ruby, о чём всему миру сообщили сами создатели Go. Все остальные байки, легенды, догадки и домыслы анонимных пользователей не интересны.

«Человек предполагает, а Бог располагает».

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

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

Но почему-то получилось заменить только какую-то вебню нелепую типа rest api.

Ещё Docker с Kubernetes написать получилось.

Каждый из нас пытается закопать плюсы по мере своих сил. Эти ребята делают так :)

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

Не глупость. Далеко не везде использование C++ без GC оправдано и в каких-то случаях C++ может быть успешно заменен языком с GC. Что и имело место быть в тех Google-овых проектах, в которых C++ использовался и на которые смотрели авторы Go.

Яркий пример такого рода от другой крупной корпорации: ядро Visual Studio было переписано со временем с C++ на .NET (хотя нативный код в плагинах остался до сих пор).

Поэтому история развивалась именно так: авторы Go стали делать новый язык на замену C++ и Java, которые широко использовались в Google, и которые показывали себя не очень хорошо в проектах с большим количеством разработчиков. Сделали. Но потом с удивлением обнаружили, что в Go массово переходят со всяких Python-ов, а не с C++. Об этом сам Пайк писал несколько лет назад.

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

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

Лол :-) Расхотеть изучать язык по книге, за которую сам же заплатил, из-за предисловия - это, конечно, сильно :-) Ахаха :-)

После того, как ты уже купил книгу, вряд ли кому-либо интересно, что ты думаешь о книге, о её предисловии или о Go в целом :-)