Поправка. Популярным JAVA делали далеко не только парни из Sun. Это делалось десятком компаний и тысячей разработчиков. Причём роль Google в популяризации Java очень и очень большая. Но в любом случае это порочный метод оценки, поскольку тогда Sun/Oracle придётся признать вечными должниками Microsoft, так как популярность Java базировалась в первую очередь на популярности Microsoft Windows.
Это же во многом вопрос экосистемы — наличия фреймворков, IDE, статических анализаторов, байдингов, сообщества и т.д.
Зависит от подхода. Сливки с любой новой IТехнологии снимает тот, кто не дожидается её выхода в мейнстрим. Простой пример: сейчас я плачу Go-программисту $5K/m и это оправданная цена как экономически, так и с точки зрения дефицита кадров. Придёт ли мне в голову платить столько же JAVA-разработчику, пусть даже эффективность будет той же? Нет, не придёт. Потому что на собеседование придут десять соискателей, готовых работать и за $1-3K/m.
Я считаю, что никакой неприязни у психически здоровых людей(коих на хабре, хочется верить, большинство) нет.
О, сколько уже тут было войн тупоконечников с остроконечниками!
а вот выживают из них довольно не многие
Go развивается уже два года. Я использую в продакшене (банковский сектор) больше года. Инфраструктурные издержки снизились в 5-10 раз (относительно старых версий на Java и Python). Снизились издержки — демпируется цена. Демпируются цены — вышибаются конкуренты. Profit.
если бы мое приложение в стиле hello world потребовало почти гиг памяти
Выше уже объясняли разницу между потреблением памяти и резервацией адресного пространства.
Эээ, «тут стратегия на стратегию попёрла».
Google выпустил в свет действительно хороший инструмент, что в каком-то роде ставит под угрозу безбедное существование адептов других инструментов.
Мало кто из успешных (на своём языке) разработчиков хочет терять свою долю хлебушка с маслицем из-за появления чего-то нового. Эдакая гремучая смесь консерватизма, луддизма и цехового сговора.
Основная ниша Go — золотая середина. Т.е. разумное соотношение простоты и скорости разработки к быстродействию и затрате ресурсов. И для достижения золотой середины приходится чем-то жертвовать. А с учётом реальности, 32-битностью жертвовать приходится уже достаточно часто. Например, при работе с Mongo.
Можно даже выстроить классическую диаграмму-треугольник, где на вершинах будут простота, быстродействие и совместимость.
И я бы одобрил такой подход. Go планировался и создавался как новый язык, изначально «заточенный» под новое железо (многоядерность и многопроцессорность). И не совсем ясно зачем они решились тянуть лишний груз совместимости. Более того, я не совсем понимаю зачем они полезли на Windows-платформу, погнавшись за всеми зайцами сразу.
Вам придёт в голову писать VirtualBox на Visual Basic (или как он нынче именуется?). А на PHP или Erlang-е? Всё это тоже general-purpose языки. А вот что касается системного программирования, то тут всё иначе. С моей точки зрения «системность» подразумевает написание чего-либо маленького и шустренького. И для таких задач Go подходит замечательно.
Я согласен — проблемы с GC у Go имеются. Но всплывают они лишь тогда, когда кто-то пытается «забить микроскопом гвоздь».
func fs() []byte {
//allocate 64 MB chunks
r := make([]byte, 64*1024*1024)
return r
}
Это, по вашему мнению, нормальный подход? Я повторюсь — на любом языке можно создать такой правильный код, который напрочь убьёт программу при определённых условиях. Можно даже считать это определённым видом спорта.
Спросим иначе — почему по факту Java жрёт памяти значительно больше? Периодически столько, что вешает систему даже без «странностей» в GC? Можно даже не обращаться к серверным приложениям, достаточно запустить Eclipse и убедиться в тормознутости.
Это на лбу у каждого программиста должно быть вытатуирован принцип «Всегда экономь системные ресурсы». На других частях тела можно дополнить и другими полезными принципами RTFM. Если программе требуются значительные ресурсы, то нужно трижды подумать о реализации и изучить матчасть. Проблема-то не только в Go, а и в других GC-языках, использующих сходный механиз выделения памяти, о чём и автор самой статьи упомянул.
Go needs the space because it is garbage collected — presumably, all GC languages, or any program that takes a similar approach to memory management, will be susceptible to the same problem.
Т.е. проблема «ожидаема» на всех языках, входящих в содружество GC.
The problem is hard to replicate and test — most of the time, Go programs run perfectly fine
Т.е. ошибка всё же вылезает лишь при определённых обстоятельствах, которые ещё и трудно повторить.
I love programming in Go. And I agree with Rob Pike that «programmers complain too much when they should be fixing the problem instead».
А уж я-то как согласен с Робом! По этому поводу есть более ёмкая русская пословица — «взялся за гуж — не говори, что не дюж». Можно выразиться и иначе — «Не можешь… ть, не мучай… пу» :)
Unfortunately, I am not familiar enough with the Go runtime code to dive and make the required changes with confidence that I have both actually fixed the problem and not introduced bugs into the memory management code. I don’t have time before my deadline to look into the issue either.
О, как! «Не читал, но осуждаю!» Человек взялся за новый язык для продакшн версии, не особенно вникая в детали.
Если программист не удосуживается изучить механизм работы сборщика мусора и рекомендации по применению языка, то это плохой, заслуживающий лишь увольнения программист :)
С точки зрения компилятора, бесконечный цикл тоже выглядит корректным алгоритмом. Как и попытка деления, без проверки делителя (на ноль).
Такие сообщения мне напоминают анекдот про японскую лесопилку и советских лесорубов с ломиком. При особом желании можно сломать реализацию практически на любом языке. Но по факту такие глюки вылезают лишь при достаточно редком стечении обстоятельств и криворукости «новых программистов», пытающихся решать задачи в лоб и «по микрософтовски», т.е. не заботясь о качественном подходе и об экономии ресурсов.
В моей объективности вполне можно усомниться, поскольку я тут в роли «адвоката дьявола» (или Евангелиста GO — смотря с какой позиции смотреть), но факты остаются фактами — за год использования GO в продакшне мне не доводилось сталкиваться с такими ситуациями и проблемами. Может благодаря хорошей привычке работать исключительно под Linux и в 64-битных версиях.
Go, как и любой другой язык, обладает своими особенностями (см. Effective Go), которые следует учитывать, а не изображать Google Translate переводя напрямую привычные алгоритмы с одного языка на другой.
Даже на эталонных языках (C/C++) случаются проблемы с memory leaks, если разработчик не будет внимательно следить за использованием памяти.
Языка программирования «Панацея» ещё не существует, как и не существует компиляторов, способных преобразовать программу «Хочу, чтобы всё работало зашибенно, без глюков и желательно даже на старом железе» в совершенный код. И этому стоило бы порадоваться — появись такой волшебный компилятор — легион программистов останется без работы :)
Поправка. Кто работает с Gimp очень давно, тот привык к многооконной среде.
Зависит от подхода. Сливки с любой новой IТехнологии снимает тот, кто не дожидается её выхода в мейнстрим. Простой пример: сейчас я плачу Go-программисту $5K/m и это оправданная цена как экономически, так и с точки зрения дефицита кадров. Придёт ли мне в голову платить столько же JAVA-разработчику, пусть даже эффективность будет той же? Нет, не придёт. Потому что на собеседование придут десять соискателей, готовых работать и за $1-3K/m.
Google выпустил в свет действительно хороший инструмент, что в каком-то роде ставит под угрозу безбедное существование адептов других инструментов.
Мало кто из успешных (на своём языке) разработчиков хочет терять свою долю хлебушка с маслицем из-за появления чего-то нового. Эдакая гремучая смесь консерватизма, луддизма и цехового сговора.
Можно даже выстроить классическую диаграмму-треугольник, где на вершинах будут простота, быстродействие и совместимость.
Я согласен — проблемы с GC у Go имеются. Но всплывают они лишь тогда, когда кто-то пытается «забить микроскопом гвоздь».
func fs() []byte { //allocate 64 MB chunks r := make([]byte, 64*1024*1024) return r }Это, по вашему мнению, нормальный подход? Я повторюсь — на любом языке можно создать такой правильный код, который напрочь убьёт программу при определённых условиях. Можно даже считать это определённым видом спорта.
Т.е. проблема «ожидаема» на всех языках, входящих в содружество GC.
Т.е. ошибка всё же вылезает лишь при определённых обстоятельствах, которые ещё и трудно повторить.
А уж я-то как согласен с Робом! По этому поводу есть более ёмкая русская пословица — «взялся за гуж — не говори, что не дюж». Можно выразиться и иначе — «Не можешь… ть, не мучай… пу» :)
О, как! «Не читал, но осуждаю!» Человек взялся за новый язык для продакшн версии, не особенно вникая в детали.
Одно слово — индус.
С точки зрения компилятора, бесконечный цикл тоже выглядит корректным алгоритмом. Как и попытка деления, без проверки делителя (на ноль).
В моей объективности вполне можно усомниться, поскольку я тут в роли «адвоката дьявола» (или Евангелиста GO — смотря с какой позиции смотреть), но факты остаются фактами — за год использования GO в продакшне мне не доводилось сталкиваться с такими ситуациями и проблемами. Может благодаря хорошей привычке работать исключительно под Linux и в 64-битных версиях.
Go, как и любой другой язык, обладает своими особенностями (см. Effective Go), которые следует учитывать, а не изображать Google Translate переводя напрямую привычные алгоритмы с одного языка на другой.
Даже на эталонных языках (C/C++) случаются проблемы с memory leaks, если разработчик не будет внимательно следить за использованием памяти.
Языка программирования «Панацея» ещё не существует, как и не существует компиляторов, способных преобразовать программу «Хочу, чтобы всё работало зашибенно, без глюков и желательно даже на старом железе» в совершенный код. И этому стоило бы порадоваться — появись такой волшебный компилятор — легион программистов останется без работы :)