Не понимаю твоего начальства. У Го совершенно иная ниша. Большие проекты порталы - PHP/Java/C#, ибо архитектуру нормальную построить проще, инструменты сборки адекватные. Ща тут смузисосы набегут конечно, но ты послушай хорошего совета.

Компания написала крупный проект и пришла на ЛОР советоваться про переписывание. ЛОР пришел к успеху! Или...

У Rust есть Servo, который достаточно крупный. Для инфраструктурных проектов Rust пока молод и если и есть, то где-то в pet-projects «на посмотреть». Go таки постарше в плане первого «стабильного» релиза будет.

Не понимаю твоего начальства. У Го совершенно иная ниша. Большие проекты порталы - PHP/Java/C#, ибо архитектуру нормальную построить проще, инструменты сборки адекватные. Ща тут смузисосы набегут конечно, но ты послушай хорошего совета.

Дело в том, что можно отказаться от переписывания на Go. Но для этого нужно привести серьезные аргументы. Тут я бы и хотел их получить. Python многим в нашей команде (главным образом начальству) не нравится. А основным вариантом для переписывания все равно видится Go т.к. на нем уже написаны отдельные части.

Компания написала крупный проект и пришла на ЛОР советоваться про переписывание. ЛОР пришел к успеху! Или...

Я все-таки не компания

Ну куда же теме про Go без Docker'a. Других проектов правда нету, но ничего.

Ну куда же теме про Go без упоминания, что кроме Docker'а ничего нету. Правда, Golang уже в десятку топа на Github вошёл, но ничего.

https://octoverse.github.com/

Когда вы там обанкротитесь черкни пару строк на этот форум.

Эта статистика очень специфичная. Хз как её считали.

К примеру у go 20k звёзд, а у раста 18k. О чём это говорит? Почти ни о чём.

Рекомендую завалиться на golang-ru.slack.com

Я когда с python начал перелязать там очень помогли.

А вопросы походу у вас те же что и у меня возникли. В принципе можно фигачить все внутренние части микросервисами, связать их с помощью consul. Это если о глобальной архитектуре, а внутреннее устройство это отдельная тема. В любом случае рекомендую заглянуть на golang-ru.

Ща тут смузисосы набегут конечно

Большие проекты порталы - PHP/Java/C#

Да вот один уже набежал :)

slack.com

Почему в этом упорине? Зарегистрироваться там тот еще геморрой

Точнее, я зарегистрировался, но так и не понял, как туда войти

Разобрался — http://4gophers.ru/slack

ну и тупизм

Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?

Переписывание на другой язык обычно не приводит у ускорению, ибо тормоза в архитектуре/кривых запросах/кривых руках и т.д. Скорее всего (тем более без опыта разработки на го) вы получите точно так же тормозящее поделие.

Время стоит потратить не на переписывания а на оптимизацию.

</thread>

Притон безумных хипстеров-фанатиков этого недоязычка.

Да начнётся err-срач

• Получаем эксепшон в неожиданном месте:

  plug()
  pray_there_werent_any_unexpected_exception()
  

• Постоянно ходим в документацию (точнее, исходники) и имеем ломающийся софт при изменениях в библиотеках ( Darth_Revan не даст соврать, было)
• Берем go и наслаждаемся очевидным и явным способом обработки ошибок

  err := shootInLeg()
  if err != nil {
    checkNumberOfLegs()
  }

• И тем, что не нужно на каждый чих лазить в доки. err — он и в африке err, а вот знать, что из функций может генерить какой-нибудь IoException — нужно иметь доки перед глазами.

Вместо резюмирования процитирую свой комментарий

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

Точнее, я зарегистрировался, но так и не понял, как туда войти

Кхм. Команда, логин, пароль.

Сегодня это для командной разработки почти такой же стандарт де факто, как github для хранения реп :)

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

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

Вообще-то, у нормальных людей все наоборот: аргументы требуются на то, чтобы потратить ресурсы, а не на то, чтобы съэкономить.

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

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

Там нужно было получить инвайт на почту через левый сайт

А, чтобы в чужую команду попасть — да, нужно приглашение. Это главный минус Slack — отсутствие гостевого доступа.

Да, твой «надежныи кот)))» разобьется о первый же panic из рантайма языка/стдлиб.

И поймается через recover

Но суть в том, что if err != nil { return err } эксепшны делают за тебя при развертке стека. Потом можно отловить на самом верхнем уровне, а не загромождать код, как goвно-луддиты.

И страдать с неявностью на первом уровне (фактически, onerror goto получается, лол), обмазываясь костылями вроде with

Я уже устал считать, сколько раз я слышал эту мантру в коммьюнити goвна.

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

Давай лучше посремся про генерики, бгггг.

А шо генерики? Их отсутствие решают кодогенерацией и interface{}. И мне вполне хватает.

Так что пока не придумали, как нормально в билд-тайме их сделать, можно пользоваться https://github.com/cheekybits/genny и https://github.com/joeshaw/gengen

Пишите на C++1z.

Как будто выразительность и лаконичность это всегда что-то хорошее и мастхев

Сразу вспоминается недавнее <*-*> с хабра из скалы

Таки для

if err != nil {return x, err}

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

Лично я в этом ничего плохого не вижу, обязательные точки с запятой сильно, сильно хуже

Правда, Golang уже в десятку топа на Github вошёл

Обогнал shell и почти догнал Си. Успех.

как github для хранения реп

gitlab же или bitbucket

Не парьте мозг и берите Java. Go хорош для тулинга и микросервисов, это его ниша.

И поймается через recover

Т.е. эксепшны переизобрели.

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

Пишу на нем третий год, привкус говна не пропадает. Я недостаточно сильно молюсь Пайку?

решают кодогенерацией и interface{}

Привет из 90-х от жавашников/скриптопараша. Не понимаю, каком говноедом нужно быть, чтобы это нравилось.

И страдать с неявностью на первом уровне (фактически, onerror goto получается, лол), обмазываясь костылями вроде with

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

Да? А я орм для моделей данных использую и пагинации

как github для хранения реп

gitlab же или bitbucket

Не... Если по аналогиям, то bitbucket — это hipchat, а gitlab — это kandan или mogochat.

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

Сначала определись, что ты разрабатываешь: лаунч программу SpaceX или андроид приложение для ИП Васяна. Во втором случае с бюджетом в 15К руб. ты не будешь делать тесты и обрабатывать все ошибки.

Это две крайности. Спектр Go ближе ко второй крайности и очень далек от первой. Поэтому без возможности прокинуть ошибку вверх ты будешь ставить заглушки, которые будут засирать твой код. Если Васян еще докинет 15К руб. можно детализировать обработку ошибок и дописать тесты. Правда я не знаю как ты будешь объяснять Васяну на что ушли 15К руб. и так работающему приложению.

Дело не в крайностях, а в том как нужно делать в том или ином языке программирования, в Go принято возвращать ошибки (если я не прав - поправьте) и этот подход обоснован и имеет свои плюсы, другое дело, что авторы не придумали способа делать это более лаконично, что бы весь код не превращался в месиво if err != nil...

. Всего база данных состоит из ~200 таблиц.

Это не крупный проект. Это средний.

Далее уже в нашей компании поставленный нам проект стал дорабатываться и постепенно переписываться с Python 2 на Python 3 и затем Python 3.5 (3.5 из-за лучшей поддержки асинхронной работы).

Есть мнение, что основная проблема в этом. Вы взяли проект написанный не вами - и начали его непрерывно переписывать. Естественно после такого получили текущий результат. ИМНО от переписывания на GO лучше не станет - проблема в голове, а не в питоне. Нормальных программеров (а не пионеров и т.п. хипстеров) на Питоне, намного больше. Есть мнение, что занявшись профилированием и выявлением узких мест производительность поднять проще, чем по пиоенрски «все нах переписать».

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

Странный какой-то менеджмент уровня «надо только выбрать правильный язык, а все остальное само придет». Последний питон, да еще и с asyncio, не может просто так тормозить. Переписывание не даст никакого прироста, вы же узкоспециализированы по питону сейчас, только время потеряете. Очевидно, проблемы в архитектуре приложения или БД.

Пфф, давай расскажи мне почему?

В компании где я работаю сейчас (это очень крупная компания на рынке США), используется пхп, недавно переехали на седьмую версию, и после небольших изучений профиля профилировщика мне удалось добиться производительности TTFB <= 130ms, учитывая, что там спереди еще php-fpm, nginx, load balancer, с сзади БД. Как видишь, для веб-приложения овер-быстро. А в пхп сейчас всё очень хорошо для мейнстрима: 1) Классическое ООП (с некоторыми отличиями от модели Java/C#) 2) Опциональная, строгая типизация (проверка аргументов, возвращаемых значений). 3) Большая база библиотек 4) Очень хорошая производительность, серьёзно, я был на последнем код-фесте, где выступал один из разрабов ядра, они проделали огромную работу по ускорению движка.

И это ещё не предел. Уже над JIT начали работать.

Лорчую. Надо переписать всё с питона на php. Это же энтерпрайз. Да и ООП классическое. На худой случай на perl6.

Опциональная, строгая типизация

В питоне строгая типизация не опциональная. И есть аннотации типов(давно в виде докстрингов, теперь и в самом синтаксисе).

Но ты, конечно, перепутал strong/weak typing со static typing(точнее type annotations потому что static typing опциональным быть не может).

Каюсь, перепутал, static типизация, да. Под аннотациями ты имеешь ввиду, что сам интерпретатор на них смотрит или это только для IDE? Я не агитирую переписать всё на PHP, у меня просто есть личный опыт с этим языком и есть его применение в крупном проекте, который разрабатывается командой разработчиков и получается нормально, вот. Лично я предпочитаю шарп, например.

А где плюсы языка-то? Или они переделали стандартную библиотеку функций, да и вообще переписали весь язык, выкинув всё из 200Х? Нет? Не нужно от слова СОВСЕМ!

что сам интерпретатор на них смотрит или это только для IDE?

Сам интерпретатор(дефолтный cpython по крайней мере - у питона несколько интерпретаторов в т.ч. с JIT, которые могут это использовать в перспективе) - нет. Но смотрят ide и специальные утилиты типа http://mypy-lang.org/ (последняя пока не переваривает код с async/await, так что, толку он неё пока мало, но в php async/await нет вообще же(?)).

Как будто async/await в питоне чем-то лучше, чем отсутствие такового

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

«Мне не нужно бежать быстрее медведя», а назвать языки которые лучше php проблем не составит и так сложилось исторически ибо обратная совместимость и автор языка решил поиграться и написать библиотеку, а не разработать полноценный язык. К чему я это всё пишу, прекратите насиловать труп, я не вижу не одного сценария будущего, где php жил долго и счастливо

P.S а вы можете использовать его сколько угодно и зарабатывать деньги, только не нужно его предлогать другим ибо это путь в никуда, у меня всё :)