Ну есть 1с там и язык сам на русском. И названия по русски. Тут такое дело, что имена переменных вплетаются в язык. То есть хорошо читается или "привет, как дела" или "hello, how are you", но не "привет, how дела you"
Сейчас появилась задача сделать приложение с плагинами (чтобы в деплое различные конфигурации создавать и разную поставку делать) благо в нашем случае нам вроде пока хватает штатного plugins так как условия описанные автором выполняются - собирается всегда все за раз с одной версии и в одну платформу и просто уже в рантайме что-то или подгружается или нет, выгружать не требуется.
По поводу интеропа с C смотрели и Kotlin Native и Go и Rust - лучше всего как ни странно получается когда приложение на C, а в него увязывается например Kotlin Native или Rust и в нем используется Kotlin Native. Go с Kotlin не очень дружат - основная причина, что Kotlin формирует *.h где все сделано через (void*) (объекты воспроизводятся с методами) - ни при импорте в C ни при импорте в Rust проблемы нет, а вот Golang как оказалось его CGO это не поддерживает - приходится кроме штатного хидера еще пилить какие-то костыли с подменой имен и реекспортом. По обратному интеропу та же примерно история - 2 разных GC не шибко хотят дружить - то есть как-то все это импортится, но какой-то уверенности, что все что надо в нужный момент вычищается нет. При импорте из C или Rust такого вопроса не встает особо. В общем как раз Go/Kotlin interop не сказать что очень уж взлетает
У нас 2 языка на постоянке в стеке очень разные по "духу" Golang и Kotlin.
Скажу так - меня лично НЕ бесит `err != nil` , гораздо больше бесит когда в ревью я вижу как Java/Kotlin разработчики любят класть болт на обработку ошибок или наоборот использовать исключения для передачи управления. В итоге я на Kotlin начал писать ближе к Golang (используя Result<T> и обязательную реакцию на статус ошибки в вызывающем коде)(правда сам Golang тут непричем, я к такому стилю в Kotlin начал приходить до практичкского исполоьзования Golang или Rust. Поэтому как раз обработку ошибок в Go я как раз считаю очень и очень здравой.
Меня лично в Go по сравнению с Kotlin/Java/Rust/C++ раздражает какая-то нарочитая недоделанность генериков (и появились как-то не сразу, и появились какие-то недоделанные - нельзя делать Generic методы, только функции без ресивера). Вот они бы могли возглавить рейтинг недовольства.
А вот что прямо радует, без шуток - предельно быстрый, простой и полнофункциональный встроенный тулчейн - модульная система на базе GIT, внятный тестовый движок из коробки, cover, бенчмарки, профайлинг, линтер, документация - все из коробки без необходимости проведения вуду-ритуалов над Gradle как это обычно происходит в Jvm истории
И я ни в коей мере не соглашусь с Вашей исходной посылкой - производительности у Go не сильно больше чем у Java по крайней мере на gRPC (посмотрите официальные бенчмарки), низкоуровневости в нем тоже не сказать, что много. И я не слышал чтобы Go использовался для системных задач (для таких задач наличие рантайма с GC не очень характерно). Они с Kotlin одного поля ягоды. Разница существенная не в низком уровне или системности, а в поддержке нативной компиляции. В случае с Kotlin это Kotlin Native - но этот продукт не зрелый, поэтому используем Go.
Отвечая на ваш вопрос про портирование.
Переписывания того что уже есть с языка на язык задачи действительно не было (у нас в команде), хотя другая команда именно переписывала на Go, с PHP.
Но часть новых сервисов было решено делать на Go, а не на Java (по причине огромного футпринта в памяти JVM), хотя уже много было наработок на Kotlin (и хотелось их максимально использовать и дальше). И при этом требуется поддержание некоторого SDK на 2-х языках (для других команд) - там всякие внешние коннекторы и спеки и всякие кастомные маршаллизаторы - это на 2-х языках ведется. Соответственно была задача максимально быстро перенести часть шаблонных наработок чтобы они были и в GO и во-вторых есть код который реально сразу в 2 языка сопровождается.
А вот то, что вы описчываете "быстро", "низкоуровнево" и системно - это скорее про Rust если из современных платформ смотреть и с C/C++ не связываться. Вот они как раз на другой поляне играют несколько. Rust тоже есть в стеке (но это скорее просто чтобы какие-то квалификации такого рода в коллективе были и не ржавели), переводить всех на Rust - это действительно тяжело и в итоге себя не оправдывает. Но где он уместен - тоже применяем. Вот там я не скажу что получается один в один переносить, не получается - другого планирования требует язык.
Ну я думаю у них на это был серьезный мотив именно связанный с тем, что генерики у них пока не очень. Без наличия стандартного механизма обобщения не стоит замахиваться на "стандартный LINQ для Go" и в целом взять готовый с инета или сделать свой для своих нужд не сложно. К тому же в случае го это тем более бессмысленно так как нет обобщенного понятия Iterable или аналога. Плюс это не будет полноценным если сразу не решить с унификацией []int и <-chan int
Да, Go это про конвенции которые надо выработать в своих проектах.
Мы в итоге пришли к следующей формуле - если важно, чтобы твою структуру делали только через конструктор - делай ее приватной
type _MyType struct {} // в терминах Kotlin - это internal
func NewMyType() *_MyType {...} // а это public
Если так делать - то варианта прямого создания абы как _MyType не остается.
Вторая конвенция это конечно отношение к "пакету" в Go примерно как к "классу" в Java/Kotlin, а не как к пакету в Java/Kotlin. При таком понимании - пакет это синглтон со статическими методами (функциями), с inner class (структуры и их методы). То есть пакет в Go это не "коллекция связанного кода", как в Java, а "компонент под ключ", что ближе к "большому классу". В принципе большинство пакетов в Go у самих Google примерно так и выдержаны. Это понимание тоже позволяет лучше спланировать API и определиться с видимостью тех или иных структур и функций
Свои 5 копеек как автор вставлю. Kotlin богаче как язык. Но как и из статьи видно - голанг также вполне комфортный. Если говорить про сам язык, то менять Котлин на го смысла нет. Но дефект котлина не в нём самом, а в том что JVM, которая не радует когда много подов всяких сервисов. Я честно ждал джва года, что kotlin native будет выпущен в релиз... Но к сожалению он не известно когда будет доведён до ума и если нужен Натив, то выбор очень быстро падает на go. C/C++ вообще даже не рассматривали. На расте я пописываю, но в командный общий стек не стал вносить, тяжеловат в освоении.
Автор все правильно написал и у нас бы он или аналогично ведущий бы себя человек бы прошел. В комментариях в очередной раз вижу непонимание сути. Опять вопросы из серии "а вот ты наведешь пыль в глаза, а потом как работать" или "как докажешь, что твой алгоритм лучший". Это от непонимания того как работает и на что смотрит вторая сторона - собеседующий. Вот я много собеседую - все советы автора - абсолютно верные и то чему он внимание уделяет.
И главное - советы эти помогут только тому, кто хорошо программирует и все знает, но теряется и ерунду творит на собеседованиях, есть такие. Те же кто просто попытается сымитировать почитав эту статью - ну это очень быстро на читстую воду выводится.
Автор судя по всему - хорошо понимает о чем пишет и у нас бы например почти наверняка бы прошел эту часть собсеседования. Уверяю Вас - действительно воспользоваться советами автора сможет только человек, который понимает. Пустить пыль в глаза не получится - когда видно, что человек просто начитался хабра и пытается что-то из себя выдавить - это очень быстро и иногда очень забавно выводится на чистую воду
Очень странная статья никак не льющаяся с тем что в реальности из себя представляет техническое собеседование. Уже вторая статья за неделю от обиженных на собеседующих. Потому и сложно они Вам даются и такие странные для вас вопросы что вы и не до конца понимаете на что именно тимлиды и т.п. смотрят. Я про серьёзные компании куда именно профессиональных прогеров нанимают
Согласен с теми кто считает что проблема именно в том что автор с лёгкостью пишет какойто сжатый обфусцированный код. Ему и дали неряшливый начальный какой-то пример и блокнот чтобы он показал просто спокойные навыки организации кода. А не чудеса c++ выражений в одну строчку. А если бы ещё и сходу алгоритм распевали то совсем хорошо. Мы не Яндекс но когда разрабов смотрим тоже больше смотрим на знание методики а не хардкора. И раз человек метит в такие компании как Яндекс, лучше урок из своего провала извлечь, а не жаловаться на собеседующего.
Ну есть 1с там и язык сам на русском. И названия по русски. Тут такое дело, что имена переменных вплетаются в язык. То есть хорошо читается или "привет, как дела" или "hello, how are you", но не "привет, how дела you"
Сейчас появилась задача сделать приложение с плагинами (чтобы в деплое различные конфигурации создавать и разную поставку делать) благо в нашем случае нам вроде пока хватает штатного
pluginsтак как условия описанные автором выполняются - собирается всегда все за раз с одной версии и в одну платформу и просто уже в рантайме что-то или подгружается или нет, выгружать не требуется.По поводу интеропа с C смотрели и Kotlin Native и Go и Rust - лучше всего как ни странно получается когда приложение на C, а в него увязывается например Kotlin Native или Rust и в нем используется Kotlin Native. Go с Kotlin не очень дружат - основная причина, что Kotlin формирует *.h где все сделано через (void*) (объекты воспроизводятся с методами) - ни при импорте в C ни при импорте в Rust проблемы нет, а вот Golang как оказалось его CGO это не поддерживает - приходится кроме штатного хидера еще пилить какие-то костыли с подменой имен и реекспортом.
По обратному интеропу та же примерно история - 2 разных GC не шибко хотят дружить - то есть как-то все это импортится, но какой-то уверенности, что все что надо в нужный момент вычищается нет. При импорте из C или Rust такого вопроса не встает особо. В общем как раз Go/Kotlin interop не сказать что очень уж взлетает
У нас 2 языка на постоянке в стеке очень разные по "духу" Golang и Kotlin.
Скажу так - меня лично НЕ бесит `err != nil` , гораздо больше бесит когда в ревью я вижу как Java/Kotlin разработчики любят класть болт на обработку ошибок или наоборот использовать исключения для передачи управления. В итоге я на Kotlin начал писать ближе к Golang (используя Result<T> и обязательную реакцию на статус ошибки в вызывающем коде)(правда сам Golang тут непричем, я к такому стилю в Kotlin начал приходить до практичкского исполоьзования Golang или Rust.
Поэтому как раз обработку ошибок в Go я как раз считаю очень и очень здравой.
Меня лично в Go по сравнению с Kotlin/Java/Rust/C++ раздражает какая-то нарочитая недоделанность генериков (и появились как-то не сразу, и появились какие-то недоделанные - нельзя делать Generic методы, только функции без ресивера). Вот они бы могли возглавить рейтинг недовольства.
А вот что прямо радует, без шуток - предельно быстрый, простой и полнофункциональный встроенный тулчейн - модульная система на базе GIT, внятный тестовый движок из коробки, cover, бенчмарки, профайлинг, линтер, документация - все из коробки без необходимости проведения вуду-ритуалов над Gradle как это обычно происходит в Jvm истории
И я ни в коей мере не соглашусь с Вашей исходной посылкой - производительности у Go не сильно больше чем у Java по крайней мере на gRPC (посмотрите официальные бенчмарки), низкоуровневости в нем тоже не сказать, что много. И я не слышал чтобы Go использовался для системных задач (для таких задач наличие рантайма с GC не очень характерно). Они с Kotlin одного поля ягоды. Разница существенная не в низком уровне или системности, а в поддержке нативной компиляции. В случае с Kotlin это Kotlin Native - но этот продукт не зрелый, поэтому используем Go.
Отвечая на ваш вопрос про портирование.
Переписывания того что уже есть с языка на язык задачи действительно не было (у нас в команде), хотя другая команда именно переписывала на Go, с PHP.
Но часть новых сервисов было решено делать на Go, а не на Java (по причине огромного футпринта в памяти JVM), хотя уже много было наработок на Kotlin (и хотелось их максимально использовать и дальше). И при этом требуется поддержание некоторого SDK на 2-х языках (для других команд) - там всякие внешние коннекторы и спеки и всякие кастомные маршаллизаторы - это на 2-х языках ведется. Соответственно была задача максимально быстро перенести часть шаблонных наработок чтобы они были и в GO и во-вторых есть код который реально сразу в 2 языка сопровождается.
А вот то, что вы описчываете "быстро", "низкоуровнево" и системно - это скорее про Rust если из современных платформ смотреть и с C/C++ не связываться. Вот они как раз на другой поляне играют несколько. Rust тоже есть в стеке (но это скорее просто чтобы какие-то квалификации такого рода в коллективе были и не ржавели), переводить всех на Rust - это действительно тяжело и в итоге себя не оправдывает. Но где он уместен - тоже применяем. Вот там я не скажу что получается один в один переносить, не получается - другого планирования требует язык.
А
Ну я думаю у них на это был серьезный мотив именно связанный с тем, что генерики у них пока не очень. Без наличия стандартного механизма обобщения не стоит замахиваться на "стандартный LINQ для Go" и в целом взять готовый с инета или сделать свой для своих нужд не сложно. К тому же в случае го это тем более бессмысленно так как нет обобщенного понятия Iterable или аналога. Плюс это не будет полноценным если сразу не решить с унификацией
[]intи<-chan intА это точно не тривиал бы был
Да, Go это про конвенции которые надо выработать в своих проектах.
Мы в итоге пришли к следующей формуле - если важно, чтобы твою структуру делали только через конструктор - делай ее приватной
Если так делать - то варианта прямого создания абы как
_MyTypeне остается.Вторая конвенция это конечно отношение к "пакету" в Go примерно как к "классу" в Java/Kotlin, а не как к пакету в Java/Kotlin. При таком понимании - пакет это синглтон со статическими методами (функциями), с inner class (структуры и их методы). То есть пакет в Go это не "коллекция связанного кода", как в Java, а "компонент под ключ", что ближе к "большому классу". В принципе большинство пакетов в Go у самих Google примерно так и выдержаны. Это понимание тоже позволяет лучше спланировать API и определиться с видимостью тех или иных структур и функций
Свои 5 копеек как автор вставлю. Kotlin богаче как язык. Но как и из статьи видно - голанг также вполне комфортный. Если говорить про сам язык, то менять Котлин на го смысла нет. Но дефект котлина не в нём самом, а в том что JVM, которая не радует когда много подов всяких сервисов. Я честно ждал джва года, что kotlin native будет выпущен в релиз... Но к сожалению он не известно когда будет доведён до ума и если нужен Натив, то выбор очень быстро падает на go. C/C++ вообще даже не рассматривали. На расте я пописываю, но в командный общий стек не стал вносить, тяжеловат в освоении.
Автор все правильно написал и у нас бы он или аналогично ведущий бы себя человек бы прошел. В комментариях в очередной раз вижу непонимание сути. Опять вопросы из серии "а вот ты наведешь пыль в глаза, а потом как работать" или "как докажешь, что твой алгоритм лучший". Это от непонимания того как работает и на что смотрит вторая сторона - собеседующий. Вот я много собеседую - все советы автора - абсолютно верные и то чему он внимание уделяет.
И главное - советы эти помогут только тому, кто хорошо программирует и все знает, но теряется и ерунду творит на собеседованиях, есть такие. Те же кто просто попытается сымитировать почитав эту статью - ну это очень быстро на читстую воду выводится.
Автору зачет.
Автор судя по всему - хорошо понимает о чем пишет и у нас бы например почти наверняка бы прошел эту часть собсеседования. Уверяю Вас - действительно воспользоваться советами автора сможет только человек, который понимает. Пустить пыль в глаза не получится - когда видно, что человек просто начитался хабра и пытается что-то из себя выдавить - это очень быстро и иногда очень забавно выводится на чистую воду
Очень странная статья никак не льющаяся с тем что в реальности из себя представляет техническое собеседование. Уже вторая статья за неделю от обиженных на собеседующих. Потому и сложно они Вам даются и такие странные для вас вопросы что вы и не до конца понимаете на что именно тимлиды и т.п. смотрят. Я про серьёзные компании куда именно профессиональных прогеров нанимают
Согласен с теми кто считает что проблема именно в том что автор с лёгкостью пишет какойто сжатый обфусцированный код. Ему и дали неряшливый начальный какой-то пример и блокнот чтобы он показал просто спокойные навыки организации кода. А не чудеса c++ выражений в одну строчку. А если бы ещё и сходу алгоритм распевали то совсем хорошо. Мы не Яндекс но когда разрабов смотрим тоже больше смотрим на знание методики а не хардкора. И раз человек метит в такие компании как Яндекс, лучше урок из своего провала извлечь, а не жаловаться на собеседующего.