Как перейти на Go с других языков?
Есть неплохой ресурс помогающий перейти Python разработчикам на Golang — www.353.solutions/py2go/index.html
Есть ли что-нибудь подобное для PHP или C++ ?
Как, вообще, проходят трансформации?
Svetlana Malezhyk, Talent Acquisition Consultant в Valtech
Facebook
Twitter
LinkedIn
anonymous
Просто читаешь книжку Go Programming Language. Потом пишешь на Go. У меня в команде все пишут на Go фуллтайм и все пришли с разных языков (кто с Java, кто с Scala, кто с PHP...) и только один парень пару лет писал на Go до этого. И ничего, гребем.
flyman
шото много свитчеров на ГО с С++,
хрестанутих колбасит, илс 3.!4да хрестам незабаром?
Леголас Трандуилович
Gennady Dogaev
Свидетелей Го много :)
Свидетелей Го много :)
и главное, ни одного потерпевшего
Artem Bondarenko
У го, есть особенность. Если с плюсами читая чужие исходники ты сразу понимаешь какое ты ничтожество, и потом приходит понимание что те исходники писал онанист, то с Го ты сразу понимаешь что ты крут и только читая чужие исхоники ты приходишь к мысли что ты ничтожество. Возможность онанировать в Го сильно ограничена.
Artyom Krivokrisenko
В Го ты понимаешь что ты ничтожество, читая свои исходники на Го.
Потому что другие не решили теже проблемы в разы проще и быстрее?
Мне нравится что в Го можно поставить ловушку которая будет ловить обращение за пределы массива итд, которые происходят внутри функции. Это будет сыпать ошибками но не крашить все. Есть время решить, а нада эта фунция вообще или нет? Как часто она нада итд.
Да и вообще, есть принцип KISS en.wikipedia.org/wiki/KISS_principle мильярд раз убеждался что это единственный спосооб сделать что-то сложнее ширпотреба.
Это будет сыпать ошибками но не крашить все.
Хорошая попытка, гоубои, но я предпочитаю On Error Resume Next
Vladyslav Melnyk
Мне нравится что в Го можно поставить ловушку которая будет ловить обращение за пределы массива
try catch
Чего? Плюсы в принципе не могут ловить выход за пределы масива, если это не класс с перегружеными операндами.
Шарп может, джава думаю тоже, на плюсах придется повелосипедить.
Во-во. Повелосипедить. И велосипедов этих... qstring, string, что-то во всяких boost есть... Сколько этих велосипедов только общеизвестных? И каждый уважающий себя онанист от С++ считает своим долгом изобрести свой.
Да мне впринципе пофиг на плюсы какой мне резон переходить с шарпа на го?
Да ХЕЗ. KSP под линухом бегает наура. Я написал всего одну прогу на C# и было это когда я был молодым и счастливым, деревья были большими а .NET в бетах ходил.
KSP под линухом бегает наура
Только на пониженных настройках. И если сраный unity еще в KSP хоть немного оправдан, то в куче сраных 2Д игор — вообще нет
Спрайтовые игры на юнити, скайп на ноде, куда мы катимся???
Скайп это какой-то треш последнее время. Похоже что мелкомягкие забили на него на всех системах кроме своей. Сегодня скайп упал и запускаться перестал вообще. Что делать, не знаю. До этого вообще какие-то дикие глюки были, тупо они меня не видят я их не вижу. Не можем друг друга в контакты внести. Пытаюсь на google hangout перейти, вайбер или что-то еще.
А 3д в спрайтовых играх на удивление оправдан. Еще лет дофига назад нужно было разобраться чем рисовать кое что совершенно не стандартное. Оказалось что OpenGL кроет традиционные методы как бык овцу: текстура грузится в память видеокарточки (довольно дорогая операция) и дальше отрисовывается очень быстро, хоть прозрачно хоть не прозрачно, короче как угодно. Если добавить антиалиасинг в рисовании линий, сплайнов итд, короче мне понравилось.
Сегодня скайп упал и запускаться перестал вообще.
Это не баг, это фича: As announced earlier this year, the old Skype for Linux v4.3 is at its end-of-life and will be decommissioned in the upcoming weeks.
You will be automatically signed out of Skype until you update. Please, update to the new Skype 8.x, which is ready for you with lots of improvements at Skype.com.
Алсо, новый скайп требует 64бита и ssse3
Что делать, не знаю.
Попробуй через онлайн клиент web.skype.com/en
А 3д в спрайтовых играх на удивление оправдан. Еще лет дофига назад нужно было разобраться чем рисовать кое что совершенно не стандартное. Оказалось что OpenGL кроет традиционные методы как бык овцу: текстура грузится в память видеокарточки (довольно дорогая операция) и дальше отрисовывается очень быстро, хоть прозрачно хоть не прозрачно, короче как угодно. Если добавить антиалиасинг в рисовании линий, сплайнов итд, короче мне понравилось.
А вот давайте не путать 3д движки и API для доступ к графическому акселератору. Рисовать 2д сцены через OpenGL это норма. Юзать юнити/UE4 для 2д сцен — не норма.
Да, да. Я уже понял, когда за 5 минут до интервью, скайп сказал что нада апгрейдтится. Я успел. Вот только новый скайп, который 64бита, и ssssssssssssssssssse3 рухнул и снова запускаться отказывается.
У меня скайпа еще на телефоне есть.
Я думал что юнити это просто какая-но надстройка над OpenGL.
Anton Taranov
Я думал что юнити это просто какая-но надстройка над OpenGL.
facepalm.jpg
Dmitry Panfilov
ты сразу понимаешь какое ты ничтожество
уже говорили про вашу самооценку?
Oksana Chuiko
пишу на го уже больше полугода, у нас вся система на микросервисах, а микросервисы на го. Щаслива. Джаву оставьте себе.
По теме- переход как обычно -книжку, туториалы, задачи и пошел.
Как обычно, это «кошмар, караул, все пропало, быстро погнали». Попутно желательно совещаться кто чего прикольного раскопал.
Хороший язык — это не тогда когда щаслива, что пишешь полгода на нем, а когда щаслива что поддерживаешь код, написанный полгода назад, а с этим у гоу все грустно
Как удалить «поддержан»? Я ошибся. Как раз у Го все хорошо.
Как удалить «поддержан»? Я ошибся.
Спалился, гоухейтер!
еще раз жмакни на поддержан
рылли? поддерживаю и дописываю в код, написанный пару лет назад, в то время как попытка запустить код на ноде возраста 8 месяцев провалилась в адский депенденси хелл
Нода не прощает ошибок, отсюда более высокие требования в плане квалификации. Хуяк Хуяк и в продакшн уже не получится. Вам не повзло разгребать код после таких деятелей, ничего не поделаешь.
NewOne NewOne
Никита Дмитренко
java умирает ?
ну как в фильме про живых мертвецов, вроде ходит и кусается, но чето не то (((
Первое пророчество о смерти джавы я услышал в 6 лет.
Чем-то мне напоминает, как Рамзан Кадыров как-то хвастался, что первого русского он убил в 16 лет)
Artyom Krivokrisenko
Кто отбывает срок в гопрозории, плиз, поделитесь новостями, дженерики уже добавили?
не и слава богу
Добавили, но только пользоваться ими можно только Робу Пайку и компании, а не гоферам. Достаточно просто посмотреть на исходники slice.go...
Корнєєв Дмитро
были фоновые задачи и глобальная будущая на го. пока делал фоновые, в течении недели прошел go tutorial, после этого начал делать постепенно глобальную новую на го. туториала хватило, чтобы разобраться с новшествами синтаксиса, понять как пишутся каналы, горутины. после этого просто решал задачу. теперь новые сервисы пишутся на го
Aliaksandr Valialkin
Вас услышали и в go1.10 добавили Round. Осталось добавить дженерики
Iliya Isd
Я перешёл так: нашёл клиента, которому был нужен сложный бекенд-сервис и сделал его на Go. Получилось классно: и язык изучил, и сервис хорошо получился, т.к. для таких целей язык самое то.
А либ под Go уже довольно много. Но заказов и вакансий пока что сравнительно немного. Народ ленивый, любит нодочку. Я вот недавно был на конференции и слушал разбор там одного кейса, как решали проблему в нагруженном сервисе. Хотелось сделать фейспалм и посоветовать перейти на Go. Все их проблемы бы сразу улетучились. Проблема в том, что техническая проблема — это не проблема. А вот найти человека — да. А под нодочку людей тупо больше.
Iliya Isd
Это мне скорее медвежья услуга, мне спецов искать, раз уж на то пошло.
Но я как-то не переживаю по этому поводу, зато хороший продукт.
Ну это не самая аутсайдерская технология, не забывайте. Пусть не такая мейнстримовая как нодочка и прочее — это да, но языку уже 10 с лишним лет и он активно развивается. По крайней мере, я не испытал трудностей с подбором либ и поиском ответов на вопросы.
Dmytro Lapshyn
Вопрос без капли троллинга — чем именно Го лучше для сервисов? Могу ошибаться, но из тех примеров и описаний, что я видел, складывается однозначное впечатление, что Go — это довольно низкоуровневый язык. Ну, не как ассемблер или даже C, конечно, но явно выглядит (без обид!) как язык предыдущего поколения по сравнению с C#, Java, и даже современным ES6.
А низкоуровневость и скорость работы скомпилированного кода хороши для системного ПО и всякого middleware, а вот для прикладного ПО я бы на первое место однозначно ставил скорость разработки и доступность специалистов для последующей поддержки — а это, увы, ИМХО не те вещи, которыми Го может похвастаться.
доступность специалистов для последующей поддержки
Мова побудована, щоб бути максимально простою для вивчення та розуміння коду.
Навіть якщо гофера під рукою нема, можна перевчить кого завгодно.
скорость разработки
За власними спостереженнями та інфорю з інтернетів, «десь як пітон».
Ну явно швидше ніж джава з її
KokokoBuilder kokokoBuilder = new KokokoBuilder(); kokokoBuilder.pokpok(new Kudkudah()); Kokoko kokoko = kokokoBuilder.kukareku();
Дмитро
а еще на го очень удобно делать сортировку, фильтрации и агрегации для коллекций разных типов — ведь в go есть циклы и поддерживается приведение типов, не то, что в Java с ее лямбдами стримами и генериками.
на го очень удобно делать сортировку, фильтрации и агрегации для коллекций разных типов — ведь в go есть циклы и поддерживается приведение типов, не то, что в Java с ее лямбдами стримами и генериками
Простите, вы это серьёзно сейчас? Нет, опять же... возможно (!!), в Java лямбы и стримы как-то сильно криво реализованы, но в .NET, а особенно на функциональном F#, вот именно что работать с коллекциями — одно удовольствие. Да и в C# с LINQ тоже очень удобно это делать. После такого возвращаться к императивным циклам с явным пробеганием коллекции уж точно не хочется.
Konstantin Strukov
Мова побудована, щоб бути максимально простою для вивчення та розуміння коду.
Навіть якщо гофера під рукою нема, можна перевчить кого завгодно.
Але це зовсім не гарантує черги бажаючих перевчитися ;)
Ну явно швидше ніж джава з її KokokoBuilder
Дякую, приклад підняв настрій )) Я, нажаль, зовсім не спеціаліст у Java, але чув, що там подібні речі давно вже генеруються автоматично штуками накшталт Spring Boot: жах, коли подібне потрібно писати власноруч, можливий хіба що у якихось дуже legacy проектах. Але можу помилятися.
В мене склалось враження, що багатослівність — це така ж фішка джави, як err != nil в го.
Але це зовсім не гарантує черги бажаючих перевчитися ;)
Якщо це не гарантує, то менеджер чи ейчар гарантує :-)
Ну явно швидше ніж джава з її KokokoBuilder
Та блин, это не особенность джавы как языка, а особенность Архитекторов, котрые дизайнят оод. Ничего вообще не мешает зафигачить 100500 строк спагетти все в одном методе.
minodvesP Vasya
KokokoBuilder kokokoBuilder = new KokokoBuilder();
kokokoBuilder.pokpok(new Kudkudah());
Kokoko kokoko = kokokoBuilder.kukareku();
это сделало мой день)))
Покажите эквивалент на гоу, мы поржем.
чем именно Го лучше для сервисов?
Основная фишка Go — это go. В нём очень удобно распараллеливать выполнение задач. Зачастую даже тот код, что на других языках как правило выглядит как обычная однотредная функция, в Go можно распараллелить, и это касается не только асинхронных операций ввода/вывода.
Например. Приходит какой-то запрос с клиента, и по его url вызывается хэндлер, сразу после этого вызова продолжается приём других запросов. Далее, при вызове хэндлера код быстро определяет, что нужно ответить, и возвращает результат, но при этом после ответа в параллельных горотинах будет продолжаться выполняться какой-то функционал: апдейты в базу данных, какие-то обновления в структуре данных программы, и прочее что можно отложить. То есть здесь гораздо проще писать более производительный код.
Скорость выполнения кода на Go примерно в
В отличии от C, ООП там есть, только со своим оригинальным подходом. Принципы наследования, инкапсуляции, полиморфизма — выполняются, ну а кто говорил что релиз должен быть именно в виде классов? Как раз в Go представлен наикратчайший путь реализации концепций ООП. Go в целом лучше всех остальных языков следует принципу бритвы Оккамы: не плодить лишние сущности без явной необходимости.
Например. Приходит какой-то запрос с клиента, и по его url вызывается хэндлер, сразу после этого вызова продолжается приём других запросов. Далее, при вызове хэндлера код быстро определяет, что нужно ответить, и возвращает результат, но при этом после ответа в параллельных горотинах будет продолжаться выполняться какой-то функционал: апдейты в базу данных, какие-то обновления в структуре данных программы, и прочее что можно отложить. То есть здесь гораздо проще писать более производительный код.
Благодаря Го мы наконец поняли, что вещи, которые мы рутинно делали на Java/C# в далеком 2000 году — на самом деле нереально сложные проблемы, для решения которых нужно создание нового недоязыка.
на Java/C# в далеком 2000 году
Можно ещё рутино делать на C++, хоть под стандарт 2003, хоть
Ну-у, работа с I/O completion ports на c# в начале 2000х была чем угодно, только не рутиной, ибо требовала временами магии P/Invoke 80го уровня :)
Например. Приходит какой-то запрос с клиента, и по его url вызывается хэндлер, сразу после этого вызова продолжается приём других запросов.
Что-то мне это напоминает. А, точно, node же!
В отличии от C, ООП там есть, только со своим оригинальным подходом.
Прям как в жс. Может мне даже понравится этот го.
А, точно, node же!
Там подходы значительно отличаются, любая абсолютно функция может быть выполнена как в треде вызывающей, так и в своей горотине.
ООП там не как в js, свой оригинальный.
любая абсолютно функция может быть выполнена как в треде вызывающей, так и в своей горотине
Шо то Х, шо то Х.
ООП там не как в js, свой оригинальный.
Я надеюсь, с шлюхами и блек джекомдинамической типизацией и сообщениями?
Типизация естественно статическая строгая, в отличии от js. Но даже в мире js уже все пришли к выводу, что от этого нужно отходить. Поэтому Microsoft выпустила typescript, а Google — Dart. Эти решения с разной степенью радикальности, но в целом тенденция очевидна.
Эти решения с разной степенью радикальности, но в целом тенденция очевидна.
Но полиморфизм-то в го есть? ООП ведь.
Из-за этого, кстати, C в быстродействии и проигрывает — т.к. у C полиморфизма/виртуальных вызовов нет.
Но полиморфизм-то в го есть?
Все функции могут быть как виртуальные, то есть если по указателю на родительский тип записан дочерний, то функции вызываются дочернего типа.
ОМГ. Big Corp X придумала свой супер-костыль для выдуманной проблемы — и всё, это сразу называется тенденцией в js-мире.
Проблема как раз не выдуманная. На сегодняшний день объёмы кода, выполняемые на стороне браузера достаточно большие, чтобы принимать какие-то шаги для кардинального увеличения производительности. Например, есть WebGL, суть которого в том, что вызовы OpenGL — заскриптованы, и можно было бы писать полноценные 3D-action игры, еслиб не интерпретируемый js. В новых стандартах js уже добавили strict mode, let vs var, и много чего нового на пути к компилируемому js, JIT-компиляции, и возможностям реализации современных методов разработки кода, какие есть в VS под дот нет. Google несколько лет назад выпустил Dart, но это было как раз то самое радикальное решение, значительно опережающее своё время, и рынок это не оценил. А js тем не менее движется в том же направлении, только путём эволюционных изменений в стандартах.
И каким образом typescript, который транслируется в js, увеличивает производительность? Это интересное заявление. Как и отношение стандартов к производительности. Производительность обеспечивает движок, а не стандарт сам по себе.
В том то и дело, что бремя поддержки существующих решений — это как чемодан без ручки, который выбросить жалко, поскольку в это вложены немалые деньги всего рынка, и нести этот чемодан тяжело, поскольку не позволяет реализовать назревшие изменения. Typescript — это тоже полумера, а не средство позволяющее вывести разработку на кардинально новый уровень. Статическая типизация облегчит анализ кода на предмет ошибок во время компиляции, и несёт в себе разные преимущества для создания компилятора. То есть, с переходом всех на typescript, в дальнейшем можно было бы реализовывать виртуальную машину и JIT-компилятор. В Dart это сделано уже и сразу, но Microsoft естественно отказалась от поддержки решения от гугла, Apple также отклонила поддержку в своём браузере. Значит, ждём, пока стандарты ES дозреют.
Valentin Nechayev
Само по себе использование конструкций, которые легко детектируются и оптимизируются конкретным движком. Не знаю, насколько качественно это сделано именно в TS (я бы тут скорее ожидал видеть хинты в виде комментариев), но в общем случае помочь тут движку более чем реально.
Google несколько лет назад выпустил Dart, но это было как раз то самое радикальное решение, значительно опережающее своё время, и рынок это не оценил.
Ога, на момент выпуска дарта ts уже бы в бете, но рынок не оценил потому что в ie и safari не добавили vm. Поэтому Гугл решил что будет двигать angular 2 на ts. Лол на лоле просто познавать историю и возможности веб девелопмента от вас.
Не имеет принципиального значения, что появилось раньше, ts или dart, разница всё равно в 1 год, это одинаковый отклик на существующие проблемы во фронт-энде. Под рынком здесь имеются в виду ведущие компании, определяющие правила игры, и достаточно было бы тройке лидеров договориться, возможности фронд-энда были бы сейчас кардинально более высокого уровня. Mozilla и Opera всё равно приняли бы стандарты по факту.
возможности фронд-энда были бы сейчас кардинально более высокого уровня
О каких возможностях речь, что ты сейчас не можешь сделать во фронтенде?
Потрахаться с приведением типов потому что на user input компилятор ругается
Я уже писал об этом несколько раз, логичнее было бы сделать исполнение js в VM, и также JIT-компиляцию, что значительно повысит производительность исполняемого на фронте кода, и будет того же порядка как у всех компилируемых языков. В результате в браузер можно будет перенести все те приложения, что сейчас выполняется под нэйтивное API операционной системы. Это позволит усовершенствовать бизнес-модель этих приложений, и в результате существенно повысить доходность отрасли и всех разработчиков в целом.
джаваскриптера сопротивляются ,потому что они не хотят потерять элитность джс ,как единственной платформы в браузере. А то понабегут всякие рубисты и джависты..
А то понабегут всякие рубисты и джависты..
Будут задействованы не только рубисты и джависты, но и все остальные. И вообще граница между вебом и нэйтивными приложениями будет полностью стёрта. Для этого нужна виртуальная машина, и стандарт на байткод, вместо стандарта на js.
И вообще граница между вебом и нэйтивными приложениями будет полностью стёрта.
что бы стереть грань между фронт енд вебом в браузере и десктопом,мобайлом. надо сначала понимать из чего она состоит. у тебя этого понимания явно нет.
что бы стереть грань между фронт енд вебом в браузере и десктопом,мобайлом. надо сначала понимать из чего она состоит
Я занимался разработкой 3D-игр ещё с 2006 года, так что понимание у меня куда лучше чем у большинства присутствующих. Между мобайлом и десктопом разница была только в производительности железа, и на сегодняшний день она уже стёрта. Например, с выходом Windows8, и в
Я занимался разработкой 3D-игр
эмм, а при чём здесь фронтенд?
Кто хочет решать фронтенд-задачи — тот их решает уже сейчас. Кто не хочет — тем сейчас js не такой, потом css будет не такой, потом DOM, а потом и ещё что-то помешает.
Идеи насчёт DOM и CSS очень хороши, лучше любой интерфейс десктопных приложений на нём строить, вместо создания контролов в окне. В общем-то раньше даже существовал такой проект htmlayout, суть была в том, что эта либа линковалась к проекту на C++, и дальше рендерит в окне нужный html с css. Причём рендерить html можно не только с выводом в окно, но и в directx-текстуру. Это означает, что в любой 3D-игре можно например на меш с экраном компьютера натянуть эту текстуру, и лазать там в браузере, прямо в сцене игры, это очень круто. Только fps это дело выдавало небольшой. Ну и кроме того, очень многие десктопные приложения юзают какой-нибудь рендер html для своего интерфейса. Так что потребности рынка в этом есть, и на задачи фронт-энда надо смотреть шире.
В общем-то раньше даже существовал такой проект htmlayout, суть была в том, что эта либа линковалась к проекту на C++, и дальше рендерит в окне нужный html с css.
Сейчас этот тоже есть, но почему-то все «тру-программисты» плюются. Называется node-webkit/electron. Да, есть конечно недостаток — даже простая программа имеет размер в пару сотен метров и памяти жрёт прилично, но с точки зрения клепания UI удобно.
точки зрения клепания UI удобно.
При этом все абсолютно игнорируют QML (Qt) — наилучший из виденных мною вариантов
Не щупал, ничего не скажу
Называется node-webkit/electron
Я тут посмотрел, как развивается htmlayout, похоже сделали много нового, включая порт под linux и macos, и теперь проект называется sciter. На сайте даже висит видюшка, как его можно под directx юзать sciter.com/sciter-and-directx по-моему это круто. Ну и есть бинд для Go github.com/sciter-sdk/go-sciter
Сама по себе либа — небольшая.
В результате в браузер можно будет перенести все те приложения, что сейчас выполняется под нэйтивное API операционной системы.
В браузере эти приложения и АПИ никогда не перенесут не из-за отсуствия чьего-то желания запилить виртуальную машину, а по соображениям безопасности в первую очередь.
Это позволит усовершенствовать бизнес-модель этих приложений,
Так будут примеры таких приложений или бизнесс-моделей, которые в текущий момент развития веб фронт енда нельзя запилить?
а по соображениям безопасности в первую очередь
Определяющие соображения — это получаемая прибыль, а не безопасность продукта. Безопасность кода — это производная от бизнес-ожиданий. Ну и VM позволит делать абсолютно всё то же самое, что делается в нэйтивных приложениях. Хоть шифрование и обфускацию байткода, с электронной подписью. Например, во времена существования флеша, что только не делали в этих swf.
еще раз — позволять делать все в браузере не будут по соображения пользовательской безопасности, попытки встроить в браузер какую-то хню с виртуальной машиной типа java-апллетов, silverlight и т.д. уже повторялись неоднократно и очень давно, впоследствии это все было не так давно задепрекейчено всем производителями браузеров из-за проблем с пользовательской безопасностью таких решений(хотя по правде говоря JS и HTML5 api выжил с рынка эти технологии намного раньше).
попытки встроить в браузер какую-то хню с виртуальной машиной типа java-апллетов, silverlight и т.д. уже повторялись неоднократно и очень давно
В том то и дело, что это были встраиваемые решения, чтобы хоть как-то компенсировать недостатки существующих возможностей. Тут речь о том, что вся страница браузера целиком должна работать под VM, с доступом к DOM из VM. Естественно, нужно учесть опыт существующих решений, таких как flash, silverlight и т.п. Но не стоит раздувать преждевременные страхи насчёт безопасности, во времена начала электрофикации тоже пугали что мы все умрём от электричества.
Так будут примеры таких приложений или бизнесс-моделей, которые в текущий момент развития веб фронт енда нельзя запилить?
Да сколько угодно кстати. Например, игры: исполняемый код можно писать под WebGL, и портировать под любые социальные платформы, и куда угодно. С JIT-компилятором это будут не только простые казуалки, но и игры любой сложности, доступные сейчас на десктопе и консолях. Фотошоп можно сделать под веб. Офис — тоже можно сделать под веб, и не ту фигню, что реализована в Office365, а точно такую же как на десктопе. Даже 3D-рендеры можно сделать прямо браузере, во всяком случае интерфейс, а рендерить на серверах. И кстати, о серверах, описанные кейсы вовсе не означают, что приложения будут работать как «толстый» клиент.
С этими примерами есть одна проблема — они все весят от от нескольких до десятков гигабайт и их не очень удобно грузить как веб страничку. но в остальном да, запилить виртуальную машину и все будет зашибись, рынок осознает как тупил когда использовал десктоп.
они все весят от от нескольких до десятков гигабайт и их не очень удобно грузить как веб страничку
Всё относительно, я например видел пример 3D-игры, где код вместе со всеми текстурами весит всего 100 килобайт, но это конечно экстремальный случай. Флешки с качественной графикой, рассчитанной на FullHD, видюшками, весят порядка
Oleksii Khomchenko
Оно уже в VM и уже JIT.
Вы так говорите словно джавы, никогда небыло.
Аплеты, javafx вот это вот все — было, не взлетело.
Аплеты с java — примочка к html, тут речь о том, чтоб сам html управлялся под vm. В этом случае нет речи о том что взлетит/невзлетит, если в бразуере будет выполняться нэйтивный код от jit-компилятора, то взлетит однозначно и без вариантов.
Уже запилили asm.js — кому надо, уже юзают. Но на самом деле никому не надо, так как обычный javascript и так со всем справляется.
И что он делает, транслирует код с компилируемых языков в js? Действительно, нафиг это надо, лучше тогда напрямую на js писать. Mozilla просто Google попыталась протроллить, поскольку в отличии от них всё равно никуда за пределы браузера не вылазиет.
Давайте вы сами пойдете погуглите что это такое а потом вернетесь.
Так это.. злые языки говорят, что js- кривой язык..
Компилить любой язык в JS, или любой язык в asm.js, в гугле инструменты находятся за 5 минут.
Можно компилить любой тьюринг-полный язык в любой другой тьюринг-полный язык.
Скорость выполнения кода на Go примерно в2-5 раз меньше, чем того же самого кода написанного на чистом C.
Та, мы в курсе. :) Ламеры уже неоднократно доказали, что тормознутый динозавр С — проигрывает в быстродействии не только го, но и жабе.
С — проигрывает в быстродействии не только го, но и жабе
Как ни странно, но такой кейс запросто может быть. Опять-таки с распраллеливанием задачи в Go, что проблемно сделать на C с передачей контекста выполнения в другие треды.
Опять-таки с распраллеливанием задачи в Go, что проблемно сделать на C с передачей контекста выполнения в другие треды.
Какие страсти творятся, в современном мире высоких хипстерских технологий.
Пиши еще. Твой предшественник тут уже сливался, когда офигенно распараллеленый код на Go садился с лужу, когда рядом с ним ставили обычный однопоточный код, написанный на C#.
Можно с тем же успехом сравнить многопоточный код на Go, с однопоточным на том же Go, и увидеть что многопоточный сливает по производительности. Здесь прежде всего нужно смотреть на синхронизацию. Кроме того, естественно зависит от железа, выше количества ядер не прыгнешь.
Продолжайте в том же духе и через пару месяцев прозреете и сами начнете спрашивать тут «зачем такой язык?»
Проблемы языка как раз беспокоят меньше всего, при разработке на C++ всё равно 95% всего кода — это элементарные конструкции выражений, условий и циклов. Только к этому коду ещё немалый оверхед идёт, достаточно посмотреть там только на работу со смартпоинтрами. Или тема дженериков. В Go есть просто интерфейсы и утиная типизация, и компилер выдаёт лаконичные и предельно ясные сообщения об ошибках. Если в C++ будет какая-то ошибка в шаблоне, сообщение об этой ошибке выглядит как какое-то издевательство, там ещё на несколько строк надо искать полезную инфу на предмет того, что вообще произошло, причём разбираться в бреде что выдаёт компилер — бесполезно, лучше просто искать в тексте по имени своего файла и номера строки. Впрочем, все конструктивные недочёты C++ уже всем давно известны, и это как раз одна из причин использования более беспроблемного языка.
утиная типизация, и компилер выдаёт лаконичные и предельно ясные сообщения об ошибках
Посмеялся. Стектрейс на несколько экранов в рантайме из-за неправильно определенного типа --- это безусловно прогресс над устаревшей статической типизацией, ага.
И при этом человек гонит на плюсовые шаблоны, ага.
просто искать в тексте по имени своего файла и номера строки
Очевидно, что если ошибка, то всегда именно в тексте быдлокодера. Или в гоу ошибки бывают не только в быдлокоде, но и в стандартных библиотеках что ли?
Как говорится, не ошибается тот, кто ничего не делает. И это как раз преимущество, что в случае косяка допустим в коде хэндлера сервера, вылезает стектрейс в лог, и сервер продолжает работать дальше, а не падает вообще полностью с сообщением об ошибке защищённого режима. Потому что в случае такой ошибки в коде на другом компилируемом языке, ещё повезёт если это дебаговая сборка, иначе вам придётся по предшествующим действиям, дизассемблеру и состоянию регистров гадать, что в коде надо править.
И это как раз преимущество
Омг. Т.е.у софтины внутри уже нарушены инварианты, но она продолжает работать как ни в чем не бывало? Надежно, стабильно и абсолютно безопасно, ага.
Будет софтина работать, или как — это выбор программиста. Одно дело, когда такой выбор есть, и совсем другое, когда выбора вообще нет. При ловле исключения в recover разработчик может решать что и как делать с ошибкой, может пофиксить, может игнорировать, может завершить работу.
может пофиксить
Нет, не может. Это концептуальный вопрос — у программиста нет возможности заранее знать, какие будут ошибки; иначе бы он их бы сразу в основном коде пофиксил бы.
может игнорировать
Это идентично «пофиксить путем пропуска»
может завершить работу
Это единственно правильный результат — это сохранить лог ошибки и закрашиться.
Это единственно правильный результат — это сохранить лог ошибки и закрашиться
Не всегда, хэндлеры на сервере могут работать с независимыми друг от друга состояниями, если возникнет ошибка в одном, это не отразится на другие. В этом случае нет необходимости крашить всё полностью.
Где и какие будут ошибки — можно догадаться, логично что ошибки скорее всего возникнут в недавно написанном и неоттестированном участке кода, вот как раз для него и можно предусмотреть разные варианты вылета.
если возникнет ошибка в одном, это не отразится на другие.
Если они работают в одном адресном пространстве, то этого гарантировать нельзя.
ошибки скорее всего возникнут в недавно написанном и неоттестированном участке кода
Эээ, х**к-х**к и в продакшен? Код же тестируют, до выкатки на продакшен.
Код же тестируют, до выкатки на продакшен
Если есть возможность программно отлавливать ошибки, без полного падения софта, это существенно облегчит тестирование и поддержку. Не понимаю, о чём тут вообще можно спорить, не нравится обработка ошибок — можете просто валить свой софт на любое исключение, и симулировать тем самым ошибки защищённого режима.
сервер продолжает работать дальше, а не падает вообще полностью с сообщением об ошибке защищённого режима
On Error Resume Next
заебись тема, чо
Ну это ж не скала. Найти любого толкового прогера на любом другом мейнстрим языке; переучить на го — дело трех дней.
ну эт да. Ну написать в вакансии\спам рассылке, что возможно переобучение из других яп, делов то.
Как, вообще, проходят трансформации?
Делается общая анестезия, заходит хирург, вскрывает череп, удаляет часть неокортекса, складывает череп обратно. Пациента пробуждают, если IQ получился меньше 90, то программист на Го готов, иначе повторить начиная с пункта 1.
Пишите на бейсике тогда
Ути пути какие мы оптимисты. (я про сложности языка). Я так тоже думал когда на матлабе прогал. Тоже думал что все просто, пока не понял что то что я напрогал можно ужать раз так 20, и производительность раз так в 100 возрастет.
Нестор Иванович
не получиться, насрать на освободившееся место забыли
Просто читаешь книжку Go Programming Language. Потом пишешь на Go. У меня в команде все пишут на Go фуллтайм и все пришли с разных языков (кто с Java, кто с Scala, кто с PHP...) и только один парень пару лет писал на Go до этого. И ничего, гребем.
Главное тут кнут — ну стимул какой-то, который будет говорить что ты нагенерил говнокод. Причем независимый. Типа reference design.
Типа reference design.
Такой есть — effective go и offical code review guide.
Не знаю. Я просто очень часто обнаруживал что кроме методов которые предлагает С/С++ есть еще и другие, гораздо более эффективнее.
Так, потрібні. А також потрібні знання, як можна швидко та безболісно перевчити людину, що хоче поповнити ряди Go розробників.
і перевчаєте
А что значит «переучиваете» ? Типа на это нужно какие-то ресурсы тратить. Туториал в зубы — и сам переучиться!
и ?
на все это есть статьи, видео-туториалы на ютубе, етц.
Vasilij Tjorkin
Не-не, вы шо?! Все хочут прям вот щас готовеньких спецов, желательно сеньоров. Назовите хоть одну контору, которая даст время на раскачку человеку без опыта в Go. Я не знаю ни одной.
що за дивні питання. Судячи з вашого оголошення вам треб людей с бекграундом в нетворкінгу та SND, от таких в прешу чергу і шукайте.
Якщо б робили якийсь веб-девелопмент мало б сенс дивитись на людей з веб експіріенсом.
может с ПХП и переходят в Го, но с крестов переходить в Го профита нет никакого
Gennady Dogaev
C PHP на GO? А зачем переходить с развитой технологии с большой экосистемой и комьюнити на новую, где ничего нет или меньше?
На Go пишете или на PHP? Имхо, это язык для задротства, а не для работы github.com/golang/go/issues/4594
Разве что если комьюнити достаточно большое и успело понаписать библиотек для таких задач. Кстати, там хоть менеджер зависимостей/пакетов есть какой-нибудь?
Я вот тут недавно написал в очередной раз «свои первые пару строчек на JS для продакшена» и мне стало интересно, вот этот язык он для чего? для задротства или для работы?
Для работы, потому что:
1. Ничего другого собственно и нет, если ты о браузерном жс, а не о node. Тайпскрипты всякие всё равно транслируют в жс
2. Есть очень много готового. Фреймворки, библиотеки, кастомные UI-компоненты
Если появится какой-нибудь го для браузера — он будет языком для задротства пока не появится поддержка во всех браузерах (в IE11, бугага) и не выполнится п. 2.
Его нативно понимают браузеры?
Это был таки TS и таки Нода, но мысль понятна.
Ну с нодой не всё так однозначно. Я лично не вижу весомых причин для перехода на ноду с пхп. Хотя мне в-принципе нравится что одно, что другое.
1. Ничего другого собственно и нет, если ты о браузерном жс, а не о node.
там хоть менеджер зависимостей/пакетов есть какой-нибудь?
Вот глядя на js, это один из первых вопросов, который возникает: там менеджер зависимостей/пакетов есть какой-нибудь? Помимо вопроса «какой наркоман это всё придумал». Ещё я первое время был полностью уверен, что загружаемый в браузер js там компилится в байт-код, и исполняется виртуальной машиной, только об этом почему-то все авторы мануалов как-то скромно умалчивают. А вот фиг, оказывается интерпретируется. А оптимизация js на сегодняшний день состоит в таком чуде инженерной мысли, как перевод в «плоскую модель» и «минификация». Это при том, что на дворе 2017 год, уже завершается.
Альтернатива этому конечно тоже есть — Dart, нормально спроектированный язык, тоже от Google, только в связи с грузом бремени js отказались от встраивания виртуальной машины в брауезер, да и не договорились ни с кем.
Расскажите нам как гоу решил проблему зависимостей в браузерном js?
В дарте — решена, так же как во многих языках, в том числе и Go, перечнем импорта в начале файла. Казалось бы ничего сложного, в js этого нет.
в js этого нет.
вообще-то уже есть developer.mozilla.org/...ference/Statements/import
Я бы про пакетный менеджер go вообще молчал, о проблемам с управлением зависимостей на go и «путях их решений» наслышаны все.
А оптимизация js на сегодняшний день состоит в таком чуде инженерной мысли, как перевод в «плоскую модель» и «минификация».
Это оптимизация не js, а работы с сетью в рамках http протокола и браузерных возможностей.
В js есть npm и boweryarn. Конечно для их использования на фронте желательно использовать утилиты для сборки, gulp например.
Так это называется костыли к js, а не возможности языка. Вообще мне понравился костыль closure-compiler, он ещё транслирует новую версию js в более старую, для поддержки старых браузеров. По идее, было бы лучше создать какой-то стандарт на байт-код, для исполнения в VM в браузере. Это дало бы возможность писать код на любом более удобном языке, также существенно возросла бы производительность, появились бы возможности оптимизации, ну и конечно, JIT-компиляции. Это не праздный вопрос, поскольку объёмы кода на фронт-энде уже достаточно большие.
Фигню городишь. Если речь о node — то npm является возможностью языка, так как ставится вместе с нодой. Если речь о браузерах, то ты бы вспомнил когда был придуман js и сколько существует браузеров и браузерописателей. И как ты видишь импорты в браузере без костылей? Типа, видя import интерпретатор скачивает файлик по сети? Лучше уж костыли, чем так.
Ноду не рассматриваю, нет смысла, когда есть компилируемый Go, и java с виртуальной машиной. Ну а js был придуман на год позже Lua, архитектура которого намного лучше продумана, есть возможность встраивания куда угодно, и легко мог бы быть использован для управления DOM в браузерах. Авторы могли бы не изобретать велосипед, а просто позаимствовать нормальное решение. Тем более, что Lua абсолютно ничем не сложнее js. Насчёт организации импорта — лучше всего сначала всё полностью скачать, потом запустить, так например обычно делается во всех флешевых играх. Хотя динамическая подгрузка тоже возможна.
Плюсую насчет Lua. Жаль, что его не поддерживают браузеры. :(
Vitaliy Fedoriv
Ну от що це
github.com/npm/npm/issues/19019
за х..я ??? Яка тривала місяць.
Я сьогодні node проапдейтив і трохи офігів (як таке взагалі можна було релізити) ?
Причому в мене таке враження, що девелопери node і npm між собою змагаються, хто більший косяк зробить.
Ну от що це
github.com/npm/npm/issues/19019
за х..я ??? Яка тривала місяць.
А вот это там для кого на офсайте ноды написано мелким шрифтом? c2n.me/3PXaNMO Хотите юзать bleeding edge — не обижайтесь что оно bleeding. Тем более, из обсуждения становится ясно что npm, поставляемый с node 9 работал.
от цим екосистема js і відрізняється: реліз==альфа, форк на форку і «воно ж через ж... але працює»
Ещё раз: ставишь node нужной версии — и оно работает из коробки. Обновляешь npm до последней — кто тебе доктор? Я с начала 2016 года и до понедельника работал с Ember.js версии 1.13. Потому что обновить до 2.16 было некогда — нужно было пилить фичи. И ничего, не умер. Вплоть до того что нужные мне аддоны для свежих версий я форкал и делал совместимыми с 1.13. Так между старой и новой версией фреймворка есть разница, например новая версия быстрее, имеет новые фичи. А вот обновлять npm с одной минорной версии на другую — это необязательно и не принесет ничего нового.
Это не js, а open source так работает. И я не верю что он работает по другому в го или ещё где-то.
Имхо, это язык для задротства, а не для работы
Docker, kubernetes, ethereum, minio, cockroachdb, influxdb, prometheus — це не робота, ага.
github.com/golang/go/issues/4594
І що ти хочеш цим сказати?
Разве что если комьюнити достаточно большое и успело понаписать библиотек для таких задач
Чувак, тут стдліба за своїм функціоналом дрюкає стдліби конкурентів, що вже казати про сторонні ліби.
golang.org/pkg
godoc.org/-/subrepo
Кстати, там хоть менеджер зависимостей/пакетов есть какой-нибудь?
Так. Їх кілька. Навіть офіційний є. github.com/golang/dep
Docker, kubernetes, ethereum, minio, cockroachdb, influxdb, prometheus — це не робота, ага.
ТС спрашивала про переход с php в go. Вот чет мне ну никак не кажется что писал чувак на пхп для веба и вдруг пошел докер писать на го. А писать на го бэкенд сайта — зачем? Причем я так понимаю что это желание фирмы такое, добровольно-принудительно переучить кого-то на го (спрашивает HR, не девелопер).
Я вот не знаю, я в свое врея работал с питонистами так вот они были совсем не против ни на го ни на что-то ещё трендовое прейти. Почему бы и нет? Почему не разнообразить свой опыт то?
Если перейти на го и продолжить писать веб — это разнообразить опыт менее удобным инструментом. Если перейти на го и писать всякий докер — это существенная смена специализации. В первое время получится разве что наговнокодить.
А писать на го бэкенд сайта — зачем
Швидше на порядок, пам’яті жере менше на порядок, плюшки строгої типізації.
Але да, залежить від того який у них проект і які вимоги до нього.
Може виявитись що го оверкіл, і еліксир буде доречніше.
Швидше на порядок, пам’яті жере менше на порядок, плюшки строгої типізації.
А насколько медленнее писать? Если тоже на порядок — мало кому это подойдет.
А насколько медленнее писать?
На Go вообще не нужно заморачиваться насчёт языковых конструкций, поэтому нет никаких соответствующих издержек времени. Просто пишешь что надо, и работает.
Разрабочики Go прислушались к вашей конструктивной критике и добавили Round в go1.10. Теперь собираются добавить менеджер зависимостей в go 1.11. Так что пора переходить на Go
Потому Гугл пихает это говно
Vladimir Danylevsky
Как, вообще, проходят трансформации?
1.Находите интересную задачу
2.Решаете её на Go, походу знакомитесь с ресурсами о Go
3........
4.PROFIT!!!
Сашко Чехоцький
Тему можна закривати =)
Думаю, можна за один крок: людина? що вже пише на Go, повинна вкусити ту, що ще не пише.
Главное что бы таки укусить а не как в «настоящем айтишнике»
Найкращі коментарі пропустити