LINUX.ORG.RU

Go vs Kotlin

 , ,


1

4

Прошу помощи зрительного зала в оценке перспективности смены карьеры с Java Backend разработчика на Go или Kotlin Backend. Да, я знаю, что Kotlin - это больше Android, но вот прямо сейчас наклёвывается новая работа именно на Kotling и именно в Backend. Причём компания - вовсе не стартап переросток с тремя разрабами. Что бы вы выбрали?

  1. Отказались бы от Kotlin backend и продолжили искать Go backend
  2. Согласились бы на Kotlin backend
  3. Остались бы на теряющей популярность, но всё ещё жирной Java backend
  4. Попробовали бы что-то другое (в комментах укажите что)

И да, я считаю, что Java неуклонно движется в сторону COBOL номер два. Со временем популярность Java продолжит падать и дальше, вплоть до выхода из первой десятки популярных языков. По моим ощущениям на это понадобится не более десяти лет. При этом новых и интересных проектов на Java будет всё меньше и меньше, вплоть до полного исчезновения.

Недавно узнал, что Kotlin не привязан к JVM так сильно, как я до сих пор думал. Речь идёт о Kotlin Multiplatform.

В мире Go существует уникальная возможность перехода, которая закроется через 3 - 4 года. В подавляющем числе Go ориентированных компаний нет требования какого либо прошлого опыта разработки на Go и достаточно лишь опыта разработки на других ЯП, в числе которых обычно упоминают и Java. Если сейчас не запрыгнуть на этот поезд, можно опоздать и не запрыгнуть уже никогда. Уже сейчас начали появляться компании, где требуют хотя бы 2 - 3 года опыта на Go. Их пока мало, но будет больше. 2 - 3 года назад таких компаний не было вообще.



Последнее исправление: zg (всего исправлений: 1)
Ответ на: комментарий от zg

А если бы собирался, как бы он работал? Допустим, что T - это тоже String, но нет типа String.

Легко. Компилятор должен проверить, что тип принимает параметр. Читай про higher-kinded types.

hateyoufeel ★★★★★
()
Ответ на: комментарий от zg

Ну хорошо, а где сейчас Haskell реально используется?

Дохрена в том же вебе, на бэкенде (хотя фронт на хачкелле я тоже видел, но лучше бы не видел). Туда же всякие кастомные компиляторы, дохренища в финансовом софте, криптовалютчики на хачкель массово дрочат, потому что IOHK делают компиляторы для смартконтрактов на нём. И так далее, и так далее, и тому подобное.

Хотя тут на самом деле обратная зависимость: хачкель, окамль и прочие лишпы появляются там, где много поехавших аутистов, задрачивающих всякую заумную муть. Просто такая вот корреляция. Не на жабе же писать, в конце-то концов.

На сколько легко можно найти работу с этим языком

Есть довольно стройное сообщество, там часто публикуют вакансии. У меня в прошлый раз ушло пару недель, чтобы найти себе неплохое место.

как там обычно платят, по сравнению с Java Backend?

Я понятия не имею, сколько платят жабистам. Но сам я не жалуюсь. Зависит от предметной области и насколько горяч вокруг неё рынок сейчас, как и с любым другим убогоньким недоязычком.

Только это, Higher-Kinded Types – это не фишка хачкеля. Те же C++ или даже Scala их умеют вообще без проблем. Тут просто жаба убогая, потому что это жаба и она убогая. Я тут просто хаскеллем разбрасываюсь, потому что это один из основных недоязычков в моей работе сейчас, и с ним проще всего показывать некоторые концепты из-за довольно простого синтаксиса. Если я буду приводить примеры использования HKT на плюсцах, у всех включая меня глаза закровоточат.

Ну и перечитай мой коммент с первой страницы ещё раз. Язычки приходят и уходят, а иногда даже свои приходится выдумывать.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от urxvt

Еще добавлю. Не спора ради, просто впечатлениями делюсь. Мне кажется, ни в одном популярном императивном языке не уделяется столько внимания именно философии. В Го об этом кричали практически на каждом шагу. Этим Го сильно UNIX напоминает. Оно и не удивительно, так как корни и создатели из одной тусовки.

А кто видел вживую, как на го пишут коммерческий код. Они реально эту философию как-то соблюдают? А то она очень уж сильно расходится с общепринятыми подходами из чего я делаю предположение, что на философию все кладут и клепают как привыкли. Или не прав?

Взять вот банально юнит-тесты. По философии assert не положен, пиши if-ы и не выпендривайся. Но 22.3k звёзд у testify говорит само за себя, люди привыкли писать с ассертами и на философов положили большой и толстый игнор в этом вопросе.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

А кто видел вживую, как на го пишут коммерческий код. Они реально эту философию как-то соблюдают? А то она очень уж сильно расходится с общепринятыми подходами из чего я делаю предположение, что на философию все кладут и клепают как привыкли. Или не прав?

Из того, что я видел, то в условном аутсорсе или среднестатистическом стартапе с нанятыми школьниками за полцены то об этой философии, понятное дело, никто даже и не слышал. В «серьезных» (напр. Victoria Metrics) проектах ей очень даже стараются следовать.

Взять вот банально юнит-тесты. По философии assert не положен, пиши if-ы и не выпендривайся.

Как по мне, это не верное утверждение. Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого. Но это легко решается пользовательскими библиотеками.
У них подход, что лучше не добавлять что-то, чем добавить его недостаточно хорошим и потом всю жизнь мучиться.

urxvt ★★★★★
()
Ответ на: комментарий от zg

В приличном обществе на TIOBE не ссылаются - слишком много к нему вопросов. Вот на Redmonk имхо лучше

The RedMonk Programming Language Rankings: January 2024

Чем выше и правее тем лучше (Stackoverflow больше о проблемности языка). Так я бы обратил внимание на Ruby & Typescript из второй группы языков и Scala, Go, Kotlin из третьей группы. Даже Swift местами можно глянуть.

Самое главное в языке, чтоб он ложился на содержимое вашей головы :)

necromant ★★
()
Ответ на: комментарий от urxvt

Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого.

Ниже цитата из книги The Go Programming Language от Kernighan-а (11.2.5):

Many newcomers to Go are surprised by the minimalism of Go’s testing framework. Other languages’ frameworks provide mechanisms for identifying test functions (often using reflec- tion or metadata), hooks for performing ‘‘setup’’ and ‘‘teardown’’ operations before and after the tests run, and libraries of utility functions for asserting common predicates, comparing values, formatting error messages, and aborting a failed test (often using exceptions). Although these mechanisms can make tests very concise, the resulting tests often seem like they are written in a foreign language. Furthermore, although they may report PASS or FAIL correctly, their manner may be unfriendly to the unfortunate maintainer, with cryptic failure messages like «assert: 0 == 1» or page after page of stack traces.

Go’s attitude to testing stands in stark contrast. It expects test authors to do most of this work themselves, defining functions to avoid repetition, just as they would for ordinary programs. The process of testing is not one of rote form filling; a test has a user interface too, albeit one whose only users are also its maintainers. A good test does not explode on failure but prints a clear and succinct description of the symptom of the problem, and perhaps other relevant facts about the context. Ideally, the maintainer should not need to read the source code to decipher a test failure. A good test should not give up after one failure but should try to report several errors in a single run, since the pattern of failures may itself be revealing.

The key to a good test is to start by implementing the concrete behavior that you want and only then use functions to simplify the code and eliminate repetition. Best results are rarely obtained by starting with a library of abstract, generic testing functions.

И далее приводят конкретный пример с assertEquals заменяя его на сравнение и утверждая, что получилось лучше. Я уж не буду всё копировать, PDF легко находится.

Поэтому я таки буду утверждать, что авторы языка намеренно не внесли эту функцию в стандартную библиотеку и намеренно рекомендуют не использовать дополнительных библиотек для этой функции. В крайнем случае написать эту функцию прямо по месту использования. Чего там можно в assertEquals не такого сделать-то… Я бы даже сказал, что сделав эту функцию магической её можно было бы сделать гораздо удобней. К примеру распечатать Assertion Failed: test_math.go:456: sqrt(2) (returns 5) != 4, т.е. текст выражения в ассерте, а не только его значение, которое доступно при обычной реализации.

Ещё могу заметить, что я читал, что в самом гугле в тестах запрещено использовать что-либо кроме стандартной библиотеки.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от urxvt

Ну я допускаю, что в очередной версии языка они и assert-ы добавят, почему нет. Лично я тоже не представляю, как писать юнит-тесты без ассертов. И хотя я в целом предпочитаю следовать философии Go, но конкретно в этом вопросе всё-таки использую testify. В конце концов они не боги и могут ошибаться и менять своё мнение.

vbr ★★★★
()
Ответ на: комментарий от vbr

Ну я допускаю, что в очередной версии языка они и assert-ы добавят, почему нет. Лично я тоже не представляю, как писать юнит-тесты без ассертов.

Ну вот в Java ассертами языка практически никто не пользуется. Для написания юнит тестов используют библиотеки JUnit и AssertJ, у которых свои ассерты есть, гораздо более функциональные.

zg
() автор топика
Последнее исправление: zg (всего исправлений: 1)

GO простой и очень скучный. Из плюсов:

  1. «ВСЕГДА» есть исходники, что позволяет разобраться в коде даже при отсутствие документации.
  2. «Скучность» языка не позволяет сделать массу выкрутасов как на С++ или Java, не надо неделями вкуривать что там нагородили в шаблонах, и что скрывается за той или иной аннотацией. Все вот тут рядом, максимум в соседнем файле. И написано так как Вы бы сам написали. Язык «не позволяет» 100500 вариантов одного и того же.
  3. Все под рукой библиотека где есть достаточный набор функций для реализации консольного приложения.

Из минусов:

  1. «ВСЕГДА» есть исходники, через это продавать либы и фр-ворки тяжело, поэтому скорее всего нет нормального гуя (я так думаю).
  2. «Скучность» языка - если что то хочется то надо приложить массу усилий и хаков что бы получить нечто не входящие в «нормальный» возможности. И с 90% у Вас в результате это не получится.
  3. Стандартная библиотека, она же и средняя по производительности и удобству. Если надо что быстрое, легкое или необычное идем на строну. А там может быть все что угодно, от давно забытого разрабом кода, до ультра экспериментального.
alnkapa
()
Ответ на: комментарий от InterVi

Go под лицензией BSD, поддерживается и другими компиляторами (gcc), так что он вряд ли сдохнет — сообщество подхватит. Уже слишком много проектов, чтобы он мог быстро исчезнуть.

Смешно читать про сообщество подхватит.

Сообщество еще ни одного крупного проекта подхватить не смогло.

anonymous
()
Ответ на: комментарий от Cergoo

Потому что в гугле сидят умные люди, которые понимают, что выразительность - это для поэтов, а им надо мешки ворочать силами армии макак.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

что Kotlin - это больше Android

глупости какие, Спринг это уже практически котлин по дефолту

И да, я считаю, что Java неуклонно движется в сторону COBOL номер два.

JVM никуда не денется, ибо альтернатив ей нет

в оценке перспективности смены карьеры с Java Backend разработчика

Вот фиг его знает, дружище, для Джависта перейти на Котлин, ну это как со старого Камаза пересесть на современный Мерседес - одно удовольствие, надо только пару дней почитать учебник и начать пользоваться. Что тут страдание разводить - стоит мне, не стоит мне, а вдруг, а может быть. Еще раз - цена вопроса зайти на https://kotlinlang.org/, прочитать туториал и как бы всё, остальная херня типа градл/мавен тебе как джависту должна быть известна давно.

FishHook
()