Вот этот момент немного не понял. А почему те же c# и джава тоже в разы быстрее отработали? Это как-то связано с тем, что они интерпретируемые или просто лучшая оптимизация из-за возраста?

2.5 секунды плюсы 34 (!) секунды голанг Задание сгенерировать Бин дерево и посчитать количество узлов для каждой глубины

В целом главная проблема - сборка мусора. Это плата за удобство программирования

Вот этот момент немного не понял. А почему те же c# и джава тоже в разы быстрее отработали? Это как-то связано с тем, что они интерпретируемые или просто лучшая оптимизация из-за возраста?

они не интерпретируемые, а компилируемые в байткод

возможно тут JIT помог

сложнее, чем "компилируемые в байткод"

jit тут помог не быть тормозным

тут два моммента

1. оптимизатор в go довольно убогий. и будет таковым оставаться, ибо для 99% задач, которые решают на go, оптимизатор просто не нужен 2. разница 2.5 и 34 секунды означает только одно - "структура данных плохо влезает в кеш процессора". или большая, или разбросана по памяти, или предсказатель ветвлений ее не понимает. если, например, взять ту же структуру, что использовалась в c++ - разрыв может сократиться

Понял, спасибо)

Надо на код задачи ещё смотреть :)

/report

@onokonem @m0sth8 тут какая то нездоровая хрень у человека творится

Сколько уже спамеров забанили за историю группы?

Сколько уже спамеров забанили за историю группы?

73 штуки

GoFlood?

это не канал )

это не канал )

а что это? O_o

а что это? O_o

чат )

73 штуки

Ты банил?

Коллеги, кто как, свои приложения в продакшен заводит?

Да смотря куда. Если что-то сложное, важное - докер. Для веб-игрищщ завел себе акк не heroku. Деплой идет бинарем через отдельный гит-реп (чтобы основной с кодом не замусоривтаь). 1. компиляю у себя CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o ../project-heroku/bin/app 2. git add . 3. git push heroku master Может не очень красиво, что бинарь в гит кладу, но получается простой быстрый деплой в одну команду make

вендор в корне, бин тоже - норм. Чем плохо?

Bin же должен быть в $GOPATH/bin (вроде)

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

Проверка на err обязательна, так как буфер с энтропией может быть пустым

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

вендор в корне, бин тоже - норм. Чем плохо?

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

Bin же должен быть в $GOPATH/bin (вроде)

Разве обязательно

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

Там в качестве менеджера glide

вендор норм - как раз в отдельной папке все рядом и не лезет по всему проекту

Разве обязательно

А бинари в в репе тебе вообще зачем?

я использую dep (и вроде как он рекомендован для всех новых проектов) - в корне проекта 2 файла Godep.toml `и `Godep.lock - в них описаны все зависимости - так же папка vendor - в ней лежит исходный код проектов нужных версий, согласно файликам. Да. vendor лежит в .gitignore и не коммитится в проект - он нужен только на рабочей машине для сборки

я использую dep (и вроде как он рекомендован для всех новых проектов) - в корне проекта 2 файла Godep.toml `и `Godep.lock - в них описаны все зависимости - так же папка vendor - в ней лежит исходный код проектов нужных версий, согласно файликам. Да. vendor лежит в .gitignore и не коммитится в проект - он нужен только на рабочей машине для сборки

правила хорошего тона требуют закоммитить vendor тоже

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

правила хорошего тона требуют закоммитить vendor тоже

Вот неправда. Там есть плюсы и минусы. А там каждый сам решает.

правила хорошего тона требуют закоммитить vendor тоже

Зачем? На случай, если у нас оторвется внешний источник и мы не сможем больше скачать?

Зачем? На случай, если у нас оторвется внешний источник и мы не сможем больше скачать?

точно. Гит историю ту же можно переписывать

или просто грохнуть проект

сделает умный человек форс пуш и нет коммита

по глупости например

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

но это конечно сложнее

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

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

Каждый проект форкать такое себе. Да и в случае если ты не один работаешь, то нужно акк компании на гитхабе делать?

Не обязательно. Мне никто не запрещает сделать бесплатный публичный форк открытых проектов на GH. А дальше в своей закрытой репе, которая вообще лежит даже не на ГХ я импортирую нужные мне зависимости. go get и dep штуки умные - они без проблем мне вытаскивают все нужное из разных источников.

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

Не обязательно. Мне никто не запрещает сделать бесплатный публичный форк открытых проектов на GH. А дальше в своей закрытой репе, которая вообще лежит даже не на ГХ я импортирую нужные мне зависимости. go get и dep штуки умные - они без проблем мне вытаскивают все нужное из разных источников.

Вот сделал ты форк. И ушел из компании. И решил форк удалить.

только что ответил )

кстати, если я правильно помню, удаление оригинальной репы ведет к удалению всех форков

для публичных беслпатных?

тогда можно неаккуратно полгитхаба разломать

придет очередной leftpad - и карачун гитхабу ) Вобщем это надо проверить, уж очень рискованная вещь. Может это как-то лицензией регулирутеся?

кстати, если я правильно помню, удаление оригинальной репы ведет к удалению всех форков

нет конечно ?

Для закрытого кода компании можно сделать локальные копии реп и в них отдельный upstream на внешний репозиторий. Периодически затаскиваешь свежий код, мерджишь, проверяешь. Тогда ты вообще не зависишь от GH и что там снаружи происходит. У тебя всегда один и тот же реп по одному и тому же адресу. Даже если у тебя в твоем проекте сделан lock на master (гы), то все равно, мастер не будет спонтанно меняться (ну в надежде, что отвечающие за это люди адекватны и изменения зависимостей обсуждаются перед тем как их ломать).

или можно просто закомитить vendor

мусор в репе будет копиться

периодически его чистить

ERROR: S client not available

ну и будет ну и что

куча левых коммитов

Это мешает смотреть изменения.

Это мешает смотреть изменения.

если иметь культуру все vendor изменения отдлельным коммитом - то должно быть ок

Если я хочу посмотреть изменения в ветке?

Т.е. приходит merge request. И нужно ревью сделать, например.

берешь и смотришь)

github очень клево vendor/* скрывает по-умолчанию

(потому что там обычно дофига всего)

Гитхаб да.

Не так уж часто в MR обновляются зависимости. А если обновляются, то да, нужно сделать ревью

В файлах dep и так отображается, что они изменились. Или мне ещё и коду зависимостей ревью делать?

В файлах dep и так отображается, что они изменились. Или мне ещё и коду зависимостей ревью делать?

пропускаешь их, если считаешь что это ревьюить не надо

Ну так не все веб интерфейсы скрывать позволяют.

повод написать фичареквест автору

или даже pull request

Ну фронтенд писать я пока не собираюсь.

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

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

Я бы с удовольствием сменил наш гит сервер. Но это слишком болезненно.

Я бы с удовольствием сменил наш гит сервер. Но это слишком болезненно.

Почему?

Ну там и куча задач и история. И документооборот. И все нужно для аудита.

Ну там и куча задач и история. И документооборот. И все нужно для аудита.

А что за продукт используете? Не GitLab?

напомните плз, куда уходить с `gopkg.in/mgo.v2`?

напомните плз, куда уходить с `gopkg.in/mgo.v2`?

можно сюда https://github.com/globalsign/mgo

Вот еще на эту тему: https://engineering.mongodb.com/post/considering-the-community-effects-of-introducing-an-official-golang-mongodb-driver

Приветствую! Может и не в профильный чат, но вопрос актуальный. Как удалить куку при 403 ответе?) Set-Cookie не отрабатывает, походу

Приветствую! Может и не в профильный чат, но вопрос актуальный. Как удалить куку при 403 ответе?) Set-Cookie не отрабатывает, походу

вернуть клиенту 403 и удалить у него куку?