25 Мб наверное потому что собирали с dependency "vibe-d" version="~>0.8.4"?
Можно было бы подтянуть по-отдельности vibe:core и vibe:http, в итоге исходник весил бы около 3Мб после обработки через strip (3 Мб правда это не под ARM, а под x86-64, под ARM наверное даже меньше будет).
Чтобы народ не пугать, ведь в этих 25 Мб куча всяких ненужных вещей типа драйверы mongodb и т.д.
здорово что вы всё русскоязычное комьюнити назвали нецивилизованным
Ну вот видите как оно получается. Я же написал что русскоязычное комьюнити уступает в адекватности, а не то что оно нецивилизованно.
Говорю же, "Чукча не читатель, чукча писатель".
И уж точно не Вам на это мое высказывание обижаться, тем более что Вы тут совсем недавно пытались выставить меня фанатиком Go, говоря что "гоферам застилает глаза божественность Пайка, но неплохо бы ознакомиться с теорией." и позволяя себе прочие фривольности (при весьма забавном обстоятельстве, что я на Go НЕ пишу).
Так что давайте закроем тему. Здесь больше нечего обсуждать.
Думаю что ответ на Ваш комментарий был связан с вопросом: "А зачем для магазинов всякая хардкорная конкурентность и всё такое?".
Про Go упоминаний не было. Но Вы опять про Go и про студентов, хотя я, например, использовал сочетание "вчерашних студентов", что подразумевает то что человек все-таки закончил обучение в ВУЗе.
И такое происходит на протяжении всей ветки со всеми комментаторами.
Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.
Вы видимо тоже не хотите читать мои комментарии. Скажите, где именно я задавал вопрос о том "зачем знать разницу между монадой и аппликативным функтором"?
Я не пишу на Go. Для моих задач он не имеет достаточной выразительности и удобства. Я упомянул Go в качестве ответа на вопрос Fesor.
Посыл мой заключался в том, что сегодня все пишут GUI на Electron, а завтра есть вероятность появления какой-либо более оптимизированной по памяти и скорости технологии, согласно закону перехода количественного в качественное.
Я упомянул Go специально, т.к. это всем понятный пример, который на слуху у большинства, в отличие от более маргинальных здесь приведенных языков (F#, Racket, CML и т.д.), и упомянул его в совершенно конкретном контексте — сетевых приложений.
Вместо того чтобы прочитать мои сообщения внимательно, люди, заметив упоминание Go, решили наброситься на меня и начать выяснять чем Go лучше или хуже других технологий (еще и попутно выставляя меня фанатиком Go).
Скажите, Вы тоже не видите изначального посыла моих комментариев?
Зачем среднестатистическому HTTP серверу нужны continue и break
Ну, наверное затем, чтобы, как минимум, можно было более удобно построить конечный автомат для парсинга HTTP запроса, нет?
Хотя да, что уж там, с монадами-то процесс парсинга значительно ускорится и потребит меньше памяти! Это ж как можно будет распараллелить процесс, если парсить заголовки и тело запроса отдельными pure функциями, завернутыми в монаду. Ого-го!
А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)
Не вижу смысла спорить «какой язык более гошный, чем го»
Что значит более "гошный"? Когда Go появился, сначала его позиционировали как конкурента и замену языку C, но не найдя на этом поприще признания, его просто специализировали под написание сетевых приложений. И в этом ключе он уже обрел популярность.
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!
GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
В JVM тоже есть способ гнать байткод в натив — Excelsior например.
Ну конечно есть способы. Даже в некоторых скриптовых языках есть возможность компиляции в нативный код. Вот только это не отменяет того факта что частотность использования этих решений на продакшне гораздо ниже. И не все из них production-ready. Тем временем Go уже давно production-ready и предоставляет компиляцию (причем достаточно быструю) в нативный код из коробки =)
Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.
Вы сравниваете Haskell и Go, как будто это два конкурирующих между собой языка. По-моему вполне очевидно и ожидаемо что у специализированного языка стандартная библиотека может быть меньше чем у более общего.
Причем посыл Вашего абзаца мне видится таким: "да признаю (черт возьми!) что Go тут перещеголял другие языки. Но… но… но это все от того что он хуже!" =D
Все мы знаем что "Любая достаточно сложная программа на <язык_программирования> содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp" ®
Но большие и примечательные production сетапы на Lisp (как и на Haskell) в мире можно пересчитать по пальцам.
Потому что обслуживать, скажем, торговые сети или интернет магазины дешевле и целесообразнее при помощи вчерашних студентов или переквалифицировавшихся профессионалов, чем при помощи PhD и профессоров из вузов Ivy League. Ибо масштаб проблемы слегка не тот.
И в этом Go прекрасно решает свою задачу, ведь написание сетевых сервисов и всяких HTTP серверов — это не научная проблема, а самая что ни на есть прикладная.
По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.
Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.
Изначальный вопрос был:
почему все они достаточно маргинальны по сравнению с Go?
Но Вы, получается, ушли от ответа, так что тут раунд!
И вообще, кому нужен Clojure, когда есть Common Lisp? =)
Сочувствую. Но не переживайте, все у Вас наладится, я в это верю, правда.
Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.
Полностью согласен! Осталось только предложить это самим гоферам, а не писать это под моими комментариями. =)
Что нового привнёс Go?
Go популярен, поэтому я упомянул именно его, для того чтобы говорить с людьми на одном языке, принимая во внимание то что я не знаком с Fesor лично и не знаю его бэкграунда. Это считается нормальным в диалоге — переходить от общего к частному.
А вот то что у Вас от этого бомбануло (наверное), не сказать чтобы прямо моя вина. Тем более что дискутировал изначально я не с Вами =)
Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:
СSP модель в Go не является чем-то новым и захватывающим, но вот то что язык специализировали под определенные задачи, сделали при этом его компилируемым в машинный код, приспособили под современный рынок труда а затем правильно отпозиционировали — вот это как раз является.
Я не вижу смысла продолжать дискуссию, потому что мы с Вами, судя по-всему, говорим несколько о разных вещах.
Но раз уж Вы решили вступить в ряды диванного спецназа (ведь в интернете опять кто-то неправ), то ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?
Создается ощущение, что Вы нарочно опускаете контекст дискуссии. Ключевое слово "сетевые сервисы" почему-то осталось незамеченным Вами и остальными комментаторами этой ветки.
Как и обычно бывает в рунете (и на Хабре в частности) — сначала закидывают шапками, а потом разбираются.
Я говорил не про сам язык программирования Go, а лишь привел его в пример в качестве иллюстрации закона перехода количественного в качественное (по Вашей же просьбе). Контекстом этого перехода является именно предметная область написания сетевых сервисов (network applications), а не проблемы отрасли, парадигмы программирования или вселенской справедливости.
Причем под количеством и качеством я понимал термины из философии (Диалектика Гегеля / Диалектический Материализм), а не количество как число (уж тем более число разработчиков) и качество как качество ПО.
Сам пример перехода я подрузамевал так:
Появляется проблема написания сетевых сервисов и приложений;
Появляются разрозненные решения: зачастую библиотеки/фреймворки к существующим языкам для работы над проблемой;
Возрастает сложность проблемы, возрастает нагрузка на приложения;
Постепенно продолжают происходить количественные изменения: предлагаются новые варианты решения — multi-threading (Java, Apache HTTP server, etc.), fork (CGI, FastCGI, *CGI), async concurrency (libevent, libev, libuv, etc. и основанные на них решения — NGINX, NodeJS и т.д.)
Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines), позволяя еще более эффективно использовать процессорные ядра.
Стандартная библиотека позволяет написать мощный и быстрый HTTP сервер в пару строк кода за несколько десятков минут. На решение подобной задачи с точно такой же эффективностью в других языках уйдет просто уйма времени (особенно в C++).
Если Вы не согласны с такой интерпретацией, то подробнее о примерах действия закона можете прочитать в вики.
За сим позвольте откланяться. Считаю данную дискуссию исчерпанной и вышедшей за рамки данной статьи.
Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
Сетевые сервисы сейчас проще и быстрее писать на Go, не теряя в производительности и потреблении памяти.
Написать сетевое приложение на Go значительно проще чем на C++. Касательно Java/Python и т.д. — все это языки, в которых для исполнения кода используется дополнительная абстракция (виртуальная машина/интерпретатор), так что по эффективности они априори проигрывают.
По поводу D могу сказать что там не все так однозначно. Есть фреймворк vibe.d, но он из коробки не даст той же производительности как и Go. В vibe.d тоже используется кооперативная многозадачность, но там нет встроенного пула потоков, по которому раскидываются задачи (технически это возможно, но программисту все еще нужно понимать что происходит "под капотом").
По поводу микросервисов могу сказать что эта архитектура скорее попытка адаптации к рынку труда, чем к решению технологических задач. Микросервисы можно писать на чем угодно, и этот факт позволяет компаниям охватывать при найме гораздо большую часть рынка, чем просто "PHP Developer" или "Erlang Developer" (и т.д.).
Rust же совсем не про сетевые сервисы. Это С на стероидах. В будущем приложения, которые раньше писали на C, будут писать на Rust, т.к. этот язык конкурирует именно с C и его производными.
Так что Go на мой взгляд именно что качественный скачок применительно к написанию сетевых сервисов. А на Ваш взгляд?
Пример: язык Go. Раньше все писали сетевые сервисы на чем попало, то есть Python, Perl, Node.js, C++ и т.д. Сегодня для этого берут Go. Компилируемый язык со встроенной кооперативной (а также вытесняющей) многозадачностью.
Посмотрите на проект Сentrifugo: https://github.com/centrifugal/centrifugo
Раньше был написан на Python (Tornado), теперь на Go. В итоге производительность увеличилась на порядки, а потребление памяти снизилось, не сильно при этом потеряв в простоте поддержки кода.
К сожалению программистов такая вещь как Electron пользуется спросом у бизнеса именно по причине оптимизации денежных трат. Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.
Electron действительно сжирает всю память и процессорное время. Однако это дает возможность бизнесу быстро вводить в строй новые продукты.
И это единственная причина. Electron как технология ужасен. Но технологии не стоят на месте и в будущем все-таки есть надежда на более выигрышную по производительности технологию.
Закон перехода количественного в качественное никто не отменял :)
Скорее как страх Google проиграть часть рынка Samsung'у с их Tizen'ом.
Вообще никогда не понимал зачем на носимых устройствах нужна JVM, пусть даже и оптимизированная в каких-то моментах.
Те же Apple девайсы никогда не поставлялись с таким огромным количеством памяти на борту. Хотя бы просто из-за отсутствия виртуальной машины и специфической сборки мусора.
Надеюсь что Tizen все-таки даст Гуглу пинка под зад, хотя бы в этой рыночной категории. Давно пора бы.
Ничего странного. В Array.prototype.forEach нет возможности использовать break, в то время как в обычных for/while циклах всегда можно. К тому же forEach требует объявления анонимной функции, что не всегда подходит.
Странно что он течет под x86-64, т.к. по идее проблема "фальшивых" указателей на этой платформе стоит не так остро как на 32 разрядных системах.
Жаль это слышать, надеюсь они наконец-то дотестят и сольют пулл реквест precise gc с мастером.
А сколько примерно объектов в памяти у Вас в среднем? Просто для статистики, хочу лучше понять масштаб проблемы уктечек на стандартном GC
25 Мб наверное потому что собирали с dependency "vibe-d" version="~>0.8.4"?
Можно было бы подтянуть по-отдельности vibe:core и vibe:http, в итоге исходник весил бы около 3Мб после обработки через strip (3 Мб правда это не под ARM, а под x86-64, под ARM наверное даже меньше будет).
Чтобы народ не пугать, ведь в этих 25 Мб куча всяких ненужных вещей типа драйверы mongodb и т.д.
Ну вот видите как оно получается. Я же написал что русскоязычное комьюнити уступает в адекватности, а не то что оно нецивилизованно.
Говорю же, "Чукча не читатель, чукча писатель".
И уж точно не Вам на это мое высказывание обижаться, тем более что Вы тут совсем недавно пытались выставить меня фанатиком Go, говоря что "гоферам застилает глаза божественность Пайка, но неплохо бы ознакомиться с теорией." и позволяя себе прочие фривольности (при весьма забавном обстоятельстве, что я на Go НЕ пишу).
Так что давайте закроем тему. Здесь больше нечего обсуждать.
Думаю что ответ на Ваш комментарий был связан с вопросом: "А зачем для магазинов всякая хардкорная конкурентность и всё такое?".
Про Go упоминаний не было. Но Вы опять про Go и про студентов, хотя я, например, использовал сочетание "вчерашних студентов", что подразумевает то что человек все-таки закончил обучение в ВУЗе.
И такое происходит на протяжении всей ветки со всеми комментаторами.
"Чукча не читатель, чукча писатель!" ©
Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.
Вы видимо тоже не хотите читать мои комментарии. Скажите, где именно я задавал вопрос о том "зачем знать разницу между монадой и аппликативным функтором"?
Давайте я Вам объясню:
Я не пишу на Go. Для моих задач он не имеет достаточной выразительности и удобства. Я упомянул Go в качестве ответа на вопрос Fesor.
Посыл мой заключался в том, что сегодня все пишут GUI на Electron, а завтра есть вероятность появления какой-либо более оптимизированной по памяти и скорости технологии, согласно закону перехода количественного в качественное.
Я упомянул Go специально, т.к. это всем понятный пример, который на слуху у большинства, в отличие от более маргинальных здесь приведенных языков (F#, Racket, CML и т.д.), и упомянул его в совершенно конкретном контексте — сетевых приложений.
Вместо того чтобы прочитать мои сообщения внимательно, люди, заметив упоминание Go, решили наброситься на меня и начать выяснять чем Go лучше или хуже других технологий (еще и попутно выставляя меня фанатиком Go).
Скажите, Вы тоже не видите изначального посыла моих комментариев?
Думаю это вопрос не ко мне. Лучше об этом спросить у Ozon: https://vc.ru/ozon/45542-go или у Zalando, или у остальных пользователей.
В основном они применяют Go для инфраструктурных моментов (насколько мне известно).
Также есть всякие рекламные биржи и т.д.
Поддержите. Ведь это все что Вам остается в отсутствии объективных аргументов.
Ну, наверное затем, чтобы, как минимум, можно было более удобно построить конечный автомат для парсинга HTTP запроса, нет?
Хотя да, что уж там, с монадами-то процесс парсинга значительно ускорится и потребит меньше памяти! Это ж как можно будет распараллелить процесс, если парсить заголовки и тело запроса отдельными pure функциями, завернутыми в монаду. Ого-го!
А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)
Что значит более "гошный"? Когда Go появился, сначала его позиционировали как конкурента и замену языку C, но не найдя на этом поприще признания, его просто специализировали под написание сетевых приложений. И в этом ключе он уже обрел популярность.
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!
Ну конечно есть способы. Даже в некоторых скриптовых языках есть возможность компиляции в нативный код. Вот только это не отменяет того факта что частотность использования этих решений на продакшне гораздо ниже. И не все из них production-ready. Тем временем Go уже давно production-ready и предоставляет компиляцию (причем достаточно быструю) в нативный код из коробки =)
Вы сравниваете Haskell и Go, как будто это два конкурирующих между собой языка. По-моему вполне очевидно и ожидаемо что у специализированного языка стандартная библиотека может быть меньше чем у более общего.
Причем посыл Вашего абзаца мне видится таким: "да признаю (черт возьми!) что Go тут перещеголял другие языки. Но… но… но это все от того что он хуже!" =D
Все мы знаем что "Любая достаточно сложная программа на <язык_программирования> содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp" ®
Но большие и примечательные production сетапы на Lisp (как и на Haskell) в мире можно пересчитать по пальцам.
Потому что обслуживать, скажем, торговые сети или интернет магазины дешевле и целесообразнее при помощи вчерашних студентов или переквалифицировавшихся профессионалов, чем при помощи PhD и профессоров из вузов Ivy League. Ибо масштаб проблемы слегка не тот.
И в этом Go прекрасно решает свою задачу, ведь написание сетевых сервисов и всяких HTTP серверов — это не научная проблема, а самая что ни на есть прикладная.
Изначальный вопрос был:
Но Вы, получается, ушли от ответа, так что тут раунд!
И вообще, кому нужен Clojure, когда есть Common Lisp? =)
Сочувствую. Но не переживайте, все у Вас наладится, я в это верю, правда.
Полностью согласен! Осталось только предложить это самим гоферам, а не писать это под моими комментариями. =)
Go популярен, поэтому я упомянул именно его, для того чтобы говорить с людьми на одном языке, принимая во внимание то что я не знаком с Fesor лично и не знаю его бэкграунда. Это считается нормальным в диалоге — переходить от общего к частному.
А вот то что у Вас от этого бомбануло (наверное), не сказать чтобы прямо моя вина. Тем более что дискутировал изначально я не с Вами =)
СSP модель в Go не является чем-то новым и захватывающим, но вот то что язык специализировали под определенные задачи, сделали при этом его компилируемым в машинный код, приспособили под современный рынок труда а затем правильно отпозиционировали — вот это как раз является.
Я не вижу смысла продолжать дискуссию, потому что мы с Вами, судя по-всему, говорим несколько о разных вещах.
Но раз уж Вы решили вступить в ряды диванного спецназа (ведь в интернете опять кто-то неправ), то ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?
Создается ощущение, что Вы нарочно опускаете контекст дискуссии. Ключевое слово "сетевые сервисы" почему-то осталось незамеченным Вами и остальными комментаторами этой ветки.
Как и обычно бывает в рунете (и на Хабре в частности) — сначала закидывают шапками, а потом разбираются.
Я говорил не про сам язык программирования Go, а лишь привел его в пример в качестве иллюстрации закона перехода количественного в качественное (по Вашей же просьбе). Контекстом этого перехода является именно предметная область написания сетевых сервисов (network applications), а не проблемы отрасли, парадигмы программирования или вселенской справедливости.
Причем под количеством и качеством я понимал термины из философии (Диалектика Гегеля / Диалектический Материализм), а не количество как число (уж тем более число разработчиков) и качество как качество ПО.
Сам пример перехода я подрузамевал так:
Стандартная библиотека позволяет написать мощный и быстрый HTTP сервер в пару строк кода за несколько десятков минут. На решение подобной задачи с точно такой же эффективностью в других языках уйдет просто уйма времени (особенно в C++).
Если Вы не согласны с такой интерпретацией, то подробнее о примерах действия закона можете прочитать в вики.
За сим позвольте откланяться. Считаю данную дискуссию исчерпанной и вышедшей за рамки данной статьи.
Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
Сетевые сервисы сейчас проще и быстрее писать на Go, не теряя в производительности и потреблении памяти.
Написать сетевое приложение на Go значительно проще чем на C++. Касательно Java/Python и т.д. — все это языки, в которых для исполнения кода используется дополнительная абстракция (виртуальная машина/интерпретатор), так что по эффективности они априори проигрывают.
По поводу D могу сказать что там не все так однозначно. Есть фреймворк vibe.d, но он из коробки не даст той же производительности как и Go. В vibe.d тоже используется кооперативная многозадачность, но там нет встроенного пула потоков, по которому раскидываются задачи (технически это возможно, но программисту все еще нужно понимать что происходит "под капотом").
По поводу микросервисов могу сказать что эта архитектура скорее попытка адаптации к рынку труда, чем к решению технологических задач. Микросервисы можно писать на чем угодно, и этот факт позволяет компаниям охватывать при найме гораздо большую часть рынка, чем просто "PHP Developer" или "Erlang Developer" (и т.д.).
Rust же совсем не про сетевые сервисы. Это С на стероидах. В будущем приложения, которые раньше писали на C, будут писать на Rust, т.к. этот язык конкурирует именно с C и его производными.
Так что Go на мой взгляд именно что качественный скачок применительно к написанию сетевых сервисов. А на Ваш взгляд?
Пример: язык Go. Раньше все писали сетевые сервисы на чем попало, то есть Python, Perl, Node.js, C++ и т.д. Сегодня для этого берут Go. Компилируемый язык со встроенной кооперативной (а также вытесняющей) многозадачностью.
Посмотрите на проект Сentrifugo: https://github.com/centrifugal/centrifugo
Раньше был написан на Python (Tornado), теперь на Go. В итоге производительность увеличилась на порядки, а потребление памяти снизилось, не сильно при этом потеряв в простоте поддержки кода.
К сожалению программистов такая вещь как Electron пользуется спросом у бизнеса именно по причине оптимизации денежных трат. Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.
Electron действительно сжирает всю память и процессорное время. Однако это дает возможность бизнесу быстро вводить в строй новые продукты.
И это единственная причина. Electron как технология ужасен. Но технологии не стоят на месте и в будущем все-таки есть надежда на более выигрышную по производительности технологию.
Закон перехода количественного в качественное никто не отменял :)
Скорее как страх Google проиграть часть рынка Samsung'у с их Tizen'ом.
Вообще никогда не понимал зачем на носимых устройствах нужна JVM, пусть даже и оптимизированная в каких-то моментах.
Те же Apple девайсы никогда не поставлялись с таким огромным количеством памяти на борту. Хотя бы просто из-за отсутствия виртуальной машины и специфической сборки мусора.
Надеюсь что Tizen все-таки даст Гуглу пинка под зад, хотя бы в этой рыночной категории. Давно пора бы.
Ничего странного. В Array.prototype.forEach нет возможности использовать break, в то время как в обычных for/while циклах всегда можно. К тому же forEach требует объявления анонимной функции, что не всегда подходит.
PS. Опоздал, кажется тут уже ответили =)
Да любой более-менее сложный конечный автомат. Например: https://www.thibault.org/newhome/thoughts/goto-and-fsms.html
Согасен с тем, что goto никаким злом не является. Просто конструкция, которую стоит применять обдуманно.
Спуститесь на уровень пониже (в ассемблер), и (о боже!) там везде goto! Безусловные и условные переходы по-другому и не работают.
Излишняя демонизация goto и глобальных переменных говорит скорее об узости мышления таких демонизаторов.
Странно что он течет под x86-64, т.к. по идее проблема "фальшивых" указателей на этой платформе стоит не так остро как на 32 разрядных системах.
Жаль это слышать, надеюсь они наконец-то дотестят и сольют пулл реквест precise gc с мастером.
А сколько примерно объектов в памяти у Вас в среднем? Просто для статистики, хочу лучше понять масштаб проблемы уктечек на стандартном GC
У Вас клиент наверное под x86 без 64?