Интересует, есть ли у нас, в Украине кто-то, кто активно интересуется языком Google Go, кроме меня =), или хотя бы пробовал что-то писать. Интересует также отношение к этому чуду техники, а также желание работать с этим языком в ближайшем будущем...
Если 20, то можно что угодно учить, все пригодиться. Если 40, то тоже что угодно, пофиг по возрасту не пройдете. Если 60, то А-а-а-а-а-а-а-а, ходячие мертвецы....
если 80 — однозначно учить, последняя надежда
Надежда на что?
Через покупку в нем недвиги?
habrahabr.ru/…mpany/mailru/blog/325046
www.jtolds.com/…-and-you-should-feel-bad
Валялкина и Весельчака У не слушай никогда и ни в чём.
Для меня минусов сильно больше, чем плюсов. Единственная большая польза — располошить болото и проложить дорогу примерно тому же, но нормальному, а не с 100500 идиотизмов на ровном месте.
для Валялькина те статьи наоборот высветляют преумещества Го над другими языками
Я пробовал. Ощущения очень положительные. Язык писаны прогерами для прогеров. Причем очень опытными прогерами. Забугром очень много вакансий. У нас, как обычно. Пользовался Littleide. И дебаг и остальное вполне нормально.
С очень много это преувеличение. Indeed.com — 683 вакансии
https://www.indeed.com/jobs?q=golang&l=
Та же скала или свифт например дает почти в 10 раз больше предложений (не говоря уже о питоне с джавой)
https://www.indeed.com/jobs?q=swift&l= (5679)
https://www.indeed.com/jobs?q=scala&l= (5456)
С очень много это преувеличение. Indeed.com — 683 вакансии
НУжно смотреть вакансии где слово голэнг в subject, иначе получаешь большинство вакансий с го как необязательное требование.
И получается что вакансий го аж 53: www.indeed.com/jobs?q=title:golang
против 10 тыс на джаве: www.indeed.com/jobs?q=title:java
В этом случае теряются вакансии с названием наподобие «Software Engineer», некоторые крупные компании именно такие вакансии объявляют, например https://www.uber.com/ru-UA/careers/list/?city=all&country=united-states-of-america&keywords=&subteam=engineering&team=engineering
Но даже если и так — процентное отношение приблизительно сохраняется.
Да, теряются для всех.
Поэтому я и писал —
процентное отношение приблизительно сохраняется
Пользовался LittleideПопробуйте Gogland от Jetbrains.
Предпочитаю фришные, если они есть.
вот, хорошая статья для наброса, ну и просто для подумать: cowlark.com/2009-11-15-go — сравнение языка Go с неким языком X (X в конце раскрывается)
только в статье они почему-то скобочки в коде Go неправильно переносят) я конечно понимаю, что это больше для сравнения с синтаксисом алгола (думал правда, что это какой-нибудь раст), но все же)
з.ы. ну а по большому счету по синтаксису не шибко то и отличаются в некоторых местах (хотя в целом отличия есть, но имхо больше косметические, нежели какие-то принципиальные). А вот насчет начинки алгола (что язык реально может по функционалу?) — хз, никогда алгол не юзал.
Я не в Украине но немного трогал.
Отношение не очень — с Java 8 на это переходить надо быть поехавшим
а вот как замена PHP для хyяк хyяк в продакшен наверно таки ок
Спустя полтора года коньюктура изменилась на противоположную — на Java 8, Scala и nodejs остаются только поехавшие, а все остальные переходят на Go.
Спустя полтора года коньюктура изменилась на противоположную — на Java 8, Scala и nodejs остаются только поехавшие, а все остальные переходят на Go.Судя по постам одного местного гокнутого, «поехавшие» в Го сообществе приходят таки не из джавы, а из питона. Так что возможно вы и правы. :)
Поехавшие сильно количественно доминируют ))
это массовый психоз
Umptun в «Radio-t» сказав що він лайно і в якійсь статті на Хабрі написано що він лайно.
Очень вредно читать треды программистов
особенно споры про язык. В итоге не хочется учить ничего....
Go оставляет смешанные чувства, с одной стороны рутины и каналы позволяют писать high throughput сервисы быстро и просто, плюс легкий деплоймент с жирным статик бинарником. С другой стороны инфраструктура полнейший кал, нормального дебага нет, поддержки IDE нет (идеевский плагин — не очень) и отдельный случай это go get — самый отвратительный и примитивный пакетный менеджер который я видел. Да и программисты на го обычно просто херачат процедурную лапшу с высокой связностью кода и не заморачиваются над low couping/high cohesion, тестами, модульностью...
p.s. А еще interface{}, interface{} everywhere.
поддержки IDE нета как же LiteIDE github.com/visualfc/liteide ?
go get — самый отвратительный и примитивный пакетный менеджер который я виделдо go get еще не дошел, но возможно это правда — нодовские и и питоновские (npm и pip соответственно) думаю действительно удобнее будут.
программисты на го обычно просто херачат процедурную лапшутак вроде Go и есть процедурный язык, т.е. на нем писать процедурную лапшу — это то, что доктор прописал как я понимаю))
и не заморачиваются над low couping/high cohesion, тестами, модульностью...ну тесты на го вроде можно писать, хотя возможно большинство го-кодеров ими действительно не заморачиваются)))
Го вполне себе ООП. Просто он там урезан до пределов разумного. Там гораздо меньше возможностей доя «мозгового онанизма» чем в С++. Для тех, кому главный принцип «чем сложнее тем лучше», альтернативы плюсам нету.
Просто он там урезан до пределов разумного
Есть мнение и не только мое что отсутствие дженериков и обработка ошибок ретурн кодами это сильно дальше пределов разумного.
Зато сразу видно, есть обработчик ошибки вообще и где он.
Проблема го в том что 90% обработчиков ошибки перекидывают ошибку на уровень выше, загромождая код бесчисленными _,err := f() if err != 0 {return err}
С исключениями тоже самое, но строк больше. Но тут по крайней мере сразу видно что делается с ошибкой. Не нужно лезть может быть даже в другой файл, придумывать название исключению итд. Не, если кодить по принципу «чем сложнее тем лучше», то исключения наше все.
Как то ты по всем пунктам промахнулся.
пример в студию!
Напиши короче.
if err != 0 {return err}
gofmt это отформатирует на 3 строчки.
В джаве проброс exception делается добавлением throws MyCoolException в сигнатуру метода. Теперь примени свои познания устного счета до
Ну так и напиши это все в том-же формате. Вместе с
try {
}
Для проборса эксепшна наверх никакого try не нужно.
Блин. Докажи что эксепшины короче. Напиши обработку одного из них в три строчки.
Я тебе написал про проброс эксепшна наверх а не обработку.
Вот вот. Зачем просто если можно сложно. Ошибка в одном месте, обработка в другом. Да еще и название ошибки возьми и придумай.
openmymind.net/…or-Handling-Good-And-Bad
Такой подход обработки ошибок годиться для типичных нишевых задач го — во всех остальных случаях — локализация, обработка ошибок связанная с контекстом это боль. Exception стиль однозначно лаконичней и безопасней особенно там где есть глубокая цепочка вызова. В принципе как и со всем остальным инструментарием го, в других языках тоже можно писать подобный код — но этого никто не делает, по простой причине — это неудобно при высокоуровневом программировании.
Основная проблема го как языка в том, что разработчикам дали ограниченый инструментарий и не дали выбора — паралельные вычисления, обработка ошибок, работа с коллекциями, управление зависимостями и тд. Для каждой задачи хорош свой инструмент, а вы радуетесь что вам дали silver bullet от всех бед заставляя работать так, как на других высокоуровневых языках делали
Вот честно. Я никогда не понимал исключений. Более того, я в кайфе от Го, как раз потому что у разработчиков ЗАБРАЛИ то чем некоторые разработчики мягко говоря очень сильно злоупотребляли. А это ООП и перегрузка операторов. Мое личное мнение что видение C++ от разработчиков QT гораздо ближе к «решению проблем за деньги». А вот С++ в исполнении от авторов новых стандартов 11 итд, гораздо ближе к мозговому онанизму. Не, може есть какие-то прогеры, которые разумно решают проблемы, которые не делают несколько классов чтобы строчку на экран вывести, но чаще я обратное видел, когда сплошное «программирование ради программирования».
Вот что действительно silver bullet это возврат нескольких параметров. Вот это реально АФИГЕННО. defer тоже афигенно. Про многозадачность, и реализацию этого в Го, тоже афигенно. Сталкивался с тем что некоторые прогеры тупо дико бояться многопоточности. Считают что сделав нить, сразу посыпятся дедлоки и прочая фигня. Авось простота реализации нитий в Го что-то изменит.
Да, а какая ниша у Го? Вот традиционные проги на нем писать, с окнами итд, тут проблемы. Я тут лучше чем QT и доработанные плюсы от них, не вижу. Если ГУИ нету, и ресурсов достаточно, то тут Го рулит.
В нормальном коде на go в обработчиках ошибок принято добавлять челевекочитаемое описание, прежде чем вернуть ошибку в return. Это делает сообщения об ошибках простыми понятными для пользователей программы.
В языках с эксепшнами (java, c++) сообщения об ошибках выглядят как огромный нечитаемый стэктрейс, содержащий максимум 5% полезной информации. Также эти стэктрейсы занимают дофига места в логах и трудно грепаются по контексту где-нибудь в середине стэктрейса.
В программах без эксепшнов и без поддержки возврата нескольких значений функции © сообщения об ошибках обычно получаются короткими, но совершенно непонятными для пользователей. Например, «error code 12345».
Стектрейсы очевидно нужны для того что бы посмотреть иерархию вызовов где произошла ошибка. Если тебе такая иерархия неинтересна, ты можешь ее не печатать.
Серьезно? И шо сильно помогает такая информация?
Вопрос идеологии языка.
Например в даже в сложном С-шном коде редко встречается вложенность больше
В случае фатальной ошибки мы просто вываливаемся по exit()
В случае нефатальной ошибки (например недоступности ресурса) код ошибки передается далеко не первый уровень, обычно на
«Канонический» С++ подход изначально максимально усложненного кода не позволяет нормально обработать ошибку в месте ее возникновения и поэтому не оставляет другого выхода, как применять goto с разверткой стека, чем по сути и является эксепшен.
Это классическая ситуация, когда одно неудачное инженерное решение тянет за собой цепочку других, еще более неудачных.
Мне кажется ты дилетант в области в которой пытаешься умничать.
Классический для ДОУ ответ. С удовольствием послушаю разъяснения знатока.
После трех попыток обьяснить тебе проблему с ретурн кодами в го, с которой все остальные в интернете согласны, я оставляю тебя разговаривать дальше самим с собой.
проблему с ретурн кодами в гоВ go нет никакой проблемы с return-кодами, и возвращать принято не код, а объект, поддерживающий интерфейс error. Кто считает этот механизм обработки ошибок якобы неудобным, может пользоваться panic/recover, который работает аналогично throw/catch.
В go нет никакой проблемы с return-кодами, и возвращать принято не код, а объект, поддерживающий интерфейс error.Как я уже писал в другом коменте проблема в перегруженности кода конструкциями на каждый чих:
Эксепшны позволяют иметь более чистый код.
Ну или делать обработку макросом как в расте.
panic/recover для ретурн кодов использовать не рекомендуют и никто так не делает, т.е. тебе прийдется пихать везде ретурн коды, потому что вся остальная экосистема (библиотеки) так устроена.
Эксепшены позволяют свалить все потенциальные ошибки в один нечитаемый core-dump и сказать, что это такая фича.
Я уже обьяснил что я думаю по поводу твоего мнения. Можешь меня больше не коментировать.
Т.е. ответить нечего. ч.и.т.д.
Исключение — операция сильно умнее, чем просто гоуту. Т.к. попутно разворачивается стэк, с вызовом деструкторов.
C++ (и C#) используются для намного более крупных систем, чем написанные на C. Соответственно, введение исключений было целесообразно, т.к. обработка ошибок возвращаемыми значениями в таких системах — ведёт к обширному замусориванию кода, невозможностью доставить ошибку (с информацией об ошибке) «наверх», невозможностью покрыть все ошибки кодами, итп проблемами больших систем.
Отсюда и пользование исключениями в крупных проектах, несмотря на весь оверхед (где-то +10% к размеру бинарников и к времени исполнения).
В средних/мелких системах, вполне можно пользовать обработку ошибок возвращаемыми значениями. Go пользуется именно для таких задач . соответственно, исключения ни к чему.
C++ (и C#) используются для намного более крупных систем, чем написанные на CЯдро линукс написано на С. Поэтому это не крупная система.
В гугле 2 миллиарда строк на джаве и ц++ против 20 млн у ядра линукса.
Ну и ядро линукса — это специфическая ниша, к тому же ц — это еще и вопрос наследия.
Ядро Линукс — это мелочь.
В общем-то, с правильными настройками компиляции ядра — можно в ядре Линукса оставить лишь шедулер в сотню строк кода. :)
В принципе синтаксис языка очень хороший, но есть пару вопросов, на которые не увидел ответов. Поддерживается ли ОС-многопоточность (не путать с сопрограммами) внутри виртуальной машины Go, и если да, то каким образом реализована синхронизация? Не получится ли такой вариант, что код просто переключается между тредами, а не исполняется в нескольких одновременно внутри одной VM.
В документации по Go сказано: “Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run”
У Go нет виртуальной машины — это компилируемый язык.
Вот здесь слайды о Concurrency паттернах в Го РобаПайка talks.golang.org/...2012/concurrency.slide#46
Вообще на тему “Concurrency is not parallelism” в Го есть много написано.
Если я правильно понял о чем речь.
Вопрос был в том может ли Го расползаться по процессорным ядрам. Как я понимаю, сейчас все работает в одном процессе, с кучей потоков.
Нет. У Go runtime есть параметр runtime.GOMAXPROCS(int)
Вобще, чтобы закрыть вопрос: вот статейка с примером Concurrency, Goroutines and GOMAXPROCS -> www.goinggo.net/...tines-and-gomaxprocs.html
А здесь с картинками www.goinggo.net/...eduler-tracing-in-go.html
Но больше — не всегда лучше :)
Go использует пул потоков поверх которых шедулит горутины, в 1.5 добавили возможность задавать cpu affinity. Так что можно даже контролировать на каком ядре будет раниться горутина.
в 1.5 добавили возможность задавать cpu affinity. Так что можно даже контролировать на каком ядре будет раниться горутинаЗнаю про runtime.LockOSThread, знаю про runtime.GOMAXPROCS, а вот про возможность задавать cpu affinity из Go не знаю :( Может, вы имели ввиду taskset?
Да, сетить GOMAXPROCS=1 и сетить cpu affinity через taskset. Но это работает только в случае если сервис stateless и есть кому балансить между инстансами.
Но суть в том, что в Java, .Net этого не сделать никак.
Но суть в том, что в Java, .Net этого не сделать никак.Не «никак», а «зачем»?
Да. Я проверял. Запускал дофига (мильен или мильярд) потоков, каждый из которых инкрементировал общую переменную внутри мютекса. Результатов не помню, но и на все процессоры расползлось и система не легла.
инфраструктура полнейший кал, нормального дебага нет, поддержки IDE нет (идеевский плагин — не очень)Не проверяй информацию — отвечай на форумах
На тот момент ещё не было даже анонсировано. Вы на дату то смотрели?
И правда, не посмотрел. Но теперь, оглядываясь на положение дел в 2015, мы можем с уверенностью сказать, что Go идет семимильными шагами в будущее и уже не ищет свою нишу, а расталкивает в стороны заржавевших и покрытых пылью динозавров индустрии со своего пути!
Скорее пока что сравнение с мышью путающейся под копытами стада слонов.
Забавная закономерность: хейтеры Go имеют некую предрасположенность к длинным названиям. И не важно, будь то названия классов в энтерпрайзе или должность в аккаунте на доу. Сколько же времени было потрачено на эти названия?)
Возможно, это сможет как-то облегчить вашу работу projects.haykranen.nl/java
кто хейтер? я хейтер? Та мне все равно на чем писать. Просто опусы фанатов Го заставляют реально кататься по полу от смеха. Это уже какой-то культ и секта. Я уверен что хороший язык с кучей преимуществ. Но так же и с кучей минусов. Как и другие современные языки. Но такие сектанты от Го отбивают всякое желание как-то участвовать в дискуссии
Кстати, в моей подписи есть смысл, она не рендомная. Но да, сектантам это, наверное, сложно понять
Но так же и с кучей минусов. Как и другие современные языки.Так в том-то и дело, что у Go есть отличительная особенность от других современных языков — у него как ни странно, нет никаких минусов. Гениальность архитектуры Go состоит в том, что при наложении любых минусов, они дают плюс! Ну а участвовать в дискуссии с сектантами — не бойтесь, если что я постараюсь помочь вам донести до них мессадж, чтобы они аргументировали нам необходимость перехода на Go, не вызывая хейтерства у исчезающе малой аудитории программистов других языков.
вот теперь я честно надеюсь что это троллинг. Иначе у меня для тебя плохие новости
вот теперь я честно надеюсь что это троллинг. Иначе у меня для тебя плохие новостиГоворите правду, какой бы она ни была. Буду надеяться, что с плюсами Go всё в порядке.
вух, точно троллинг, отпустило )
Но теперь, оглядываясь на положение дел в 2015, мы можем с уверенностью сказать, что Go идет семимильными шагами в будущее и уже не ищет свою нишу, а расталкивает в стороны заржавевших и покрытых пылью динозавров индустрии со своего пути!В этом жилмассиве будет установлено 740 газовых плит. То есть ровно в 740 раз больше, чем было во всём нашем городе до 1913 года! Как много мы достигли со времен царизма!
Для желающих учить язык на боевых задачах есть такая вот штука golang-challenge.com
Pavlo Suikov
меня интересуют только мыши, их стоимость, и где приобрести
в GlobalLogic
02.11.2015 17:07
В нише Go есть ржавчина, и ржавчина милее моему сердцу.
Ржавчина недостаточно юзабельна и стабильна под вэб, хотя мне она тоже милее.
интересно, а ним — это тоже на эту нишу претендует, или нет? просто тоже думаю глянуть как-нибудь глянуть его, когда более «взрослый» релиз нима будет.
Ну и раст может тоже гляну сравню с го (хотя как я понимаю раст сложнее будет).
Где сейчас rust, а где go? Не на тот язык программирования поставили.
Pavlo Suikov
меня интересуют только мыши, их стоимость, и где приобрести
в GlobalLogic
15.04.2017 23:33
Инженерия — не тотализатор и не фондовый рынок; ржавчина как была, так и остаётся милее моему сердцу.
Rust слишком сложный для среднего программиста, поэтому он всегда будет в роли отстающего. Даже у короля суперсложных языков программирования — С++ — не сможет отжать существенную долю, т.к. любители парадигмы разработки «чем сложнее, тем круче», останутся верны С++.
Pavlo Suikov
меня интересуют только мыши, их стоимость, и где приобрести
в GlobalLogic
20.04.2017 14:22
Вы доказываете совершение мной некоей ошибки, вынуждая оправдываться за то, что я руководствуюсь собственным мнением, а не статистикой; скажите, в чём смысл этого агрессивного конформизма? «Всё больше людей выбирают синий цвет в качестве любимого, потому любить зелёный — глупо и неправильно»?
Мне нравятся Rust, REBOL, Tcl, Haskell, Elm, CL, J, Agda. Это технологически красивые языки, их семантика радует меня как инженера. Я также руководствуюсь оценкой бизнес-рисков при выборе языка/технологии реализации той или иной задачи, потому на практике пользуюсь и С++ и, скажем, JS. Я не вижу, как эти вещи друг другу противоречат, или почему второе должно запрещать мне делать первое; и я тем более не вижу, чем можно оправдать логику напёрсточника в техническом дискурсе.
потому на практике пользуюсь и С++ и, скажем, JS. Я не вижу, как эти вещи друг другу противоречат, или почему второе должно запрещать мне делать первоеСамое главное, чтобы это не запрещало делать проекты на Go, и тогда будет всё нормально.
вот я недавно заинтересовался им. Пробую выполнять задачки из golang-book.ru — пока норм) так в целом язык нравиццо)
Интересно, насколько Go на 2015 год востребован в мире и в Украине в частности? может кто в курсе? или он еще (или уже) «не выстрелил»?
Вот компании которые уже пользуются языком в своих продуктах: github.com/golang/go/wiki/GoUsers
Думаю что найдешь знакомые названия.
Го «выстрелил» уже давно, просто к нам это только сейчас доходит. Но даже в Украине уже появляется больше вакансий на нем, что конечно не может не радовать.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Потихоньку начинает втягивать =)!
Го, я думаю, постигнет та же участь.
За Д не стоят корпорации которые способны вливать деньги и использовать в своих проектах, так цтхо у го есть некоторое преимущество как минимум в этом плане.
А что там слышно про F#? За ним тоже стоит корпорация.
А много проектов внутри гугла используют Го.
ИМХО, это был язык «тупо для ПРа», а не для того что-бы им пользовались. Хотя посмотрим через пару лет.
> А что там слышно про F#? За ним тоже стоит корпорация.
Ну так F# и не позиционируется как универсальный язык-замена си, поэтому про него и не должно быть много слышно...
> А много проектов внутри гугла используют Го.Это вопрос или утверждение?...
Таки вопрос, ибо я не про один не слышал.
Я думаю что снаружи гугла очень сложно судить о том на чем там пишут в принципе; -)
Плохой из вас предсказатель — github.com/…uage:go stars:>1000&type= - Go входит в top6 наиболее популярных языков программирования на github, обогнав С, С++, PHP и HTML.
Теперь моя очередь предсказывать — через лет пять, максимум десять все забудут Scala и nodejs как страшный сон.
Теперь моя очередь предсказывать — через лет пять, максимум десять все забудут Scala и nodejs как страшный сон.насчет скалы — может быть, а вот насчет ноды... я вот могу пованговать, что через 5 лет максимум на экмаскрипте для ноды напишут свою реализацию Go)
через 5 лет максимум на экмаскрипте для ноды напишут свою реализацию GoВполне может быть. Вон уже придумали async / await. Через пару лет поймут, что программисты тупые и не могут справиться не только с калбэками и промисами, но и правильно расставить эти асинки с эвейтами в большинстве случаев. После этого «изобретут» jsroutine’ы с channel’ами. Серверный js наконец-то станет в чем-то похож на go. Но уже будет поздно, т.к. 99% программ будут писаться на go.
Вот классный доклад на эту тему m.habrahabr.ru/…y/oleg-bunin/blog/311554
Чувак, честно, я тоже считаю гошные корутины и каналы удобнейшим инструментом для реализации многопоточных задач. После них ни нода, ни другие платформы и языки мне не дают той гибкости в реализации задуманного, что дает Го. Но даже мне, кто не применёт затереть за Го при удобной возможности, твои комментарии на этом форуме в пользу Го кажутся перебором. Со стороны они реально кажутся фанатичными и незрелыми имхо.
Go хорош не только горутинами с каналами, но и другими инновационными решениями:
— простым синтаксисом и go fmt, благодаря которым сторонний код на go легко читать, понимать, расширять и рефакторить;
— отсутствием «убийц времени», существенно замедляющих разработку программ на практике — эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и generic’ов;
— высокой скоростью компиляции, благодаря которой программист большую часть времени остается в «потоке» и пишет код, а не катается на гироскутере в барбершоп и вейп-бар, попивая смузи, ожидая завершения компиляции после каждой однострочной правки кода.
— сборкой программы в один самодостаточный бинарник без каких-либо внешних зависимостей. Это автоматически решает типичные проблемы деплоя новых версий программы — dll hell, dependency hell и jvm hell и избавляет от костылей в виде docker’а;
— кросс-платформенной компиляцией out of the box — программу можно скомпилировать под любую поддерживаемую платформу на любой платформе. Например, под виндой собрать бинарник для линукс или наоборот;
— поддержкой всех необходимых средств для тестирования и замеров производительности out of the box. Благодаря этому тесты с бенчмарками на go пишутся и читаются очень просто;
— поддержкой профилирования по cpu, memory allocation’ам и блокировкам out of the box. Причем профилирование можно включать/отключать удаленно в продакшн в любой момент времени, и это не снизит существенно скорость программы;
— стандартной библиотекой, содержащей действительно полезную на практике функциональность, а не сферических коней в вакууме;
— ....
— PROFIT!!!!
Все эти фичи или надуманы или более качественно реализованы в джаве + куча других плюсов — несравнимо большее внедрение в индустрии и экосистема.
Все эти фичи или надуманы или более качественно реализованы в джаве + куча других плюсов — несравнимо большее внедрение в индустрии и экосистема.
Я далек от java, но попробую пройтись по вышеперечисленным пунктам в контексте java:
— синтаксис java нельзя назвать простым по следующим причинам:
— он многословен;
— в нем много ненужного хлама, затрудняющего понимание программ;
Также в java принято писать абстрактные фабрики визиторов синглтонов через обязательный inversion of control на каждую строчку кода, что сильно затрудняет понимание java-кода.
— в java присутствуют почти полный набор «убийц времени» — эксепшны, наследование, перегрузка функций, конструкторы и generic’и. Хотя с C++ в этом плане тягаться сложно :)
— скорость компиляции java вроде повыше, чем у swift, rust, scala и C++ , но все же не дотягивает до go;
— для запуска java программ на сервере нужна минимум jvm. Отсюда jvm hell — попробуйте быстро и безболезненно перейти на новую версию jvm. Также, насколько я знаю, для запуска java программ требуется много
— с кросс-платформенностью у java вроде норм, не считая того, что для запуска java-программы нужна jvm на целевой платформе;
— насколько я знаю, в стандартной поставке java отсутствуют стандартные средства для тестирования, замеров производительности и профилирования программ. В итоге имеем зоопарк из несовместимых решений посредственного качества;
— стандартная библиотека в java с одной стороны переполнена устаревшим хламом и кучей бесполезных штук, а с другой стороны, в ней отсутствуют удобные средства, требующиеся в большинстве программ;
он многословен;Он многословен потому что после многих дебатов решили не вводить полное выведение типов (даже Гостлинг патч отсылал) в угоду читабельности
Также в java принято писать абстрактные фабрики визиторов синглтонов через обязательный inversion of control на каждую строчку кода,если правильно выбирать фреймворки — то не принято
в java присутствуют почти полный набор «убийц времени» — эксепшны, наследование, перегрузка функций, конструкторы и generic’и.Это сохранители времени
скорость компиляции java вроде повыше, чем у swift, rust, scala и C++ , но все же не дотягивает до go;В джаве правда тебе не нужно компилировать все-все как в го, в репозитории лежат скомпиленные джарники
Отсюда jvm hell — попробуйте быстро и безболезненно перейти на новую версию jvm.Раскрой что это такое? Не вижу проблемы.
замеров производительности и профилирования программ.В стандартной поставке есть профайлер, семплер, инструментатор, которому го как до луны.
стандартная библиотека в java с одной стороны переполнена устаревшим хламом и кучей бесполезных штук, а с другой стороны, в ней отсутствуют удобные средства, требующиеся в большинстве программ;Это твое личное мнение.
В джаве правда тебе не нужно компилировать все-все как в го, в репозитории лежат скомпиленные джарникиdouble facepalm:
— go поддерживает кэш скомпилированных модулей, поэтому перекомпилируются только измененные модули, а время инкрементальной компиляции огромных проектов редко превышает пары секунд (обычно меньше секунды);
— хранить в репозитории бинарники с джарниками — это моветон. В go-репозитории принято хранить только исходники. Это позволяет избежать кучу проблем:
— Для перехода на новую версию go достаточно скомпилировать проект новой версией, а не искать/ждать джарники зависимостей под новую версию джавы;
— Обновление кода всех зависимостей сохраняется в истории изменений, поэтому легко отследить, что, где и когда менялось. С джарниками видно только, что тогда-то пришел новый блоб, но совершенно не понятно, что в нем изменилось;
— Код зависимостей можно самостоятельно изучать и править под собственные нужды, не дожидаясь, пока авторы джарников соизволят внести требуемые изменения и выложить новые джарники;
— размер репозитория не увеличивается со скоростью сотни мегабайт в неделю за счет обновлений джарников.
— go поддерживает кэш скомпилированных модулей, поэтому перекомпилируются только измененные модули, а время инкрементальной компиляции огромных проектов редко превышает пары секунд (обычно меньше секунды);Я говорил про изначальную компиляцию. Пока что го живет в мире небольших студенческих поделий, в котором нету больших инфраструктурных проектов это не критично. Но когда/если го дорастет до больших деяний, этот недостаток остро прочувствуется. А инкрементальная компиляция и в джаве есть понятно.
а не искать/ждать джарники зависимостей под новую версию джавы;
Это ты опять коментируешь какие то странные свои фантазии.
С джарниками видно только, что тогда-то пришел новый блоб, но совершенно не понятно, что в нем изменилось;
Опять новости из альтернативной вселенной.
В мавене зависимости лежат отдельным от джара файлом: central.maven.org/…3.5/commons-lang3-3.5.pom
И даже есть веб интерфейс где их смотреть можно: mvnrepository.com/…commons/commons-lang3/3.5
размер репозитория не увеличивается со скоростью сотни мегабайт в неделю за счет обновлений джарников.Я думал лишние 100 мегабайт на диске ни для кого проблем уже давно не вызывают, но возможно у нищих программистов на го жизнь более трудная.
В мавене зависимости лежат отдельным от джара файлом: central.maven.org/...3.5/commons-lang3-3.5.pomЭто не зависимости, а классический нечитаемый xml с описанием зависимостей плюс кучей бесполезной инфы. Как с помощью этого xml собрать проект без доступа к интернету?
Никак. В текущем тысячилетии у программистов как правило есть интернет.
Для читабельных зависимостей мавен поддерживает разные форматы, и еще есть грейдл: github.com/…/blob/master/build.gradle
еще есть грейдл: github.com/.../blob/master/build.gradleА в go вместо всего этого несовместимого между собой зоопарка и тонн
С чего ты взял что он несовместимый между собой?
Грейдл прекрасно работает со всей мавен инфраструктурой — и тащит зависимости и умеет их публиковать.
Я думал лишние 100 мегабайт на диске ни для кого проблем уже давно не вызывают, но возможно у нищих программистов на го жизнь более труднаяСпасибо, напомнил еще одну причину тормознутости билдов на java — ведь для каждого билда нужно вытянуть из инета пару гигабайт репозиториев с джарниками :)
В случае го — это исходники, которые не факт что меньше, которые еще и скомпилить нужно.
Непонятно чем ты гордишься.
Ну и вытягивать нужно один раз в жизни, подле этого джарники кешируются локально.
В случае с go исходники всех зависимостей принято хранить в своем репозитории. Поэтому бинарники компилируются без доступа к интернету и получаются идентичными на любом компе в любое время, если собраны из одной ревизии (aka reproducible builds) одной версией go.
В случае с go исходники всех зависимостей принято хранить в своем репозитории.Что, весь гитхаб вместе с лаптопом продают? Совсем не зачем в интернет ходить?
Если твой проект зависит от всех проектов на гитхаб, то придется положить в репозиторий весь гитхаб. Но обычно ограничиваются максимум парой десятков зависимостей.
В интернет ходить нужно только за обновлениями зависимостей.
Менеджмент зависимостей в го это та ещё жесть, хранить на гитхабе и напрямую тянуть оттуда сорцы это идея печаль конечно, не зря менеджер зависимостей считался одним из ключевых недостатков . Потом придумали все версии хранить в репозитории вендоринг- лол — в принципе стандартный функционал всех пакетных менеджеров, только если в других языках это делат сам пакетный менеджер — то программистам го на это надо полагаться самим, так как нормального пакетного менеджера в него так и не добавили. Вся эта эпопея с организаций, поиском и подключением исходников и их дебагом напоминаете подключение зависимостей в браузерах на java script в 2000х — до появления ноды. Очереднаная next gen фича в стиле го.
Пока что го живет в мире небольших студенческих поделий, в котором нету больших инфраструктурных проектов это не критично. Но когда/если го дорастет до больших деяний, этот недостаток остро прочувствуетсяТак и запишем — «программисты в гугл пишут на go студенческие поделия», «docker и kubernetes — типичные студенческие поделия», «dropbox и uber — ни разу не большие инфраструктурные проекты».
Если ты имеешь ввиду под большими деяниями типичный кровавый ынтырпрайз из гигабайтов бессмысленного кода, то будем надеяться, что go там не приживется. Пусть в этой нише остается java и c# :)
Мне кажется в гугл как раз джава абсолютно преобладает над го, все офисные и бизнес преложения(дашборды, адвордс, джимейл, и т.д.) пишут на ней а не на го.
Тебе это только кажется. Го достаточно популярен в Гугле, особенно в новых клауд проектах. Го как раз и сделали что бы не надо было на сях и джаве писать там где они не нужны, а надо «хряк хряк и сервисы на го».
Тебе это только кажется. Го достаточно популярен в Гугле, особенно в новых клауд проектах. Го как раз и сделали что бы не надо было на сях и джаве писать там где они не нужны, а надо хряк хряк хуяи сервисы на го.
Го не справляеться с задачами для написания бизнес логики как высокоуровневый язык. Поэтому даже там где его берут крупные продуктовы компании — область его применения ограничиваеться написанием медиа сервера или автоматизации инфраструктурных задач. Отдельные примеры это скорее исключения из правил — написать можно на чем угодно при желании, но для большинства это попрежнему не удачный инструмент для бизнесс логики.
Наоборот, отлично справляется с написание бизнес-логики. Утиная типизация для приведения к интерфейсам во многом упрощает взаимосвязи между объектами. Кроме того, в задачах зачастую каждый объект обладает какими-то своими свойствами, в ООП на основе классов это приводит к нагромождению классов и построению всевозможных костылей и даункастов для взаимосвязей между ними, в то время как в прототипном ООП и в Go таких проблем вообще не возникает.
— Код зависимостей можно самостоятельно изучать и править под собственные нужды, не дожидаясь, пока авторы джарников соизволят внести требуемые изменения и выложить новые джарники;
Иногда вот думаешь, вроде бы и язык неплох под свои задачи есть интересные идеи и некая простота, но любое желание попробовать писать на нем отбивает понимание того, кто пишет на этом языке. кровавый энтрпрайз java вскоре утратит истинную глубину возможного пиздеца происходящего на проекте.
зы: почитай как улучшить свой подход использу возможности го на полную мощь
i.imgur.com/7IQbWD9.png
Раскрой что это такое? Не вижу проблемырасскажи, как безболезненно обновить версию jvm на сервере с кучей жава-программ, чтобы ни одна из них не поломалась при обновлении. На go достаточно перекомпилировать все программы с помощью новой версии go и залить скомпилированные бинарники на сервер, который даже не знает, что такое go. Причем компилировать можно на рабочем макбуке или винде, а потом залить на сервер под линукс. Специально настроенной билд-машины или билд-окружения не нужно.
apt-get update
apt-get upgrade
Согласен со всеми пунктами, и хочу сказать спасибо что нашёл время все так детально описать. Но, вновь таки, об этом стиле я и говорил: твои комментарии выглядят _фанатично_.
Вместо короткого ответа ты пишешь простыню. Возможно ты полагаешь, что чем чаще ты будешь описывать прелести языка Го, чем чаще ты будешь отстаивать честь Го во флеймах касающихся его, тем больше людей заинтересуются им, но на деле это вызывает обратный ефект. Это _отпугивает_ их.
Если ты пытаешься быть «евангелистом» Го, то, по моему мнению, тебе следует пересмотреть свою медиа-стратегию. Нужно тоньше доносить новое знание.
Вместо короткого ответа ты пишешь простыню.Читайте в таком случае больше мои ответы, они в короткой и доступной форме позволяют мгновенно проникнуться великими идеями разработки на Go, и незамедлительно влиться в передовое и прогрессивное сообщество программистов Go.
1. Синтаксис относительно-простой у любого ЯП. Сложность программ не в синтаксисе, а в размере.
2. Отсутствие дженериков — это жирный минус.
3. Hебольшие программки быстро компилируются на любом языке. А большое проблематично написать, без всего этого: «эксепшнов, наследования, перегрузки операторов и функций, конструкторов, неявных преобразований типов и generic’ов».
4. Сборку в 1 бинарник позволяют многие линкеры. «Статическая линковка» называется.
5. «под виндой собрать бинарник для линукс или наоборот» — означает, что в бинарник будет включена «виртуальная машина». А это сразу удар по памяти/быстродействию.
6. Cредства тестирования/отладки/профилирования — это API операционной системы. А значит, вызовы в С (как правило). Ничего «своего» тут нет.
В общем, для небольших проектиков — покатит. :)
«под виндой собрать бинарник для линукс или наоборот» — означает, что в бинарник будет включена «виртуальная машина». А это сразу удар по памяти/быстродействию.Во-первых, в go нет виртуальной машины — там рантайм, как в си.
Дык, а что такое ентот «go рантайм»? Поддержка рефлекшена, сборщик мусора + абстрагирование от операционки. Виртуальная машина и есть — хоть ты её «go рантайм» назови. :)
А значит, элемент тормознутости и раздуватости, т.к. прямых вызовов в API операционки из приложения нет — вместо этого, вызовы идут в «виртуальную машину». А сама «виртуальная машина» (по-крайней мере, те её части, что пользуются приложением) — добавлена в бинарник.
Во-первых, в go нет виртуальной машины — там рантайм, как в си.
В С/С++ нет никакого «рантайма» в бинарнике. Тебя обманули. :)
Так это рантайм-библиотека. Под каждой операционкой своя реализация — для того, чтобы приложение напрямую, делало вызовы в API операционки. В бинарник при этом, подлинковывается лишь код для вызова функций API операционки. Никакого уровня/прослойки абстрагирования между операционкой и приложением — нет (бинарники непереносимы).
Вот и сравни с «го рантаймом».
Бинарники go тоже непереносимы — они собираются под конкретную платформу. Про кросс-компиляцю слышали?
Единственное отличие рантайма go от рантайма си в том, что в go рантайме дополнительно реализованы горутины со сборщиком мусора. В остальном рантайм-либы go и c выполняют одинаковую роль -
являются прослойкой между программой и операционной системой. Где вы тут нашли виртуальную машину, которая должна исполнять специальный байткод, как в jvm?
Где вы тут нашли виртуальную машину, которая должна исполнять специальный байткод, как в jvm?Зато есть ряд технологий, которые сопутствуют в реализациях многих VM: garbage collector и ограничение прямого управления памятью, механизмы reflection, передача контекста исполнения, благодаря которому можно писать полноценные замыкания, а не просто lambda-функции как в C++.
передача контекста исполнения, благодаря которому можно писать полноценные замыкания, а не просто lambda-функции как в C++.В go эмуляция замыкания — компилятор определяет, какие сущности из внешнего контекста используются внутри лямда-функции и генерирует код для автоматической передачи только этих сущностей в замыкание. Хранить и передавать полный контекст исполнения, как в js, не нужно, т.к. в go нет eval, который мог бы обратиться к дополнительным сущностям из внешнего контекста, которые нельзя обнаружить на этапе компиляции.
А какая на ваш взгляд его идея, и самое главное какая ниша?
Поскольку железо прогрессирует и требует все новых дров, то ниша где -то здесь, но не только, имхо.
Для того что бы влезть в нишу С у го есть проблемы с производительностью и потреблением памяти, что в свою очередь видимо последствия RTTI и GC.
Они вроде как позиционируются как язык програмирования для серверных производительных апликух на многопроцесорных системах, посмотрим одолеют ли они Java и C#.
Еще прикалывает такой момент: в индустрии вроде как устоялись некоторые соглашения для синтаксиса языков, типа присваивать с помощью «=», при обьявлении переменной вначале идет ее тип, слово ’null’, и т.д., но некоторые самые умные (Go, Scala) постоянно что то изобретают, и программистам каждый раз приходится ломать многолетние привычки.
Коментар порушує правила спільноти і видалений модераторами.
Такие (сишные) соглашения присутствуют у наверное всех мейнстримных языков: C/C++/Java/C#/python/php То есть можно говорить о томч-то 90−95% процентов програмистов имеют такие привычки.
О ужс, теперь типы указываются после переменной. Что же мы будем делать без MyClass myClass = new MyClass();
А если по теме, то вас никто не заставляет писать на языках с таким синтаксисом. То что вам неудобно, не значит что это неправильно. Если в целом можно рассуждать о правильности того или иного синтаксиса.
там сишные модули генерятся, вроде?
techcrunch.com/...le-go-language<> Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. In our experiments with Go to date, typical builds feel instantaneous; even large binaries compile in just a few seconds. And the compiled code runs close to the speed of C. Go is designed to let you move fast.<>
Генерить сишный код для го — это альтернативный проект, в гугловской версии обычный компиллер в обычном понимании этого слова.
Ну и си он как я уже сказал проигрывает по производительности как я уже сказал: shootout.alioth.debian.org/...q/benchmark.php test=all& lang=go& lang2=gcc
И джаве тоже кстати: shootout.alioth.debian.org/...q/benchmark.php test=all& lang=go& lang2=java
То есть идея правильная (си на стероидах), но реализация пока не впечатляет.
зы (краснея):, а рынок, это — мы))
Кстати, почему именно Го? Не практичнее ли учить какой нибудь ерланг, если уж захотелось чего то за пределами мейнстримных Java/.NET/C/C++/C#/python/PHP/etc?
Я имел в виду что на ерланге есть некоторый шанс найти работу прямо сейчас, а на го еще некоторое время не предвидется и будуще более туманное.
Принципиальная основа — например поддержка reflection и garbage collector. Собственно go ведь не первая попытка сделать более высокоуровневый язык для системного программирования чем си. Были ведь уже и ocanl, java, c#, d, но как показала практика наличие некоторых фич и производительность конфликтуют друг с другом.
А чем питон не годится как язык общего назначения?
Думаю в ближайшее время этим языком будут интересоваться только гугл для внутренних вещей, и энтузиасты early adapters, в серьезных проектах это вряд ли появится в ближайшее время, тем более в Украине.
Если бы мне сейчас предложили работать на Go — пошел бы не задумываясь),аналогічно
Та вони є, навіть в Києві. Я як мінімум 2 знаю.
А ось контрактни в UK наприклад www.indeed.co.uk/...Developer-jobs-in-England
від 300 до 600 фунтів в день :) ииии
ПЖ — 11 років! 🎂
Jim Moriarty
Artem Bondarenko
Valentin Nechayev
anonymous
Artem Bondarenko
Gonchar Evgen
Andy W
minodvesP Vasya
Нестор Иванович
Aliaksandr Valialkin
onemore
Victor Musienkо
Mikhail Shmagailo
Дмитро
VС
Mikhail Boiko
Roman Khavronenko
Mikhail Boiko
Юрій Ярош
minodvesP Vasya
Oleh Kuchuk
A B
crypto5
Stanislav V
crypto5
Gremlin
Gremlin
168 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів