Проблема тут в том, что ARC это не что-то новое, а это те самые release/retain. В буквально смысле они. Если открыть в дизассемблере бинарник, то там будут вставлены эти самые вызовы как если бы их вставил программист. И суть проблемы в том, что ARC никак не устраняет механизма autorelease pool и вообще это две не связанные между собой вещи. Конструктор
stringWithFormat
добавляет объект в этот пул как это обычно делается в таких случаях, поэтому в этом цикле память не будет освобождаться и будет бесконечно расти. Понятное дело почему — объекты в пуле освобождаются только в момент освобождения пула. Если тело цикла обернуть в
@autoreleasepool
то проблема будет решена. Точно так же, как это было до ARC, потому что механизм работы с памятью никак не поменялся с тех пор. Опять же, открыть в дизассемблере ARC код и там будут почти теже самые autorelease pool.
Проблема так же будет решена, если использовать связку alloc и init методов. В этом случае пул не используется, а значит ARC вставит вызовы для освобождения памяти внутри тела цикла.
Поэтому ARC и полностью совместим со старым кодом — он не меняет правила игры.
Если бы все было так замечательно, то мы бы жили в прекрасном мире. На деле же даже сборка маленькой библиотеки с makefile и autoconf это пытка. Я недавно собирал под виндой с помощью кросскомпилятора libevent. Я задолбался вручную патчить сгенерированные мне makefile и configuration. В итоге еще и пришлось патчить хедеры openssl, но собралось. А должно собираться в один клик — git clone, build и все, все работает. Можно сказать — винда, проблемы вечные. Я потом пытался собрать crosstools-ng под макосью — я так и не смог это сделать под yosemite. Постоянные ошибки, которые кое как решались. Но в конце появилась одна, которую решить так и не получилось. Никакие решения в интернетах не помогали. Большое спасибо, что хоть кто-то выкладывает готовые сборки хотя бы для макоси. Кто-то еще понимает, что make это не так просто и безболезненно. Даже под теми ОС, под которыми это типа должно без проблем собираться.
Благо все таки есть проекты, которые умеют собираться. OpenSSL у меня оставил вполне хорошие впечатление будь это сборка под windows для linux arm или iOS. Да, я сейчас в основном упомянул С проекты. Но тут разницы мало в этом контексте.
А про модули знаю, но это не решит проблему legacy кода.
C++ лучший в своем классе скорее вопреки, а не благодаря. И я буду очень рад, если его заменит что-то, что нормально умеет в модули, быструю компиляцию, простую кросс компиляцию без бубнов и мегабайтных мейкфайлов. Это как минимум. Где-то его Go уже вытесняет отчасти именно благодаря упомянутым вещам, но хотелось бы вообще забыть об этом языке в пользу чего-то более умного с умной и быстрой инфраструктурой.
Так что утверждение «Компиляция под любую платформу одной строчкой» выглядит чересчур самоуверенно.
Тут скорее то, что имеет значение распространено, а как уже в одной статье говорилось, мир захватили x86-x64 и arm. С первым проблем нет, со вторым покрыты архитектуры armv5-armv8, что дает ощутимый кусок. Вот на этом всем go скорее всего без проблем будет работать при условии, что там ОС стоит совместимая.
mips-none-eabi? arm-none-eabi? Не собирается почему-то.
MIPS вроде и не поддерживает, а арм. А какой именно арм то? Под armv7 я собирал — linux версия работает на андроиде и кастомной плате с cortex-A8 процессоре. armv7 версия под darwin при условии external linkining и CGO работает на iOS, но зависит от парочки системных API, которые не делают погоды. Речь естественно о сборке Go проектов, а не самого Go.
Ага, разогнались.
Это не лучший пример. Если посмотреть исходный код, то там вовсю используется CGO, а там можно накрутить кучу зависимостей, что они и сделали. Сам по себе Go на моих проектах выдает бинарники, которые ни от чего не зависят. Сейчас проверил gitlab раннер для их CI под макось gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/osx.md — опять пустая импорт секция. Что не удивительно, ибо это одно из преимуществ GO.
Честно, не пробовал. Ну и проблема не в том, что рантайм прям мешает — на винде ради бога. Но вот у меня линукс на арме. Какие у меня там варианты с дотнетом кроме сборки руками моно или .net core?
Зачем Go? Меня лично привлекает совокупность его особенностей:
1. Компиляция под любую платформу одной строчкой. GOOS, GOARCH и вперед — винда, макось, айфон, андроид.
2. Натив код + сборщик мусора
3. Один бинарник и ноль зависимостей от компонентов ОС. Это просто прекрасно, когда ты открываешь в IDA импорт секцию и видишь пустой список. Бинарнику нужны только syscall'ы и больше ничего. Есть исключения разве что на винде и iOS. И то, это зависимости от API ОС.
4. Огромная стандартная библиотека + простейшая процедура подключения сторонних библиотек
5. Горутины
Все остальное так или иначе вносит сложности. С/С++ — ад с кроссплатформенностью, компиляцией, сторонними библиотеками, асинхронностью и т.д. .Net/Java — все хорошо, но рантайм за собой тянуть как зависимость и его оверхед по памяти как минимум. Скриптовые языки — тянуть за собой интерпретатор + оверхед по всему подряд.
Go расположился во всем аккурат между С/С++ и C#/Java и этим он привлекает. И тут скорее не язык сам интересен, а инфраструктура вокруг него, которая, впрочем, благодаря особенностям языка и стала возможна.
Что нельзя реализовать в Go имеющимся набором стандартных и дополнительных библиотек?
С учетом CGO это вообще отпадает по определению. Вкомпилить можно что угодно. Даже для C++ есть вариант.
Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?
В данном случае GO не имеет к этому никакого отношения. А .Net и Java всегда будут иметь проблему в виде рантайма.
А назовите, пожалуйста, причину, по которой тот же докер выбрал Go? Я из их презентаций не слышал киллер фичи, из-за которой он был выбран. И складывается как раз ощущение, что был выбран, потому что модно и интересно, а потом внезапно взлетело. Сам докер то внезапно взлетел, в его success-story не видно никакого планирования долгосрочного. Была внутренняя утилита, переписали для народа — внезапно взлетело.
Мне кажется это скорее вы с самого начала не поняли человека. Я прекрасно понял, о чем он говорил изначально. Меня самого парит докер этим — уже упомянутые маппинги портов залочены за контейнером, их нельзя менять не удаляя и пересоздавая его. По крайней мере, я не знаю такого способа. Хотя, казалось бы, вот тебе JSON'чик со всеми конфигами. Бери да меняй. К слову, автозапуск я так вручную и добавлял туда, и все работало.
И опять вы свернулись в клубок и выпустили иголочки. Никто на вашего Пайка не наезжал. Я всего лишь заметил, что он тот еще троль. Что тут говорить, я так же отвечал вам, когда мне надоело уже видеть непробиваемое фанбойство.
Почитайте тред. Он начинается со слов «Новый Холивар», в котором Пайк, который относится к программистам, не любящих подсветку синтаксиса, в духе треда и ответил, и вполне невинно.
Я бы это вам посоветовал, ибо так нагло врать нехорошо. Никто там про хиловары не заикался. А Пайк всего лишь пришел и вбросил, больше ничего он не добавил в ту беседу.
Только недавно читал про подсветку синтаксиса для Go groups.google.com/forum/#!topic/golang-nuts/hJHCAaiL0so, где Пайк кидался только шуточками и язвительными комментариями в духе «подсветка синтаксиса для детишек, я выше этого». В итоге пришел еще один человек из команды Go и заткнул рот тем, кто начал катить бочку на Пайка за такой настрой. Замечательная атмосфера просто.
Syntax highlighting is juvenile. When I was a child, I was taught
arithmetic using colored rods I grew up and today I
use monochromatic numerals.
Странно, а технический директор этой компании считает иначе. И раз уж мы заговорили о вопросах правильного менеджмента, спрошу, а у вас сколько максимальная команда была под вашим управлением?
Аргумент «сначала добейся» начинает уже утомлять. Что не пост от вас, то одно и тоже.
А что решает? Расскажите.
Хороший менеджер.
Да нет, не додумаются. Куда им.
И я так думаю. Поэтому ждем, когда они разочаруются в Go и перейдут на новую модную технологию. Что у нас там на повестке дня?
И после таких комментариев вы еще кого-то упрекается за тон.
Язык инструмент решения задачи, но не инструмент решения проблем менеджмента. Статья не имеет никакого отношения к «Если есть язык, который людям больше нравится и подходит под задачи лучше — почему бы последовательно не перейти на него, особенно если позволяют сроки/планы»
Только переход на Go это не прогресс, по крайней мере не в их случае. Это попытка прикрыть реальную проблему — менеджмент. Они начали писать на Scala без явного понимания, как это потом все поддерживать. Дошли до критической массы, когда проблемы уже не подъемные — перешли на Go. Последний никак не решает проблемы, которые есть у этой команды. Он лишь немного помогает в этом контексте, но в конечном итоге все проблемы этой команды приведут к тому, что и Go код они больше не смогут поддерживать. Опять переходить на что-то другое и переписывать с нуля? Или может додумаются, что проблема не в технологиях?
Такое ощущение, что вы боретесь не с причиной, а со следствием. А причина — изначально плохая архитектура. Один bool вариант в StreamReader/StreamWriter покрывает все, что необходимо от этого класса — закрыть или не закрыть стрим, который ему дается. Больше он ни о чем думать не должен. Код снаружи должен сообщать, может ли стрим использоваться где-то в другом месте или он еще занят. Уже изначально такая проблема намекает, что где-то что-то не так и IDisposable тут совсем не при чем.
то проблема будет решена. Точно так же, как это было до ARC, потому что механизм работы с памятью никак не поменялся с тех пор. Опять же, открыть в дизассемблере ARC код и там будут почти теже самые autorelease pool.
Проблема так же будет решена, если использовать связку alloc и init методов. В этом случае пул не используется, а значит ARC вставит вызовы для освобождения памяти внутри тела цикла.
Поэтому ARC и полностью совместим со старым кодом — он не меняет правила игры.
Если бы все было так замечательно, то мы бы жили в прекрасном мире. На деле же даже сборка маленькой библиотеки с makefile и autoconf это пытка. Я недавно собирал под виндой с помощью кросскомпилятора libevent. Я задолбался вручную патчить сгенерированные мне makefile и configuration. В итоге еще и пришлось патчить хедеры openssl, но собралось. А должно собираться в один клик — git clone, build и все, все работает. Можно сказать — винда, проблемы вечные. Я потом пытался собрать crosstools-ng под макосью — я так и не смог это сделать под yosemite. Постоянные ошибки, которые кое как решались. Но в конце появилась одна, которую решить так и не получилось. Никакие решения в интернетах не помогали. Большое спасибо, что хоть кто-то выкладывает готовые сборки хотя бы для макоси. Кто-то еще понимает, что make это не так просто и безболезненно. Даже под теми ОС, под которыми это типа должно без проблем собираться.
Благо все таки есть проекты, которые умеют собираться. OpenSSL у меня оставил вполне хорошие впечатление будь это сборка под windows для linux arm или iOS. Да, я сейчас в основном упомянул С проекты. Но тут разницы мало в этом контексте.
А про модули знаю, но это не решит проблему legacy кода.
Тут скорее то, что
имеет значениераспространено, а как уже в одной статье говорилось, мир захватили x86-x64 и arm. С первым проблем нет, со вторым покрыты архитектуры armv5-armv8, что дает ощутимый кусок. Вот на этом всем go скорее всего без проблем будет работать при условии, что там ОС стоит совместимая.MIPS вроде и не поддерживает, а арм. А какой именно арм то? Под armv7 я собирал — linux версия работает на андроиде и кастомной плате с cortex-A8 процессоре. armv7 версия под darwin при условии external linkining и CGO работает на iOS, но зависит от парочки системных API, которые не делают погоды. Речь естественно о сборке Go проектов, а не самого Go.
Это не лучший пример. Если посмотреть исходный код, то там вовсю используется CGO, а там можно накрутить кучу зависимостей, что они и сделали. Сам по себе Go на моих проектах выдает бинарники, которые ни от чего не зависят. Сейчас проверил gitlab раннер для их CI под макось gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/osx.md — опять пустая импорт секция. Что не удивительно, ибо это одно из преимуществ GO.
1. Компиляция под любую платформу одной строчкой. GOOS, GOARCH и вперед — винда, макось, айфон, андроид.
2. Натив код + сборщик мусора
3. Один бинарник и ноль зависимостей от компонентов ОС. Это просто прекрасно, когда ты открываешь в IDA импорт секцию и видишь пустой список. Бинарнику нужны только syscall'ы и больше ничего. Есть исключения разве что на винде и iOS. И то, это зависимости от API ОС.
4. Огромная стандартная библиотека + простейшая процедура подключения сторонних библиотек
5. Горутины
Все остальное так или иначе вносит сложности. С/С++ — ад с кроссплатформенностью, компиляцией, сторонними библиотеками, асинхронностью и т.д. .Net/Java — все хорошо, но рантайм за собой тянуть как зависимость и его оверхед по памяти как минимум. Скриптовые языки — тянуть за собой интерпретатор + оверхед по всему подряд.
Go расположился во всем аккурат между С/С++ и C#/Java и этим он привлекает. И тут скорее не язык сам интересен, а инфраструктура вокруг него, которая, впрочем, благодаря особенностям языка и стала возможна.
У .Net есть открытый Roslyn вообще-то.
С учетом CGO это вообще отпадает по определению. Вкомпилить можно что угодно. Даже для C++ есть вариант.
В данном случае GO не имеет к этому никакого отношения. А .Net и Java всегда будут иметь проблему в виде рантайма.
Я бы это вам посоветовал, ибо так нагло врать нехорошо. Никто там про хиловары не заикался. А Пайк всего лишь пришел и вбросил, больше ничего он не добавил в ту беседу.
Это типичный такой жирный троллинг.
Аргумент «сначала добейся» начинает уже утомлять. Что не пост от вас, то одно и тоже.
Хороший менеджер.
И я так думаю. Поэтому ждем, когда они разочаруются в Go и перейдут на новую модную технологию. Что у нас там на повестке дня?
И после таких комментариев вы еще кого-то упрекается за тон.