Подготовлен (https://blog.golang.org/go1.11) релиз языка программирования Go 1.11 (http://golang.org), который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется (https://golang.org/dl/) под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.11), представленные в выпуске Go 1.11:
- Реализована концепция модулей (https://golang.org/doc/go1.11#modules), которую можно применять в качестве альтернативы GOPATH, отличающейся интегрированной поддержкой версионирования, средствами доставки пакетов и улучшенной системой управления зависимостями. Система модулей пока является экспериментальной, поэтому синтаксис команд (https://golang.org/cmd/go#hdr-Modules__module_versions__and_...) для работы с модулями может поменяться в будущем. Используя модули разработчики больше не привязаны к работе внутри дерева GOPATH, могут явно определять зависимости с учётом версий и создавать повторяемые сборки;- Добавлен экспериметальный порт для WebAssembly (https://golang.org/wiki/WebAssembly) (js/wasm), позволяющий компилировать приложения на языке Go в промежуточный код WebAssembly для выполнения в web-браузерах. На выходе формируется готовый модуль WebAssembly, включающий runtime-компоненты для goroutine, планировщик, систему сборки мусора и т.п. Минимальный размер runtime-компонентов для WebAssembly составляет 2 Мб (при сжатии 500 Кб). Для вызова скомпилированных в WebAssembly программ из кода на JavaScript предложен экспериментальный модуль syscall/js;
- Предложен пакет go/packages (https://godoc.org/golang.org/x/tools/go/packages) с реализаций простого API для поиска и загрузки пакетов с кодом на языке Go. API пока не включён в стандартную библиотеку, но может применяется в качестве эффективной замены пакета
go/build, обеспечивающей поддержку модулей;- В компиляторе расширен диапазон функций для которых применяется inline-развёртывание кода. В том числе развёртывание теперь может применяться и для функций, в которых используется вызов panic().
- Предложен новый формат экспорта данных для пакетов, обеспечивающий более высокую скорость сборки для больших проектов;
- В ассемблере реализована поддержка инструкций AVX512 для архитектуры amd64;
- Улучшено качестве отладочной информации, генерируемой для оптимизированных исполняемых файлов. Обеспечено сжатие отладочных секций в формате DWARF. Добавлена экспериментальная возможность вызова функций на языке Go из отладчика;
- В различные части кодовой базы внесены оптимизации, специфичные для архитектуры arm64. В компиляторе задействованы более агрессивные оптимизации для исключения излишних переходов и проверок границ буферов. Проведена оптимизация производительности пакета math/big;
- Прекращена поддержка OpenBSD 6.0, OS X 10.8 "Mountain Lion", OS X 10.9 "Mavericks", Windows XP и Windows Vista. Для работы теперь требуется как минимум OpenBSD 6.2, macOS 10.10 "Yosemite" или Windows 7. Добавлена поддержка OpenBSD 6.4. Race detector портирован для linux/ppc64le и netbsd/amd64. Режим поверки памяти (-msan) адаптирован для платформы linux/arm64.
URL: https://blog.golang.org/go1.11
Новость: https://www.opennet.me/opennews/art.shtml?num=49183
не понимаю смысла в том го. Нужен шикарный толстый корпоративный веб есть java+spring. Если что-то надо под больной нагрузкой, и более профессиональное, или более любительское - php.
go имеет нишу для кучки любителей пилить свой велосипед, либо гугл, который пилит тоже свой велик, может себе позволить по деньгам. Остальным зачем это? Нет, я не говорю, чтоб закопали, но "дварфы и агрессивные оптимизации" как-то не впечатляют.
И часто у вас больные нагрузки на java и php?
В моменты обострения, видимо.
> В моменты обострения, видимо.Ну, понимаешь, go'пник притащит свой бинарь на 5 мегов - и сервис задеплоен. А жабист чтобы задеплоить сервис делает адские тантрумы с 100-метровым рантаймом, при том еще окажется что на серваке версия не та или какое там еще гэ. Конечно у него будет боль и обострение на фоне такого безобразия.
Херня и некомпетентность.
Понятия не имеете о чем пишете.
> Херня и некомпетентность.
> Понятия не имеете о чем пишете.Спасибо, с явой я немного имел дело - хватило. А потом пришли go'пники и показали как надо было.
> Спасибо, с явой я немного имел дело - хватилоВот именно что немного и, похоже, неправильно.
> Вот именно что немного и, похоже, неправильно.Я думаю что правильно - забыл этот п...ц как страшный сон, чему и рад. По совокупности ништяков этой технологии давно зарезервировано место в мусорном ведре. А лучше сначала в инкубатор апача, чтобы рентгены поутихли.
А ещё жаба жрёт память, как хром и не поддерживает сgroup до 1.8u121, а даже после и то с экспериментальными опциями(на прод такое, ага)
> А ещё жаба жрёт память, как хром и не поддерживает сgroup до
> 1.8u121, а даже после и то с экспериментальными опциями(на прод
> такое, ага)Ну и чего ты придолбался к памяти? Поставь себе 64гб и не плачь. Я ещё могу понять аргументы насчёт памяти лет 15-ть назад, но сейчас это вообще не проблема.
Java работает даже на смар-картах, где ни go, но c/c++ и ни что другое кроме ассемблера даже не запустится.
А на сервере или на десктопе, +/- 20-30 Мб или 100Мб, роли давно уже не играют.
Нравиться go - вперёд! Кому-то нравятся презервативы типа spring и hibernate потому что лень учить java ee и читать документации по бд, я никого не осуждаю, у каждого свой путь.
покажи спринг на своих смарт картах или веб сервер
> покажи спринг на своих смарт >картах или веб сервер.....в дурдоме амнистия или или просто и-нет подключили?
>Ну и чего ты придолбался к памяти?Я добрый, поэтому открою страшную буржуинсую тайну "Яумамкихакеру" :)
Так вот - память была, есть и ещё долго будет пожалуй что и самым ценным ресурсом в контупере.>Поставь себе 64гб и не плачь.
Не поможет. Жаба умеет сожрать любое еЯ количество. У богатых и толстых конечно есть команды которые этого страшного зверя умеют заставить квакать согласно ноток в сценарии ... но ты то от них "бесконечно далёк" :)
> Так вот - память была, есть и ещё долго будет пожалуй что и самым ценным ресурсом в контупере.
> free -mtotal used free shared buff/cache available
Mem: 257853 22648 70124 23588 165079 209808
Swap: 0 0 0А вот ядер (56), пожалуй, периодически не хватает.
у меня градация весьма простая:
любитель, проф. любитель, мид - это пхп,
мелкий, и средний энтерпрайз - java
потом сверх проекты, где каждая строчка мука выбора, между оптимизацией и непонятно чем - и там снова пхп.
> любитель, проф. любитель, мид - это пхп,
> мелкий, и средний энтерпрайз - java
> потом сверх проекты, где каждая строчка мука выбора, между оптимизацией и непонятно
> чем - и там снова пхп.Тем временем на go наворачивают всякие микросервисы, у которых и код на вид тривиальный, и титан мысли для этого не требуется, и скорость выполнения воткнет и пыху и яве, и не такое энтерпрайзно-монструозное как ява. И не так уж мало всякого или переписывают на сабж, или в новых разработках используют.
> у меня градация весьма простая:То, что ты описал, это не "градация", а "деградация".
Почти любой применимый для WEB-разработки язык при должных оптимизациях справится с необходимой нагрузкой. Например: Java (одноклассники), PHP (facebook, vk), C# (stackoverflow), Python (youtube), Ruby (twitter) - или скажите, что это ненагруженные сайты? С 7ой версии у PHP всё прекрасно с производительностью из коробки.
Однако половина прожектов таки переписали питонятину на это. Какой-нибудь dropbox не только переписал с питона на go, но потом еще и на rust.
youtube большей частью с питона переписан. Точных данных нет, но это был один из первых проектов гугла, который переносили на Go
> youtube большей частью с питона переписан. Точных данных нет, но это был
> один из первых проектов гугла, который переносили на GoПотому что проще заново сделать ЯП чем питона разогнать. Питон крайне враждебен к попыткам его ускорить.
А вот github до сих пор как Ruby on Rails детектится
Сомневаюсь, что к вебинтерфейсу гитхаба десятки и сотни тысяч обращений в секунду и он весь вертится на паре серверов. Го удобен там, где есть подобные нагрузки, например всякие rtb системы.
https://www.wappalyzer.com/ - поставьте себе плагин на браузер и смотрите кто какие технологии на сайте использует. Естественно, сайты могут обманывать в части того, что они используют, но зачем github наговаривать на себя?
Ничего не надо ставить. Входишь в https://builtwith.com/, задаешь url сайта для анализа и он выдает все используемые на сервере технологии
Ну это если раз посмотреть. Но ты же не всегда помнишь/знаешь, какие сайты интересно посмотреть. Тоже стоит этот Wappalyzer и бросается в глаза каждый раз, когда зайдешь на новый сайт, из чего он сделан.
> не понимаюДля java developer'а это естественно.
> Для java developer'а это естественно.Ява девелоперы - это такие чуваки которые все и вся делают бессмысленно и беспощадно.
точно. в гугле не знали про spring, поэтому придумал golang
в гугле просто много денег, и есть возможность делать непонятно что за велосипед .. Нам то зачем это?
Умиляет вот это "нам". Кому вам? Говори за себя.
> Умиляет вот это "нам". Кому вам? Говори за себя.У него жаба головного мозга, она сожрала мозг. Со своей стороны я вообще не понимаю нафиг нужна ява. Все сложно, геморройно, вебня получается разлапистой и глючной, производительность - где-то в теории, а на практике жабист обычно или дебажит 30-этажный трейс или трахается с профилированием, что как бы намекает. Конечно, если денег дофига, как у корпораций, можно и микроскопом гвоздь вколотить. Ява для вебни - очень напоминает это самое.
Написал херню - ибо ты не в теме.Никто там не профилирует каждый день. Бывает, но достаточно редко.
Я пару раз что-то профилировал не свое. Если руки прямые, то до профилирования дело никогда не дойдет. Течет чужой код.Сама по себе жаба норм, проблема скорее с качеством кода. Все куда-то бегут шлепая инновации. Такая тенденция наблюдается для всего ПО, но для энтерпрайза это не есть хорошо, там нужна стабильность.
Еще раз - если писать качественно, тестировать, то все будет работать как часы. Сама JVM достаточно быстрая и стабильная.
PS Похоже, тебя тревожит, что деньги корпораций текут мимо тебя. Держись там.
> Написал херню - ибо ты не в теме.Те кто в теме - не могут оценивать свои потуги адекватно: свое г0вно не пахнет.
> Никто там не профилирует каждый день.
Виденные жабисты и дотнетчики тратили нездоровый объем времени на борьбу с такими ветряными мельницами. Ничего личного, наблюдение за жизнью проектов. Иные виды вебмакак явно расторопнее и результативнее.
> Бывает, но достаточно редко.
Вы охренели, сэр! Быстрой вебни на яве, которой было бы приятно пользоваться и которая бы не жрала на сервере ресурсы как прорва - я вообще не видел. Так не бывает.
> Я пару раз что-то профилировал не свое. Если руки прямые, то до
> профилирования дело никогда не дойдет. Течет чужой код.Это очень большое "если". Поэтому в реальной жизни так почти не бывает.
> Сама по себе жаба норм, проблема скорее с качеством кода.
Сама по себе жаба давно превратилась в адский франкенштейн-переросток с сотнями проблем совместимости, потребления ресурсов, скорости работы и диким гемором деплоя. Энтерпрайзы к такому кошмару конечно привычные, но это не отменяет проблем. Хуже только дотнет, наверное, который делался по логике "догнать и перегнать", что у MS и получилось - геморроя с его рантаймом даже еще больше наверное, а продуктивность дотнетчиков в создании вебни еще ниже.
> Все куда-то бегут шлепая инновации. Такая тенденция наблюдается для всего ПО, но для
> энтерпрайза это не есть хорошо, там нужна стабильность.Единственное что там стабильно - д@рьмовость качества и конские цены за этот трэш. Что компенсируется втиранием очков манагерам и ко.
> Еще раз - если писать качественно, тестировать, то все будет работать как
> часы. Сама JVM достаточно быстрая и стабильная.Да и хрен с ней. У go вообще нет таких проблем.
> PS Похоже, тебя тревожит, что деньги корпораций текут мимо тебя. Держись там.
Похоже что тебя синдром утенка качественно долбанул.
Что ты хочешь доказать, если ты в этом полный ноль?
Хочешь сказать, что мои глаза меня обманывают?Кто тебя слушать будет, если через каждое предложения какой-то некомпетентный бред.
Много слов, но они не содержат никакого смысла, одни эмоции.Не прошел собеседование на жаба жуниора чтоли? Из обиженных?
> Что ты хочешь доказать, если ты в этом полный ноль?И что? По умолчанию анониму опеннета даются +100500 на все скиллы, так что завидуйте молча!
И вообще:
Первое Правило Экспертуса Опеннета:
Всегда вещать с умным и уверенным видом! Повторять одно и то же на разные лады, растекаясь мыслью по древу. Все знают - количество повторов заменяют качество (или отсутствие) аргументов!Второе Правило:
Если что, делать вид, что это не посадка в лужу, а целенаправленное принятие лечебно-грязевой ванны. Спрыг с темы, с переходом на личности - самые лучшие аргументы!
И т.д.В общем, он(о) не зря из под анонима пишет - под ником его, бедолажку, "затравили хейтеры-старперы надутые гусии!!1" ))
О чем ты вообще вещаешь?Это технический форум. Ты ничего не пишешь, что можно оценить как "знание".
Что-то ценное, что что-то можно взять на заметку.
Твои посты несут только эмоциональный оттенок, без какой-либо полезной смысловой нагрузки.Что я нового узнал пообщавшись с тобой?
Ровным счетом ничего.
Наше общение не имеет смысла.
Зачем ты мне печатаешь эту жижу, я не понимаю.
> Что ты хочешь доказать, если ты в этом полный ноль?Для того чтобы заметить что всучили тухлятину - не обязательно быть шеф-поваром в ресторане.
> Хочешь сказать, что мои глаза меня обманывают?
Ну если не глаза - значит, это уже ты втираешь очки внаглую. С мотивацией "шкурный интерес", вероятно. Или в лучшем случае "синдром утенка".
> Кто тебя слушать будет, если через каждое предложения какой-то некомпетентный бред.
> Много слов, но они не содержат никакого смысла, одни эмоции.Это попытка интегральной оценки технологии, глядя на то как выглядит работа команды и выхлоп на выходе. А то что теоретически можно изогнуться и заколотить гвоздь даже микроскопом - круто, но виденные продукты на яве - тормозные энтерпрайзные уроды. Эталон энтерпрайзятины из парижской палаты мер и весов, в самом негативном значении термина. Это когда все делается бессмысленно и беспощадно, стоит кучу денег, занимает дофига времени, а на выходе - адский крап. Но корпорации бывают богатыми, особенно большие, поэтому иной раз могут оплатить даже и чье-то страдание фигней. А менеджеры иногда ведутся на маркетинг вместо здравого смысла.
> Не прошел собеседование на жаба жуниора чтоли? Из обиженных?
Да чур меня! Так, глядя на то во что можно в результате превратиться...
Вы попробуйте. Я так же холиварил, но когда написал несколько сервисов, которые пашут и под Windows и под Linux, и причем не надо ставить тонну зависимостей а тупо копируешь exe и все пашет, мне понравилось. Вы посмотрите как на нем легко написай свой веб-сервис, rest/json прикручиваются буквально за минуту, и после этого на node.js смотришь как на страшного франкенштейна. Я уже несколько лет только на GO и пишу, java/php использую только для работы с старыми проектами. Ну еще осталась Delphi когда надо побыстрому накидать какое-то оконное приложение.
>rest/json прикручиваются буквально за минуту, и после этого на node.js смотришь как на страшного франкенштейнаололо, и чем-же rest/json проще чем в ноде? особенно про JSON интересно
Думаю, что речь о строгой типизации. Можно создать/объявить составной тип и указать как его де-/сериализировать.
Да, в go, если нужны типы (а они нужны) - удобнее, чем в node.
> Думаю, что речь о строгой типизации.TypeScript.
Плюсую, если нужна система типов, лучше использовать Typescript, Go явно ей не блещет.
> Вы посмотрите как на нем легко написай свой веб-сервис, rest/json
> прикручиваются буквально за минуту,Вы вероятно до момента прочтения статьи в инете "пишем свой сервис на go" никогда программированием не занимались? Потому что легко написать свой веб сервис можно на чем угодно. например на perl.. Mojolicious.
те же самые несколько строчек чтобы поднять свой сервис. На perl пожалуй и попроще будет чем на go.Про прикручивание rest/json за минуту- даже не смешно. На перле это 10 секунд - чтобы вписать имя модуля...
В инете полно макулатуры расписывающей достоинства go, как на нем просто делается то да се... практически все это уже было до этого написано и реализовано на фреймворках популярных языков. и достоинства go в этом видны только людям в предметной области невежественным, ничего кроме бравурных статей о го не читавших
Кстати у Го - отвратительная поддержка гетерогенных сетей. на многих платформах он просто не собирается. кроме винды и линуха- он собственно ни на чем больше не работает. увы....
>> Кстати у Го - отвратительная поддержка гетерогенных сетей. на многих платформах он просто не собирается. кроме винды и линуха- он собственно ни на чем больше не работает. увы....Сетей? Точно?
>> на многих платформах он просто не собирается. кроме винды и линуха- он собственно ни на чем больше не работает.Здесь неплохо помогает gccgo, в связке со стандартными инструментами go - с минимумом неудобств.
Смог таким образом собрать и для solaris sparc64 (платформа заказчика), под который нет официального порта.По мне, как java-макаке, преимущество (и иногда недостаток) go в том, что он компилируется в жирные блобы без зависимостей, и на выходе не привязан к окружению/набору библиотек в системе. Т.е. хорошо работает как переносимые скрипты. Но при этом функционально богаче скриптов.
Прикольно. А кто это такой, если не секрет, конечно, заказывает софт в 2018 под спарки (сто раз закопанных на опеннете). Да ещё на Go, а не java. Немного чудесато.
Билайн. Софт заказывает на java, который и крутится на фирменных (тм) спарках. И на c# для виндовых платформ.
А go тут для прикладных нужд админа. По старой традиции немного помогаю новым администраторам, сам же перешёл в разработку. Т.е. это не выбор от заказчика, это выбор инструмента для админа.
> отвратительная поддержка гетерогенных сетей
> кроме винды и линуха- он собственно ни на чем больше не работает. увы....ЛПП. работает вполне себе на макоси, Plan9 даже (хотя экзотика). Процессорных архитектур прилично поддерживает. Как раз в этом Go переплюнул сишечку - подерживает меньше, но зато единой кодовой базой компилятора, кросс-компайл из коробки, а сишечка много поддерживает только за счет написания множества тулчейнов разными людьми. Зоопарк-с.
Что за "отвратительная поддержка гетерогенных сетей"?
> сишечка много поддерживает только за счет написания множества тулчейнов разными людьми.
> Зоопарк-с.А вот врать все-же не надо. Один и тот же gcc поддерживает хренову кучу всего. Поэтому освоив GCC 1 раз можно собрать код и под PPC, и под MIPS, и под ARM, и под x86-64, и даже можно из линя виндовый EXE собрать. И даже более, тот же ARMовый gcc - еще и под микроконтроллер код сгенерить не обломается. А запустить go на микроконтроллере... гагага, удачи.
"Хренова куча всего" и "Все" - разные вещи. Совсем. Если ограничиться только GCC - то Go практически все тоже самое из коробки умеет. Для эмбедовки он попросту не предназначен - GC-язык, нахрена? Речь о серверах, для которых он делался.
> "Хренова куча всего" и "Все" - разные вещи.С точки зрения "все" - простой тезис: на си можно запрограммить в разы больше разных систем и архитектур чем на Go. От процессора в фонарике до суперкомпьютера. Go гораздо более узкоспециализированный и я навскидку назову полдюжины архитектур для которых си есть а go нет и не будет, вероятно. Так что если все - так все.
> Совсем.
Для начала go явно не сможет многие задачи для которых си катит. Поэтому сама идея такого сравнения воняет синдромом утенка у кой-кого.
> Если ограничиться только GCC - то Go практически все тоже самое из коробки умеет.
Ну запрограмь мне на go STM32F103 тогда.
> Для эмбедовки он попросту не предназначен - GC-язык, нахрена? Речь о
> серверах, для которых он делался.Ах, если "вот так посмотреть - то вовсе даже и не кривой" :)
> веб сервис можно на чем угодно. например на perl.. Mojolicious.У перла синтаксис долбанутый и с прицелом под веб он не делался, поэтому веб-сервер на нем все-же будет выглядеть разлапистее. А еще он тормозной интерпретатор и не может быть собран в один 5-меговый бинарь в нативном коде, деплой которого сводится к копированию на сервак.
> те же самые несколько строчек чтобы поднять свой сервис. На perl пожалуй
> и попроще будет чем на go.Я думаю что для большинства людей на этой планете все наоборот.
> Про прикручивание rest/json за минуту- даже не смешно. На перле это 10
> секунд - чтобы вписать имя модуля...А все-равно у go'шных штук код симпатичный, простой и это не птичий язык а более-менее обычный curly bracket, т.е. любой студень CSовой направленности это сможет.
> и реализовано на фреймворках популярных языков.
Проблема с всеми этими фреймворками - в массе своей это динозавры из эпохи когда невъ...е монолиты генерили на каждый запрос не менее невъ...ные простынки. Но этот подход давно протух и ценность этого добра - ниже плинтуса.
> видны только людям в предметной области невежественным, ничего кроме бравурных статей
> о го не читавшихGo сделан теми кто практикует веб, для этого самого. А чтецы древней макулатуры о вебе могут и дальше разглагольствовать - веб станет развиваться без их участия, только и всего.
> Кстати у Го - отвратительная поддержка гетерогенных сетей. на многих платформах он
> просто не собирается. кроме винды и линуха-Так собственно на серверах оно обычно и есть, вот никто и не парится особо. Было бы кому-то надо - портанули бы наверное. Гуглу это явно ни к чему - на серверах у них Linux, а винда поддерживается наверное только из-за того что под ней некоторые разработчики.
Вот сразу видно человека, который с Perl знаком только по напевам Рабиновича.
> Вот сразу видно человека, который с Perl знаком только по напевам Рабиновича.Ну да. А чего в нем хорошего? У него одно достоинство - олдскульные хипстеры его разучили когда-то. Но это достоинство только для них. Остальным нет никакого резона с ним связываться. По крайней мере, я никогда нигде не видел внятного описания чем он лучше других. Только голимые надувания щек, при отсутствии результата глядя на который я бы сказал "вау, хочу уметь так же!"
>>> У перла синтаксис долбанутый и с прицелом под веб он не делался, поэтому веб-сервер
>> Вот сразу видно человека, который с Perl знаком только по напевам Рабиновича.
> Ну да. А чего в нем хорошего?Не знать, но рассуждать с умным видом, при этом обвиняя всех несогласных в надутии щек, старперности и хиптерстве …
Эпично )
> Не знать, но рассуждать с умным видом, при этом обвиняя всех несогласных
> в надутии щек, старперности и хиптерстве …Так достаточно почитать сообщения перловиков-затейников. Можно прямо на опеннете. Из аргументов за перл по жизни только "вы все лохи, а перл крут". Откуда и мнение про надутие щек и старперских хипстерах. Нубские хипстеры скорее go возьмут.
А потом можно врубить мозг и попытаться найти хоть 1 эпичный продукт на "крутом" ЯП. Иначе крутизна ЯП-а только теоретической получается. Но без практики теории цена в базарный день.
> Эпично )
Это опеннет, детка.
> А потом можно врубить мозг и попытаться найти хоть 1 эпичный продукт
> на "крутом" ЯП. Иначе крутизна ЯП-а только теоретической получается. Но без
> практики теории цена в базарный день.Ага. Только кое-кто не раз и не два влетал со всего размаху в небольшие водоемы со своими ценнейшими рассуждениями.
> Это опеннет, детка.Да-да, мы в курсе, теперь это называется
> Я не могу всего знать, поэтому приходится пользоваться небольшими лайфхаками и шорткатами.
> У перла синтаксис долбанутый и с прицелом под веб он не делалсяСкажу просто: фраза из разряда "у perl синтаксис некрасивый" обычно выдаёт низкий кругозор человека. Обычно её употребляют люди, которые знают один, ну от силы два-три языка одного семейства. Приходят они, смотрят на новый язык -- и вдруг осознают, что он не похож на то, с чем они работали до этого, и тут же ставят клеймо, мол, некрасивый, уродский, дурацкий.
Ребята. Поучите ещё языков, расширьте свой кругозор. Вы поймёте, что у perl синтаксис вполне себе нормальный.
Стандартный подход перловиков - надуть щеки, порассуждать о личных качествах собеседника, и ... решительно забыть показать крутой продукт на этом. Или пример как просто и быстро такой продукт сделать за 20 минут. А вот go'пники за этим в карман не лезут - кастомный http серв под микросервис у них как-то так и делается по жизни. И их пример кода и результат за себя сразу же и говорит.> Ребята. Поучите ещё языков, расширьте свой кругозор. Вы поймёте, что у perl синтаксис вполне себе нормальный.
Чувак, время - ограниченный ресурс. Поэтому до того как бросаться очертя голову его транжирить на черт знает что (ЯП в природе дохрена) - неплохо бы понимать что это может потом дать. Что дает знание go - понятно. Возможность решать практические задачи веба, быстро и ненапряжно.
> Стандартный подход перловиков - надуть щеки, порассуждать о личных качествах собеседникаДа, да. Был бы я ещё перловиком. )
> и ... решительно забыть показать крутой продукт на этом.
Bugzilla? parallel? Браузерки всякие (типа D&C)? CMS-ки? Большая тусня-то в perl-комьюнити.
>> Ребята. Поучите ещё языков, расширьте свой кругозор. Вы поймёте, что у perl синтаксис вполне себе нормальный.
> Чувак, время - ограниченный ресурс.И чтоб его не тратить попусту, нужен кругозор.
> Поэтому до того как бросаться очертя голову его транжирить на черт знает
> что (ЯП в природе дохрена) - неплохо бы понимать что это может потом дать.
> Что дает знание go - понятно.Разумеется, Вам всё понятно: https://bit.ly/2BMnDZd
> Да, да. Был бы я ещё перловиком. )Так и это про ситуацию скорее.
> Bugzilla?
Окаменелость. Функциональность хорошая, веб интерфейс ужасен. Пример как делали веб в XX веке. В 2018 не принято показывать абсолютно пустой экран 30 секунд. В последних версиях попытались сделать вид что тоже умеют танцевать, но получилось известно как.
> parallel?
Было бы очень круто. По меркам 2000 года.
> Браузерки всякие (типа D&C)? CMS-ки? Большая тусня-то в perl-комьюнити.
Именно, "в perl-комьюнити". Остальным такие продукты...
> И чтоб его не тратить попусту, нужен кругозор.
Валидный пойнт, но ЯПов много и неплохо бы пруфца что нечто стоит изучения. Если изучать все, можно умереть от старости или спятить в процессе расширения кругозора.
Когда go'пник показывает микросервис, с кастомным HTTP сервером, кода менее страницы, и он делает что-то полезное (с точки зрения создания веба), а мне более-менее понятно происходящее, ОК, яп за себя сказал: он хорош для этой задачи.
> Разумеется, Вам всё понятно: https://bit.ly/2BMnDZd
Да ну фигня. Я подозреваю что и у перла есть какие-то сильные стороны. Однако наглядной демонстрации оных я не видел. А в случае go каждый второй кто им пользуется на раз покажет сильную сторону. А теоретически-крутые ЯП - пусть ими теоретики и пользуются.
>> Bugzilla?
> Окаменелость. Функциональность хорошая, веб интерфейс ужасен. Пример как делали веб в XX веке.Ну не сказал бы, что окаменелость. Последний релиз был не так уж и давно. Bugzilla -- это прежде всего проект с хорошо продуманным дизайном. С монстрами типа Jira сравните, где вся логика в приложении, а не в базе.
> В 2018 не принято показывать абсолютно пустой экран 30 секунд.
Готовить надо уметь.
>> parallel?
> Было бы очень круто. По меркам 2000 года.Ну да, конечно. Тут некоторые говорят, что и shell нынче "не крут уже", "надо что-нибудь посовременнее".
>> И чтоб его не тратить попусту, нужен кругозор.
> Валидный пойнт, но ЯПов много и неплохо бы пруфца что нечто стоит
> изучения. Если изучать все, можно умереть от старости или спятить в
> процессе расширения кругозора.Lisp стоит изучать. Scheme. За макросы и удивительную гибкость, которую они предоставляют разработчику. Racket возьмите, он очень живой и активный. Можете также глянуть на SBCL -- этот лисп (как и все CL) очень заскорузлый, но CLOS является одной из лучших объектных моделей, что я видел.
ML надо изучать. За вывод типов. За понимание того, как устроены языки, в которых ошибки типа невозможны. Смотрите OCaml. Он даст понимание того, что ООП не очень-то и нужен, и что у него есть более крутые альтернативы в виде фанкторов.> Когда go'пник показывает микросервис, с кастомным HTTP сервером, кода менее страницы, и
> он делает что-то полезное (с точки зрения создания веба), а мне
> более-менее понятно происходящее, ОК, яп за себя сказал: он хорош для
> этой задачи.Ну в самом деле, на дворе 2018й год, кого этим удивишь? Стандартные модули для поднятия http-сервера с кастомными обработчиками есть во всех живых языках.
>> Разумеется, Вам всё понятно: https://bit.ly/2BMnDZd
> Да ну фигня. Я подозреваю что и у перла есть какие-то сильные
> стороны. Однако наглядной демонстрации оных я не видел. А в случае
> go каждый второй кто им пользуется на раз покажет сильную сторону.
> А теоретически-крутые ЯП - пусть ими теоретики и пользуются.Всё познаётся в сравнении. Для Вас это сильные стороны, а я вот все их видел уже так или иначе в других языках, меня так легко не удивить. Лично я считаю, что Go -- язык уже достаточно стабильный и перспективный. Но надо всё же отдавать себе отчёт, что это не революция. Это в некотором роде редизайн C, причём весьма неплохой.
А Perl ему противопоставлять не стану. У них разные области применения. И сильные стороны Perl искать в общем-то долго не надо. Надо смотреть в CPAN и думать.
> Ну в самом деле, на дворе 2018й год, кого этим удивишь?
> а я вот все их видел уже так или иначе в других языках, меня так легко не удивить.Так Go и не ставил задачу удивить. Прямо наоборот, сделали практичный язык, из которого выкинули все что может удивлять. И получился симпатичный язык на котором просто писать веб. И, как оказалось, системные утилиты и распределенные базы данных.
> rest/json прикручиваются буквально за минуту$ dotnet new webapi
я быстрее
> $ dotnet new webapiДа кому этот яваподобный ужастик с гигазами рантайма в вебе вперся? С ним те же тантрумы с деплоем что и с явой. Даже хуже. Особенно если Linux на сервере захотеть, потому что платить за серверную винду - смысла мало.
С go всех этих тантрумов нет принципиально. Гугл в отличие от мудасофта знает как вебню делать и какие там проблемы. А мс пытался собезьянить яву и протолкать всеми правдами и неправдами. Это получилось. Правда для веба оно еще более мучительное и глючное, пожалуй.
//И между нами, go'пник за день накодит то над чем дотнетчик будет месяц ипстись, при том оно будет довольно шустрым и простым как тапка в деплое.
> go'пник за день накодит то над чем дотнетчик будет месяц ипстись
> при том оно будет довольно шустрым и простым как тапка в деплое.И как же я раньше не догадался! Неделя на проект - и достаточно. Завтра же на работе выкину весь лишний код и заменю на GO. Будет шустрым и простым как тапка в деплое. И что пацаны на проекте пять лет делали?!
> что пацаны на проекте пять лет делали?!Дык, пля, дотнетчики. Я видел как они это делают и что получается. И это было ужасно. Нет, не так! Это был наихучший способ делать вебню из всех которые я знаю. Хуже дотнетчиков вебню на моей памяти не делал никто. Долго, дорого, медленно, куча технических проблем. А если MS не дай боже осчастливит новой версией дотнета - это вообще армагедец.
> Дык, пля, дотнетчики. Я видел как они это делают и что получается. И это было ужасно.Извиняюсь за мyдакoв, которые испортили Ваше впечатление о вполне себе рабочей технологии. Да и вообще, судя по Вашим словам, вы натолкнулись на какое-нибудь доисторическое говно вроде web-
forms'ов или silverlight. Все когда-то делают ошибки.
Вообще, сейчас на дотнете вебню не пишут. На дотнете пишут Апи, а к нему прикручивают ангуляр. Тут судите сами.> Долго, дорого, медленно, куча технических проблем.
Именно с такими заказчиками и работаем. Им не нужно "тяп-ляп, и в продакшен"
только вы забываете, что java-проги работают поверх jvm, которая отъедает ресурсы системы,
а go-проги компилируется напрямую в бинарный файл
Go и Java — это 2 разных мира, которые иногда пересекаются.В Go нет и четверти того, что есть в Java в виде фреймворков, крутых IDE, гридов, сложной рефлексии, различных спрингов, интеграций со всем и вся, maven-о-gradl-ов и т.д.
Но и Java уже стала слишком тяжелой для многих кейсов, где хорош Go.
Я склоняюсь к тому, что на Java должны строиться сложные backend-приложения из области Enterprise, которые параллельно будет пилить куча разных команд, еще и из разных подрядчиков, а Go хорошо подходит для микросервисов и низкоуровневых историй, где сборка мусора не является критичным недостатком, и которые пилит 1–5 людей максимум.
На Java будут дороже стоить начальные этапы разработки, но с ростом жирноты приложения дешевле будет поддержка и развитие, на Go — наоборот, дешевле будет начальные этап разработки, но если приложение будет жирнеть, поддержка и развитие будут головной болью.
Более 10 лет варюсь в java, из них лет 5 в энтерпрайзе.Все ничего, но зараза постоянная проблема с потреблением памяти.
Занимаюсь в основном порталами Websphere и Liferay 7, но всегда есть утечки.
В итоге раздуется и приходиться перегружать.
Понятно, что любое приложение может иметь утечки вне зависимости от языка и
можно сделать дамп и отпрофилировать и т.п., я не об этом.Сам по себе портал это жирнющий слон, в котором тьма библиотек и реально отследить качество становится врятли возможным. Т.е сама концепция построения таких монстров мне кажется неверной.
Да, возможно есть в этом удобство, но добиться стабильности сложно.Насчет Go, как-то совсем он мне показался наколеночным. В Crystal на удивление зацепил и думаю, это то, что нужно. Уже достаточно своих либ и производительность на высоком уровне. Буду рад если кто-то даст адекватное сравнение его с Go.
> Все ничего, но зараза постоянная проблема с потреблением памяти.Ну, блин, вы хотели GC и автоматическое управление ресурсами. Вы его получили. Вместе со всеми его прелестями. И если си и плюсы можно чем-то типа valgrind отгриндить от и до, то в случае GC понять есть утечка или нет - это такое очень отдельное приключение. Поэтому оказывается что через месяц почему-то все жрет 20 гигов RAM, но никто не знает что с этим делать, кроме как перезапустить неведому фигню.
> Насчет Go, как-то совсем он мне показался наколеночным.
На нем микросервисы симпатично смотрятся. Кода мизер, при том работает и даже не особо тормозит, да еще в нативный бинарь собирается. Ява и дотнет в этом сильно прос@сывают с своей рантайм компиляцией и адскими зависимостями/рантаймами, так что запуск этой фигни похож на предстартовую подготовку спейсшаттла к полету.
>> Ну, блин, вы хотели GC и автоматическое управление ресурсами.Я этого не хотел. Дело скорее не в GC, а в криво написанном коде.
При этом совершенно ясно, что утечку можно устроить в любом ЯП.
> Я этого не хотел. Дело скорее не в GC, а в криво написанном коде.Автоматическая сборка мусора делает все это довольно неочевидным и другого кода в большом проекте просто не бывает. И все виденные мной большие проекты на яве и дотнете - текли.
> При этом совершенно ясно, что утечку можно устроить в любом ЯП.
Но без GC - они во первых очевиднее, во вторых хорошо ловятся тематическими тулсами. Поэтому например сишных прог которые стабильны как скала и могут несколько лет вкалывать без перезапуска я видел более чем.
Верно, дело не в java а в кривом коде. Если нужно, памятью можно управлять вручную, уверен за 10-ть лет опыта в java вы знаете как это сделать, не буду писать об этом.
Еще как пример деградации монстра можно привести Eclipse.
Который от версии к версии становится все толще и толще, и работает все хуже и хуже.Реально напрягает тенденция.
Подумываю хоть как-то отчасти уйти от Java.
как бы бы есть 2 стандарта, либо эклипс, либо интелли идеа. Ест выбор - меняй, пробуй, кандалов нет. У нас например в конторе выбора нет
> уйти от Java.как бы вам не поменять шило на мыло.
Полностью конечно не получиться.Тут вопрос вот в чем, т.к. моя стезя это порталы, то альтернатив действительно особых нет. То, что сейчас есть работает на троечку, т.е. удовлетворительно с оговорками.
Просто, интуитивно понимаешь, что эти комбайны есть посредственное решение. Хоть садись и пили что-то свое. Нужна модульная архитектура с несколькими приложениями общающихся по тем же, например, юникс или тсп сокетам. Понятно, что это не так тривиально, долго и дорого. Ядро сделать на компилируемом эффективном языке, а модули, хоть на чем угодно, все что умеет через сеть. Весь этот деплой течет, OSGI по сути костыль. 9-ку с ее модульностью пока не смотрел, да и не поддерживается она толком нигде.
> Нужна модульная архитектура с несколькими приложениями общающихся
> по тем же, например, юникс или тсп сокетам.Ты почти изобрел микросервисы. А go... на нем они лаконично получаются. Собственно поэтому новые разработки все чаще и используют этот паттерн. Трах с глюкавыми переростками которых невозможно поддерживать всех заманал. Это и самой явы касается.
>> Это и самой явы касается.Это не проблема явы.
Была однажды тенденция делать комбайны, т.е. апп сервер + деплой в него приложений.Несложные решения работают на ура. Поставил Wildfly, собрал war, деплой. Все!
Все быстро и удобно. Съэкономлено туча времени. Будет работать быстро и стабильно.Но с усложнением и нарастанием кодовой базы(фреймворков) стабильность падает.
Вот, как пример, реализация портала. Он жирный и задеплоен. Тонны кода.
Вот тут уже начинаются проблемы.Решения для микросервисов есть и на жабе.
> Была однажды тенденция делать комбайны, т.е. апп сервер + деплой в него
> приложений.Была однажды тенденция - быть здоровенной фигней с маленьким мозгом. Динозавром называлось. А потом они сдохли и теперь другие тенденции.
> Несложные решения работают на ура. Поставил Wildfly, собрал war, деплой. Все!
Проблема только в том что go'пник делает в 5 раз меньше телодвижений с тем же результатом :)
> Все быстро и удобно. Съэкономлено туча времени. Будет работать быстро и стабильно.
Угу, видел я работу таких тим и как они "ъэкономят" время. Лучшая экономия времени и бабла - разогнать этих динозавров веба к чертовой бабушке. Корпорасы просто инерционные и не прочухали что климат изменился, до них доходит только когда дохнет последний из динозавров и поэтому они вообще не могут ни одного динозавра найти. Тогда они начинают задаваться вопросом "что за фигня?". Но за это воздается - даже винтики не больно рвутся использовать такую срань, делая это в минимально-необходимом объеме по принципу "а иначе уволят". А всякий там user-generated контент, социальная активность и прочие глупости... гагага, я видел тщетные потуги манагеров это увидеть в "корпоративных порталах". Но хреновость софта это сводит на нет.
> Вот, как пример, реализация портала. Он жирный и задеплоен. Тонны кода.
> Вот тут уже начинаются проблемы.Яву без проблем я вообще никогда не видел. Городские легенды говорят что так бывает, но мне не попадалось.
> Решения для микросервисов есть и на жабе.
Но когда есть go - нафиг не уперлось. На go это в разы проще и нет адского рантайма, дикого генератора кода на сервере, проблемного вендора и прочих характерных ява-прелестей.
Столько лирики и ноль здравого смысла.
Зачем ты столько пишешь чепухи, кого ты все разоблачаешь?Дружище, комбайны прекрасно работают до определенного момента и нет ничего зазорного использовать их, пока они делают свою работу хорошо.
Пиши на Go, у тебя его никто не отнимает.
> Дружище, комбайны прекрасно работают до определенного момента и нет ничего зазорного
> использовать их, пока они делают свою работу хорошо.Хорошо и плохо - относительные термины. Хорошо - по сравнению с чем? Впрочем можно и в абсолютных/субъективных метриках - я не знаю ни одного продукта на яве, к которому мне захотелось бы вернуться и попользоваться этим еще раз, потому что это видите ли понравилось.
> Пиши на Go, у тебя его никто не отнимает.
Я разберусь на чем мне писать. Речь не о том. А о том что пользоваться этим УГ можно только если топманагер обкурившийся рекламы прикажет, под угрозой увольнения. Поэтому уг и живет только в корпорациях по сути.
Не удивлюсь, если:а. Команда java-специалистов и команда go-специалистов (я хотел бы подчеркнуть слово специалист) напишут примерно одинаковые проекты с схожей архитектурой в сравнимые сроки.
б. После пятилетней поддержки проектов обе команды будуть выть от невыносимых мук бытия и ошибок прошлого.
Нифига. На Go только самоубийца будет делать монолит, делают микросервисы, а с ними ничего жирнеть не будет. Просто не надо пихать этот язык туда, где он не нужен.
Вообще, монолит будет делать только самоубийца. Достаточно посмотреть на то как мучаются с их майнтенансом и что получается - и почему-то резко захочется делать все в стиле микросервисов. Там такой задницы не образуется. Вообще, модуляризацию и логическое разделение софта на условно-независимые модули придумали как раз для того чтобы декмопозировать сверхсложную задачу на много простых.
Раскидать всё по микросервисам-это получить снижение производительности на порядок, для начала. Тема микросервисов далеко не нова, и ещё лет тридцать назад индустрия не случайно пошла по пути создания монолитов с модульной архитекторой, а не SOA. Такая организация превосходила SOA по ряду параметров. Использовнаие SOA было признано оправданным только для некоторого класса задач, когда одна крупная задача может быть разбита на ряд мелких, абсолютно никак между собой не связанных. Именно поэтому все известные демоны (прокси, вебсерверы, субд, почтовые серверы...)сейчас имеют монолитную модульную архитектуру, а не SOA. Это когда, например, прокси сервер разбить на кучу микросервисов: один крутит cache, второй сетевые соединения с клиентами, третий сетевые соединения с внешними ресусрами, четвёртый занимаетя аутентификацие и т.д, производительность такого прокси будет на порядки меньше чем у мнолитной программы.
> Раскидать всё по микросервисам-это получить снижение производительности на порядок, для начала.Это вообще ниоткуда не следует. Более того - в зависимости от взаимосвязей это может упростить масштабирование, например.
> Тема микросервисов далеко не нова, и ещё лет тридцать назад индустрия не случайно
> пошла по пути создания монолитов с модульной архитекторой, а не SOA.Индустрия веба 30 лет назад не существовала. Если это про создание операционок - ниоткуда не следует что паттерн который хорош для создания локального низкоуровневого ситемного core будет столь же хорош для создания какой-нибудь распределенной сетевой штуки. Как бы 30 лет назад таким если кто и заморачивался, то это какой-нибудь plan9, но там получилось инопланетно и все забили.
> Такая организация превосходила SOA по ряду параметров.
А сейчас насколько я вижу микросервисы в целом гораздо лучше вписываются в то чем пытается быть веб. Ага, сейчас никто не хочет видеть "generated in 1.015 seconds with 102 SQL queries". И получать одним куском 300 кило generated, с полным репарсом DOM Tree и порушеной картинкой мало кто хочет. Хотят сгонять XMLHttp, получить мелкую штуку, отапдейтить морду на основе этих данных. Тихо и незаметно, без мельканий и срыва взаимодействия человек-машина. В эту хотелку микросервисы удачно вписываются.
> Использовнаие SOA было признано оправданным только для некоторого класса задач, когда
> одна крупная задача может быть разбита на ряд мелких, абсолютно никак
> между собой не связанных.К этому следует стремиться. Даже в модульных монолитах типа Linux Kernel пришли к довольно независимым подсистемам которые можно относительно независимо патчить в дереве майнтайнера. Иначе разработчики давно выпили бы яду.
> Именно поэтому все известные демоны (прокси, вебсерверы, субд, почтовые серверы...)
> сейчас имеют монолитную модульную архитектуру, а не SOA.Монолитной архитектурой оно было бы если бы прокси, вебсервер, субд и почтарь были засунуты в один мега-сервис, при работе с которым выбирается - прокси вы сейчас хотите, почтарь или с субд поработать. Как работал бы гибрид прокси с почтарем и субд - все наверное уже догадались. Именно так, как сейчас работают корпоративные порталы на яве.
> Это когда, например, прокси сервер разбить на кучу микросервисов: один крутит cache,
> второй сетевые соединения с клиентами, третий сетевые соединения с внешними ресусрами,Любую идею можно довести до маразма.
Не-не, микросервисы-это как раз куча мелких, на полтысячи строк кода не больше. И вот, сейчас до того моразма с этими микросервисам как раз и начинают доходить, когда любую малейшую подзадачу обязательно выносят в отдельный микросервис, то есть, он, тот самый маразм, в современной реинкарнации микросервисов как раз присутствует. Это не когда разделяют прокси, почтовик, вебсервер по разным сервисам, а как раз когда каждый из этих сервисов дерибанят на ещё более мелкие составляющие, как выше с примером с прокси.
> Не-не, микросервисы-это как раз куча мелких, на полтысячи строк кода не больше.Значит у некоторых они дорастают до мини-сервисов, или типа того. А так - если кода сильно больше, оно уже с трудом в голову целиком умещается и соответственно пойнт в простом прозрачном юните, делающем что заявлено - начинает продалбываться. Хотя порог как мне кажется все же повыше 500 строк. Хотя, возможно, у хомяков стэк маленький - приходится учитывать.
> по разным сервисам, а как раз когда каждый из этих сервисов
> дерибанят на ещё более мелкие составляющие, как выше с примером с прокси.Кстати даже так оно может неплохо масштабироваться и по процессорам, и по машинам. А прокси по совсем классическим технологиям - упрется в 1 ядро 1 машины. И все, кукуй. При сильном желании отмасштабировать его конечно можно, но это будет то еще приключеньице, потому что изначальная конструкция такого не предусматривала принципиально.
> не понимаю смысла в том го. Нужен шикарный толстый корпоративный веб есть java+spring. Если что-то надо под больной нагрузкой, и более профессиональное, или более любительское - php.Рантайм явы раздут неимоверно, а нагрузку держит не сильно стабильно -- когда запускается сборщик мусора, обычно происходят нехилые такие проседания производительности. Сейчас Oracle божится, что наконец допилили многопоточный сборщик, но в текущем стабильном релизе явы его ещё нет. А Go начали пилить ещё до того, как у Oracle хотя бы даже на горизонте замаячило решение проблемы с GC.
php -- это вы правы, разве что под больНой нагрузкой. :)
Какие ещё варианты, "коллега"?
еще есть питон, который тот же php, только вид сбоку и шире, и капризней. Мне не нужен, но использующих не осуждаю. Го напоминает мне https://kore.io/ http://facil.io/ и прочие .. Нет, если надо - можно. Но это больше так, поковыряться, а не работа.
Ну а по производительности, никому она не нужны, дешевле пару серверов купить, ил пару десятков.
>> Ну а по производительности, никому она не нужны, дешевле пару серверов купить, ил пару десятков.Вот они, слова истинной веб-макаки! За это вас бизнес и ненавидит.
> еще есть питон, который тот же php, только вид сбоку и шире, и капризней.Я бы никому не посоветовал менять php на питон. В php, хотя бы научились быстро выполнять код и более-менее надёжно писать. По скорости питон близко не стоит к php
> еще ест питон/fixed
> Ну а по производительности, никому она не нужны, дешевле пару серверов купить,
> ил пару десятков.За это вас собственно и уйдут :D. Go'пникам и платить можно поменьше чем ява-сеньор-помидорам, чудес в производительности кодинга жабисты относительно go'пников уж точно не покажут, и оно все же не особо тормозит. Потому что когда целому гуглу надо в разы больше датацентров - гугл все же начинает напрягаться и оказывается что сделать ЯП может быть и подешевле чем строить в 3 раза больше датацентров. А остальным взять go вообще ничего не стоит, гугл оплатил R&D из своих собственных соображений :)
> Ну а по производительности, никому она не нужны, дешевле пару серверов купить, ил пару десятков.Конечно никому не нужна, и вышесказанное хорошо характеризует разработчиков на java. Дешевле будет java разрабов уволить, нанять гошников. Будет быстрее, качественнее и еще и сдача останется.
судя по количеству минусов это первая стадия - отрицания =)
Интересует собственно два вопроса:
1) Есть ли возможность подтягивать другие либы (например Qt) или использовать сборки на Go как либы в других языках?
2) Есть ли хоть какой-то намёк на десктоп, мобилки и всякий IoT?
1. Да можно, работа с DLL встроена, находишь bindы и вперед, на github есть под все. Я например писал своё приложения для работы с звуком используя bass.dll. Для линухов в Go вообще реализована система типа плагинов.
2. Сам язык заточен больше для написание сервисов а не приложений. Есть бинды для Windows GUI или QT, но как-то мне не пошло, я например предпочитаю делать вебморду, или telnet чтобы какой-то другой сервис управлял этим :)
Посмотри на какие платформы компилируется. Знаю что народ пишет на нем для raspberry и подобные, есть кто и для androidа лабает, но думаю это ближе к стрельбе из пушки по воробьям.
Как неписатель на Го, могу только на этот вопрос ответить:> 2) Есть ли хоть какой-то намёк на десктоп, мобилки и всякий IoT?
Пока экспериментировал со всяким софтом для своей мобилки, встречал launched написанный на Го - крутился значительно шустрее штатного с кучей эффектов. Но моё внутреннее полиси предписывает мне пользоваться по возможности тем что идёт из коробки (LineageOS) или из F-Droid. Вообще софта написанного на Го уже довольно много - например, пользующаяся бешеной популярностью у юзеров приблуда Syncthing. Для IoT как мне кажется Go толстоват, да и выбор платформ у него не так широк.
К вашим вопросам хотел бы добавить третий - а есть ли у языка библиотека абстракции GUI - чтобы не приколачивать его гвоздями к Qt или ещё чему-нибудь, а один раз понаделать окошек и таскать приложение в винду, линукс, андроид или вот теперь в экспериметальный порт для WebAssembly и чтобы оно там везде работало? :)
Ой, опечатался: launched => launcher
Не будет у него либы, есть проект shiny, но он загнулся практически. Google не заинтересован в гуе, сообщество всем советует даже для локалхоста веб-приложение писать.
> Для IoT как мне кажется Go толстоват, да и выбор платформ у него не так широк.С gccgo вроде бы выбор платформ достаточно широк.
никаких преимуществ это не даст, так нафига? техническая возможность есть.
+и к этому: "не понимаю смысла в том го"А,для того чтобы встраивать свою вирусятину в сам компилятор и егобиблиотеки
и/или-же незаметней - свой дыры в компилируемый код.
* свои
Гуглиться привязка к Qt5 смотрите https://github.com/kitech/qt.go
Относительно динамических библиотек (shared modules) все отлично, но есть одно замечание относительно работы с ними. Пробелма в планировщики горутин они мапяться на системные потоки как M:N, то есть совершенно непредсказуемо и нужно иметь либо Thread-Safe библиотеку либо обеспечивать прибивание гвоздями к потоку OS в Go, что сразу выглядит как-то неприятно.Именно по этому Google и предлагает писать приложения для LocalHost как Веб приложения, так как нет ограничения по скорости взаимодействия с UI.
Впрочем мое личное мнение, что им нужно что-то вроде XUL или FXML.
OS X 10.9 последний нормальный выпуск. Жаль что уходит в прошлое.
10.9 уже два года не поддерживается, если вы пропустили. ни security patches, ничего. как xp или ubuntu 12.04, os x 10.9 уже давно в прошлом, и golang тут не виноват.
я до последнего сидел на 10.8 (мне как раз 10.9 не понравилась), потом сдался.
Шёл 2048 год., люди всё продолжали писать на г* вместо Python/C++/C/Ruby
Шёл 8192 год, GIL как был в питоне так там и остался
и в этом же году на конференции С++192, Бьерн Страуструп сказал, что вот-вот в языке появятся модули.
Как же он 40 лет без модулей-то жил! Файл == модуль? Как это вообще? Это же недоступно пониманию! И потом, я привык, что программа должна начинаться со слова uses...
> Шёл 2048 год., люди всё продолжали писать на г* вместо Python/C++/C/RubyПо сравнению с ruby и python go пожалуй не такой уж и плохой. И на си/си++ он похож значительно больше, если уж на то пошло. Ну то-есть умея шпрехать на си/си++ можно и на go без особых напрягов что-то сделать. А у питона и рубей синтаксис как-то здорово другой, да еще они по жизни нитормозят, в нативный код хрен скомпилишь, поэтому деплой превращаетяс в мозгоклюй когда версия питона на полшишечки не та и все дохнет с трехстраничным трейсом.
А сборка, например, exe-хи "наколенными технологиями" - PyInstaller, cxFreeze - еще тот геморрой!
Не нравится скорость Руби - есть Crystal и Elixir. И, кстати, Ruby поживее питона будет
> Не нравится скорость Руби - есть САБЖ//Fixed
> Не нравится скорость Руби - есть САБЖда, но объем кода и его читаемость..... Руби любят именно за компактность и скорость написания кода. Как и производные от Руби - Crystal и Elixir
> да, но объем кода и его читаемость.....Они у сабжа офигенны, если надо что-то типа микросервисов. Полстранички тривиальной на вид штуки подымает кастомны
> да, но объем кода и его читаемость.....Они у сабжа офигенны, если надо что-то типа микросервисов. Полстранички тривиальной на вид штуки подымает кастомный HTTP который что-то делает. И в отличие от ruby это не тормозит и не требует кучи приседаний чтобы что-то по этому поводу сделать. А еще go'пники не греют мозг тем что конфигурация на сервере не та же что на девовской машине, так что оно при попытке деплоя сдохло из-за налета на отличия.
Go как-то совсем мне показался наколеночным. А Crystal на удивление зацепил и думаю, это то, что нужно. Нормальный ООП, уже достаточно своих либ и производительность на высоком уровне, компилится в бинарник. Буду рад если кто-то даст адекватное сравнение его с Go
Языки программирования сейчас являются одними из инструментов разработчика.Сейчас можно легко связывать ПО и библиотеки между собой, не зависимо от того, на чем они написано.
Пишите хоть на ассемблере)
Это понятно. Но связывание не всегда является тривиальной и быстрой задачей. Поэтому когда есть "уже из коробки", то это гораздо предпочтительней.
Бяда в том, что орхитекторы и прочие манагеры, начитавшиеся рекламной пропаганды о Го, какой он там прям весь распрекрасный, начинают принудительно затаскивать его в проекты, заменяя им развитые ЯП-ы, такие как C++, java... Дескать, просто пишется (любая бибизьяна разберётся и не будет проблем с ЧСВ приплюснутых разрабов), ошибок не бывает, и т.д. В реальности же Go-это лютый дауншифтинг, типа авиация опасна, авто опасно, электричество опасно-залезаем обратно в пещеры, так безопаснее, вот это и есть Go.
Ох и подгорает у некоторых! :-)ЛуДший ёзыГ для систем-програминга - вёдра там всякие, драйвера и вот это всё - это _С_ !!! ТЧК.
Ну и вот - люди, которые долго и нудно пытались сделать из С ёзыГ для клёпки нет-аппс .... через ХЗ сколько лет таки это сделали! sweet rvenge - си для нет апп девов :-р
> Ну и вот - люди, которые долго и нудно пытались сделать из
> С ёзыГ для клёпки нет-аппс .... через ХЗ сколько лет таки
> это сделали! sweet rvenge - си для нет апп девов :-рДа ладно, какой-нибудь lwan даже довольно гламурен. И быстр как понос, держит несколько рекордов скорости. Но для дешевых взаимозаменимых хомячков язык где хомяк на логотипе наверное пойдет :)
Остаётся вопрос - а на чём же писать библиотеки? И тут появляется такая неожиданность, что библиотеки написанные на go можно использовать только из go
>Остаётся вопрос - а на чём же писать библиотеки?А ты их из любви к искусству пишешь? Или таки для какого то бизнес кейса ?-)
>И тут появляется такая неожиданность, что библиотеки написанные на go можно использовать только из goКакая неожиданность! А питонячьи - только из питона, я ребешные - только из ребе, а жабские только через жэвээм, а плюсячьи вообще лучше не использовать :-D
ЗЫЖ - как и все последние 30 лет - пиши их на сях. ТЧК.
> А ты их из любви к искусству пишешь? Или таки для какого
> то бизнес кейса ?-)Библиотеки пишут для реюза кода в дальнейшем, внезапно.
> а плюсячьи вообще лучше не использовать :-D
Иногда таки используют. Правда обычно апи вывешивают все-таки сишное. Потому что плюсовое хрен из чего дернешь кроме плюсов. И как угодно но косяк с code reuse ЯП ни разу не украшает.
> И тут появляется такая неожиданность, что библиотеки написанные на go можно использовать только из goИнфа устарела. Из Си можно, и таким образом из всего остального.
Добавили в Go 1.5, который вышел 3 года назад."There are several other changes. The most significant is the addition of a -buildmode option that expands the style of linking; it now supports situations such as building shared libraries and allowing other languages to call into Go libraries."
> Сейчас можно легко связывать ПО и библиотеки между собой, не зависимо от
> того, на чем они написано.Чичаз. У языков могут быть довольно разные абстракции и их гейтование друг в друга может быть не слишком пресным. Либы на си - их да, все более-менее умеют пользовать. Все-равно ОС вывешивают такое апи через либы которые интерфейсы к вызовам ядра. Поэтому все умеют в эти интерфейсы. А раз так - то и остальные сишные либы подцепляют.
> Пишите хоть на ассемблере)
На асме при желании можно ABI как у сишной либы вывесить. Но придется переписывать либу под разные системы команд. У них еще и ABI разный, кроссплатформенность не получится.
>реализована поддержка инструкций AVX512 для архитектуры amd64В каком таком проце от AMD есть поддержка AVX512?
Хотел сумничать, а показал невежество.
Речь об архитектуре AMD64, которую Intel затем лицензировала и стала использовать под именем EM64T.
Расширение AVX512 от Intel для той же архитектуры - никак кардинально архитектуру не меняет.
И то что у AMD сейчас нет процессора, который поддерживает AVX512 (а только AVX2) - никакого дела к названию архитектуры не имеет.
В архитектуре AMD64 нету вообще AVX512. AMD чтобы использовать AVX512 должна сначала купить у Intel лицензию на AVX512. В итоге невеждой оказался ты сам.
Им не надо покупать, т.к. давно заключено кросс-лицензионное соглашение. И да, AVX (тогда оно еще называлось SSE5) придумали в AMD и позже доработали вместе с Intel. С разморозкой.
Кросс-лицензирование и прочие вещи не отменяют того факта, что AMD не выпустила ещё ни одного процессора с поддержкой AVX512.
Когда-то была IA64 но её закопали еще в 2000-е, теперь тотальное засилье amd64.
Так же как и небыло в EM64T.
Архитектура vs. расширения к архитектуре, да.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"Всё, что надо знать про игого
> Всё, что надо знать про игогоТак у него и логотип честно говорит на кого ориентировано. Но это лучше чем питон который вечно "не тормозит" и тем более франкенштейны из ада типа явы, которые для создания вебсервиса подходят как паровой молот для вешания картины на стену.
Да фигня, я лично больше тащусь с другой его фразы, типа: "мы делали ёзык для С\С++ программистов, но ВНЕЗАПНО!!!(Tm) к нам пришло 100500 миллионив питонщегоффф 8-о"
Всё таки Роб классный :-)
Но он же прав
>> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python.Гениально! Отсыпь...
Тоже повеселило. Возможно автор по молодости лет никогда не видел семейство Pascal. Ну и вполне простительно не иметь понятия о семействе CSP. Возможно кроме Питона он вообще ничего толком не знает, вот ему и кажется, что что-то взято оттуда. А может просто путает происхождение языка с его основной ЦА.
Скорее всего он почерпнул эту информацию в русской Википедии.
"сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок"
Звучит как ускоренный курс молодого бойца. Компилируемость = производительности.
скриптовость = конвейер для будущих мартышек.
Правильно, куда лучше сочетать чтение между строк с высасыванием из пальца.
Они идут к сахару на Си с новыми терминами?
"inline-развёртывание кода" - раньше это называлось вставка компиляции
Оно называлось inline и развертыванием кода задолго до появления Go. Но не исключаю, что в каком-нибудь дурацком переводе могло называться и "вставка компиляции". Не читай переводы, читай оригиналы.
"Предложен пакет go/packages с реализаций простого API для поиска и загрузки пакетов с кодом на языке Go. API пока не включён в стандартную библиотеку, но может применяется в качестве эффективной замены пакета go/build, обеспечивающей поддержку модулей;"
Ребята водят публику по кругу
"Улучшено качество отладочной информации, генерируемой для оптимизированных исполняемых файлов. Обеспечено сжатие отладочных секций в формате DWARF. Добавлена экспериментальная возможность вызова функций на языке Go из отладчика;"
достаточно вызвать событие отладки чтобы выполнить свою функцию?
GOPATH звучит как путь Дзен
Ниша у Го как у ассемблера - писать темные консольки и либы которые будут призывать другие аппы)
lol no generics
> lol no genericsЧ-чо, лолка, лисповые макросы ниасилил?
Мудачье хейтит отличный язык. Пишу и буду писать прекрасные вещи на нем. Удачи всем ;)
Чем старше становлюсь тем меньше беспокоит мнение школьников относительно Golang решившего проблемы последних 20 лет в один релиз. Респект и уважуха.Вы кстати уже попробовали новую штуку с модулями в 1.11?
А расскажите пожалуйста поподробнее какие именно проблемы последних 20 лет решил Go за один релиз?
Проблему высоких зарплат разрабов, вестимо.
Дык я ж писал уже ... сделали сишечку для _не_ сисемщегофф, и в отличие от прошлых попыток оно взяло и взлетело 8-)
> Дык я ж писал уже ... сделали сишечку для _не_ сисемщегофф, и
> в отличие от прошлых попыток оно взяло и взлетело 8-)Так правильно. Сишечка все же требует понимать как компьютер работает. Это для дешевых хомячков, кодящих вебню слишком крутое требование. Да и низкоуровневый он по умолчанию. Можно исправить, прицепив либы, но в go кастомный http сразу в полстранички умещается. На си так тоже можно, но все-же придется поставить дополнительные либы. А это значит что хомячков придется учить основам компьютерной грамотности, и вообще. Неудобно.
> Сишечка все же требует понимать как компьютер работает.Да ты шо? Неужто без хорошего знания физики далеко за рамками школьного курса программировать на С невозможно? Или твое "понимание" сводится к простым вещам вроде двоичного представления и косвенной адресации?
> А это значит что хомячков придется учить основам компьютерной грамотности
Ты всерьез считаешь, что программировать легче, чем загуглить и поставить нужную либу?
> Так правильно. Сишечка все же требует понимать как компьютер работает. Это для
> дешевых хомячков,Ох уж эти элитарии.
В конце девяностых, начале двухтысячных, когда питон еще не был таким уж популярным, вполне можно было еще наблюдать за использованием сишечки вместо питончика соотв. контингентом. И все у тех "работало" - ну, если закрывать глаза на шедевральные воплощения поиска данных (в лоб и перебором, ведь мы слишали, что сишка шустрая, а если все еще тормозит, поспрашиваем на форумах, как переписать на асму) или читая данные с сокета recv(realloc(oldsize + 1) ...).
> сишечка требует понимать как компьютер работает, чтобы делать то, для чего требуется понимание, как этот самый ящик работаетПоправил в стиле КО,
ваш КО
Одно я понял что здесь хейтят и обсирают любые языки и технологии эникеи-неудачники которые ничего за всю свою жизнь не создали, больше всего улыбает когда эти дятлы поднимают вопрос о нужности какого либо языка ))))ps второй раз прочитал коменты на опеннете, считаю что коменты к новостям только занимают драгоценное место на диске
Так они же тупые !!!!!
Они ничего в жизни не добились , вот и кукарекают
И таких тупых ослов будет полно во все времена .
Самое лучшее , что можно сделать это просто не обращать на них внимания , как будто они пустое место .
> И таких тупых ослов будет полно во все времена .
> Самое лучшее , что можно сделать это просто не обращать на них
> внимания , как будто они пустое место .И необращающие внимание без перерыва, три дня и три ночи, спешат сообщить всем, как они не обращают внимание!
Ваше мнение очень важно для нас ...
Золотые слова!!!!!
Если бы все считали, что вчера всЁ уже сделали, притом
лучше, чем сегодня.....
то в одной руке до сих пор держали бы палку-копалку,
а в др. каменюку....
По всем бенчмаркам go медленнее даже C#
Билли, нам нужны пруфы
люди добрые, подскажите как собрать проект под windows 64, все уже обыскался (((