на расте потому-что экзабайты :)

В этих статьях вроде не объясняется почему.

https://news.ycombinator.com/item?id=11283688

^ вот тут рассказывают

"Однако объём памяти, который требовался Magic Pocket для работы, когда система была реализована на Go, оказался слишком большим для промышленной системы такого масштаба." 😁

у го есть гц и не самый оптимальный компилятор

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

сказать чтобы systemd перечитал конфиги и в sys/fs/cgroup все что нада позарегивал )

> The project also has a fair amount of FFI work with various C libraries, and a kernel component

хм, go отличный когда много io, на числодробилках он не очень, вот еще мнение есть http://blog.asciinema.org/post/and-now-for-something-completely-different/

> No need for concurrency or high speed here

но при выборе тулы Go vs Python я бы взял ту что на Go

но при выборе тулы Go vs Python я бы взял ту что на Go

это уже религиозное

нет, это практичность

?

я не люблю сношаться с питон зависимостями

я не люблю сношаться с питон зависимостями

не сношаюсь, что Я делаю не так?

может не ставишь сторонний софт на питоне или ставишь мало

может не ставишь сторонний софт на питоне или ставишь мало

много ставлю, мало того, еще и основной язык для своих тулов

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

и ты думаешь что их нет, а они есть

и ты думаешь что их нет, а они есть

а вот и религия

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

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

единственная “проблема” которая была — использовать python 2.6 для проверки совместимости своего тула

решилось в 2 команды в консоли

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

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

что за проблема? расскажите

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

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

что за проблема? расскажите

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

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

не очень понимаю зачем это для тулинга

нет, это практичность

больше похоже на любовь к хреновым решениям )

единственная “проблема” которая была — использовать python 2.6 для проверки совместимости своего тула

как мне без докера, быстро собирать питон проект ?

когда там тонна реквайроментсов компилируемых

для серверного софта – понятно, но сейчас и серверный код в изолировнаных средах живет часто (Docker/виртуалки) и его и так надо обновлять по отдельности

как мне без докера, быстро собирать питон проект ?

эм, Я ничего не говорил про демоны и проекты

Андрей а вы питонолюб или просто go-фоб?

мы говорили про выбор тулы

всмысле ?

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

всмысле ?

> но при выборе тулы Go vs Python я бы взял ту что на Go

Андрей а вы питонолюб или просто go-фоб?

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

а, вы все в контексте аскинемы

тогда не интересно )

все с вами Андрей понятно

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

на го попроще будет, ага %) просто ни нампая ни пандас нету, вот и не будет тулы

а у меня тула требует brew install <tool> yum install <tool> apt install <tool> emerge <tool>

а не ебатню с зависимостями

ну да, когда нет зависимостей и еботни с ними нет

Есть термин dependecy hell или dll hell

Про статик линкинг хелл не слышал

интересно почему так

на го попроще будет, ага %) просто ни нампая ни пандас нету, вот и не будет тулы

там ща линкуют блас и лапак сишные прямо в го и хуярят через них )))

там ща линкуют блас и лапак сишные прямо в го и хуярят через них )))

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

Есть термин dependecy hell или dll hell

и это не про топик. очевидно же, что питоны надо стаивить в virtual env и ко. а если рассматривать dependency hell в рамках одной тулзы, то у го тут все ровно так же как у всех (только хуже :) )

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

а я сказал про сайнтистов а не аналитиков ) Но согласен вцелом )

а, вы все в контексте аскинемы

без контекста такие обсуждения не релевантны

virtualenv не решает проблему с системными C-зависимостями, которых в питоне овер дофга

да venv ничо не решает

илююзия безопасности

ну без него хуже все-таки

хуже.

virtualenv не решает проблему с системными C-зависимостями, которых в питоне овер дофга

ну вот. а тут возвращаемся к вопросу о том, что нет библиотеки — нет проблемы )

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

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

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

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

да бросьте, вон вим энхенсед поставьте )

посомотрите зависимости ) так, везде.

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

какой кейс? все от гит-коммитов зависимости ставят, чейнжлогов не существует

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

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

если мы тут про пользователя говорим, то для него интерфейс сводится к docker run, что с питоном, что с го, что с кложурой

парни а как получить топ сисколов приложения ?

топ 10 например

https://github.com/p8952/bocker

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

https://github.com/p8952/bocker

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

не заменит но все равно забавно )

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