ну я не верю в такие синтетические тесты, во-первых.
во-вторых, вроде непосредственно про скорость вопрос и не стоял. Все таки если нужна именно скорость (причем без пауз), то пишут на других технологиях.
С этим кодом все хорошо, плохо может быть, когда придется что-то более сложное сделать.
Я писал на rx-java модуль, не сильно сложный. Но покрыть его внятно тестами не получилось.
Пришлось по сути взять и переписать так, чтобы каждый небольшой кусок обработки в стриме можно было протестировать независимо. В общем, несмотря на крутость решения вышло так, что пришлось потратить гораздо больше времени, и решение получилось довольно хрупким. Хотя, наверное, это вопрос практики.
Но у меня такой личный опыт
Ну честно говоря многие джава библиотеки хоть и можно использовать из скалы, без специальных биндингов для api это может выглядеть достаточно уродливо.
Но зависит от библиотеки конечно же.
Ну причиной может быть например экосистема, которой нет (предположительно) у хаскеля, но есть у скалы.
Вообще есть примеры того, как люди писали http сервера на баше :) (не сравниваю баш и хаскель, просто как пример).
Ну да, есть такая проблема на самом деле.и в Джава мире она тоже часто встречается. Когда одна из зависимостей транзитивно зависит на очень старую версию другой библиотеки и не даёт обновить другие зависимости.
Похоже, что эта проблема может на любой платформе возникнуть. Варианта тут 2: либо изолировать такую зависимость (как Спарк) в отдельный сервис (или отдельный класслоадер), или же просто отказаться от ее использования.
Хотя да, скала больше способствует возникновению таких ситуаций. Хоть это и не так плохо как у Питона 2 и 3 :)
Вы не видите, а разработчики, которые по 10 лет поддерживают какую-то систему, видят
Я бы сказал, что разработчики, которые написали систему и выкинули ее — это особый класс людей, которым очень повезло (хотя я сам так работал много лет). Я конечно имею в виду тех, кто работает над "живым" проектом.
Да, есть разные ситуации — когда проект никто не трогал много лет и он до сих пор на 5 Джаве. Но в этом случае даже совместимость джавы вам не поможет его обновить на новую версию. Придется очень много всего переписать, заменить часть неподдерживаемых библиотек и т.д. А вот если проект изначально хорошо поддерживается и инкрементально обновляется, то имхо проблема совместимости становится гораздо менее острой.
Хотя опять же бывают исключения.
А в случае Scala оба подхода декларируются как верные.
Ну можно же договориться, какой из подходов использовать? Видел реальный проект на Джаве, где в стайл гайдах было написано не использовать стримы, а использовать циклы.
Я наверное не совсем корректно выразился.
Я имел в виду, что отсутствие совместимости — это про леса, которую в принципе можно решать. Явно из-за нее я бы не стал отказываться от инструмента.
Под отсутствием совместимости я имею в виду, что обновив версию Scala, вам придется пройти процедуру миграции, обновить несовместимы код, все протестировать на новой версии.
Хотя как в примере из комментария ниже про Спарк могут быть нюансы.
Значит у вас огромный проект и в Го у вас абстракции и структуры утекут и получится такая каша, что время компиляции будет цветочками :)
Ну вообще-то совсем не значит. Абстракции могут утечь на любом языке, и на Джаве в частности.
это какой кто граничный случай, что я бы не расматривал его
Ну это конкретная проблема, которую я вижу ежедневно, когда 200+ разработчиков коммитят в мастер и запускают свои билды на 300+ ci-агентах (и это все ещё не Гугл).
Если у вас проект, который пишут 1,5 человека, то в принципе не так важно, на чем они пишут и с помощью каких инструментов. Важно сделать так, чтобы когда система начнет расти, ее можно было легко смасштабировать: не только прод инфраструктуру, но и CI, средства разработки, деплоймента и т.д.
Да, действительно все именно так. Любая технология имеет свои недостатки. Сплит-брейн раньше (это было больше 3 лет назад) был очень большой и частой проблемой. Надеюсь, что с того времени ращработчики что-то с этим сделали. Но вообще акка-кластер не обязательно использовать. Также как и акка-персистенс. Да и вообще, как верно подмечено, для стейтлес-сеовисов это может быть немного оверкилл. По настоящему экторы нужну, где нужно хранить состояние. Но даже в этом случае есть миллион альтернативных подходов.
Я бы не назвал кривую изучения акка слишком крутой, я смог довольно без проблем въехать. Вот где действительно сложно — так это akka-streams. Вот где слом мозга протсходит. Блин, но зато какие открываются возможности.
Как говорил дядя Бен: "Чем больше сила, тем больше ответственность" :)
На самом деле я не утверждал, что я являюсь экспертом в области Scala. Скорее даже наоборот. Но тот опыт, что у меня был, не вызвал у меня отторжения, и желание продолжать углубляться не пропало (как могло бы). Более того, я наблюдал непосредственно несколько достаточно успешных проектов на Scala и akka.
Ну тут глупо спорить, в функциональном стиле писать на Java можно.
Я сам лично писал несколько проектов на RxJava, более сложно тестируемого кода я не видел :)
Такой код действительно можно писать и даже пытаться сопровождать, но, например, на Scala это будет более нативно имхо.
Что касается размера, то я скорее не про EBS и цену, а про время — время на сборку, время на упаковку, время на доставку и и.д.
Я работаю не в Гугле (то есть я не Гугл) но у меня сейчас размеры всего такие, что сборка, регрессия, деплой и прочее занимают часы. Так что да, тут в какой-то момент могут пригодиться и меньшее время компиляции, и меньшее время скачивания контейнеров на холодном CI-агенте, и так далее.
Валидные замечания.
Правда пока люди будут писать if err != nil вы в java будете прокидывать исключения по всем слоям приложения и оборачивать в try/catch :)
А что касается размера образа, то не стоит недооценивать. Когда счёт пойдет на сотни и тысячи хостов, это все зачтется.
Ну я писал на Akka, akka-streams, и т.д.
Так что я не тру фпшник :)
В принципе, впечатления были только позитивные. Нравится та самая "мощность" языка, его выразительность. Akka как платформа — тоже огонь ;)
Не очень понятно, как Докер помогает заменить или достичь похожих результатов. Основная фича — отсутствие проблем с конкурентностью и проч.
Да, хотелось бы попробовать тру фп стэк тоже, но, видимо, не судьба.
Соглашусь про скорость компиляции. Ровно то же самое справедливо и для Scala, и для TypeScript. Вопрос в том, насколько будет большим прирост и насколько большой ожидается кодовая база.
Например, не так важно, занимает компиляция микросервис 20 или 30 секунд. Собственно как и неважно, занимает ли сборка 20 минут или 30 минут (и то, и другое — чудовищно много).
Что касается безопасности и поддержки, то не обладаю информацией, чтобы судить об этом. В любом случае, у Котлина есть мейнтейнер — уважаемая компания, которая должна на такого рода проблемы реагировать.
С одной стороны, я согласен, что возможность писать микросервис на полностью новом стеке должна дать шанс менее мейнстримовым языкам и платформам. Но, к сожалению, я не думаю, что это происходит на практике. Мелким стартапа выгоднее иметь унифицированный стек, чтобы любой член команды мог работать над любой частью системы.
Более крупным компаниям бывает уже слишком поздно отказываться от устоявшихся практик.
Что касается мощности языка — чтобы писать круды, мощность не нужна, к сожалению.
Про заголовок — неплохо ;)
На самом деле вообще не было намерения восхвалять Го. Как я отметил, мне сам язык Но не нравится. Но, выходит, что на сегодня для меня лично это первый выбор на написание бэкенда общего назначения.
Что касается проблем Скалы:
1) я лично не считаю это такой уж большой проблемой. Ну да, нет совместимости, но я лично не вижу в этом проблемы. Даже переход между версиями java — это отдельные проект, где надо все проверить и убедиться, что ничего не сломалось.
2) ну тут тоже довольно странно: на java можно писать в объектном стиле, можно писать в процедурном, можно в "реактивном"… кроме того, безобразный код можно написать на любом языке. В любом случае каждый проект устанавливает свои стайл-гайды.
Я уж не говорю про истории, как местные жители громят остановки Гуглового автобуса из-за того, что в местах, где появляется такая остановка, сразу подскакивают цены на жильёю
Не знаю, я слышал довольно негативные отзывы, как, например, люди сажают в машину надувных кукол, чтобы ездить по транзитным полосам :)
А про график, как только тебе нужно ребенка завезти в школу перед работой, твой график сразу становится нормированным.
во-вторых, вроде непосредственно про скорость вопрос и не стоял. Все таки если нужна именно скорость (причем без пауз), то пишут на других технологиях.
С этим кодом все хорошо, плохо может быть, когда придется что-то более сложное сделать.
Я писал на rx-java модуль, не сильно сложный. Но покрыть его внятно тестами не получилось.
Пришлось по сути взять и переписать так, чтобы каждый небольшой кусок обработки в стриме можно было протестировать независимо. В общем, несмотря на крутость решения вышло так, что пришлось потратить гораздо больше времени, и решение получилось довольно хрупким. Хотя, наверное, это вопрос практики.
Но у меня такой личный опыт
Ну честно говоря многие джава библиотеки хоть и можно использовать из скалы, без специальных биндингов для api это может выглядеть достаточно уродливо.
Но зависит от библиотеки конечно же.
Ну причиной может быть например экосистема, которой нет (предположительно) у хаскеля, но есть у скалы.
Вообще есть примеры того, как люди писали http сервера на баше :) (не сравниваю баш и хаскель, просто как пример).
Ну да, есть такая проблема на самом деле.и в Джава мире она тоже часто встречается. Когда одна из зависимостей транзитивно зависит на очень старую версию другой библиотеки и не даёт обновить другие зависимости.
Похоже, что эта проблема может на любой платформе возникнуть. Варианта тут 2: либо изолировать такую зависимость (как Спарк) в отдельный сервис (или отдельный класслоадер), или же просто отказаться от ее использования.
Хотя да, скала больше способствует возникновению таких ситуаций. Хоть это и не так плохо как у Питона 2 и 3 :)
Я бы сказал, что разработчики, которые написали систему и выкинули ее — это особый класс людей, которым очень повезло (хотя я сам так работал много лет). Я конечно имею в виду тех, кто работает над "живым" проектом.
Да, есть разные ситуации — когда проект никто не трогал много лет и он до сих пор на 5 Джаве. Но в этом случае даже совместимость джавы вам не поможет его обновить на новую версию. Придется очень много всего переписать, заменить часть неподдерживаемых библиотек и т.д. А вот если проект изначально хорошо поддерживается и инкрементально обновляется, то имхо проблема совместимости становится гораздо менее острой.
Хотя опять же бывают исключения.
Ну можно же договориться, какой из подходов использовать? Видел реальный проект на Джаве, где в стайл гайдах было написано не использовать стримы, а использовать циклы.
Я наверное не совсем корректно выразился.
Я имел в виду, что отсутствие совместимости — это про леса, которую в принципе можно решать. Явно из-за нее я бы не стал отказываться от инструмента.
Под отсутствием совместимости я имею в виду, что обновив версию Scala, вам придется пройти процедуру миграции, обновить несовместимы код, все протестировать на новой версии.
Хотя как в примере из комментария ниже про Спарк могут быть нюансы.
Ну вообще-то совсем не значит. Абстракции могут утечь на любом языке, и на Джаве в частности.
Ну это конкретная проблема, которую я вижу ежедневно, когда 200+ разработчиков коммитят в мастер и запускают свои билды на 300+ ci-агентах (и это все ещё не Гугл).
Если у вас проект, который пишут 1,5 человека, то в принципе не так важно, на чем они пишут и с помощью каких инструментов. Важно сделать так, чтобы когда система начнет расти, ее можно было легко смасштабировать: не только прод инфраструктуру, но и CI, средства разработки, деплоймента и т.д.
Ну нет, позвольте не согласиться. Я писал на RxJava до akka-streams. Знание rx не сильно помогло :(
Да, действительно все именно так. Любая технология имеет свои недостатки. Сплит-брейн раньше (это было больше 3 лет назад) был очень большой и частой проблемой. Надеюсь, что с того времени ращработчики что-то с этим сделали. Но вообще акка-кластер не обязательно использовать. Также как и акка-персистенс. Да и вообще, как верно подмечено, для стейтлес-сеовисов это может быть немного оверкилл. По настоящему экторы нужну, где нужно хранить состояние. Но даже в этом случае есть миллион альтернативных подходов.
Я бы не назвал кривую изучения акка слишком крутой, я смог довольно без проблем въехать. Вот где действительно сложно — так это akka-streams. Вот где слом мозга протсходит. Блин, но зато какие открываются возможности.
Как говорил дядя Бен: "Чем больше сила, тем больше ответственность" :)
На самом деле я не утверждал, что я являюсь экспертом в области Scala. Скорее даже наоборот. Но тот опыт, что у меня был, не вызвал у меня отторжения, и желание продолжать углубляться не пропало (как могло бы). Более того, я наблюдал непосредственно несколько достаточно успешных проектов на Scala и akka.
Ну тут глупо спорить, в функциональном стиле писать на Java можно.
Я сам лично писал несколько проектов на RxJava, более сложно тестируемого кода я не видел :)
Такой код действительно можно писать и даже пытаться сопровождать, но, например, на Scala это будет более нативно имхо.
Что касается размера, то я скорее не про EBS и цену, а про время — время на сборку, время на упаковку, время на доставку и и.д.
Я работаю не в Гугле (то есть я не Гугл) но у меня сейчас размеры всего такие, что сборка, регрессия, деплой и прочее занимают часы. Так что да, тут в какой-то момент могут пригодиться и меньшее время компиляции, и меньшее время скачивания контейнеров на холодном CI-агенте, и так далее.
Валидные замечания.
Правда пока люди будут писать if err != nil вы в java будете прокидывать исключения по всем слоям приложения и оборачивать в try/catch :)
А что касается размера образа, то не стоит недооценивать. Когда счёт пойдет на сотни и тысячи хостов, это все зачтется.
Ну я писал на Akka, akka-streams, и т.д.
Так что я не тру фпшник :)
В принципе, впечатления были только позитивные. Нравится та самая "мощность" языка, его выразительность. Akka как платформа — тоже огонь ;)
Не очень понятно, как Докер помогает заменить или достичь похожих результатов. Основная фича — отсутствие проблем с конкурентностью и проч.
Да, хотелось бы попробовать тру фп стэк тоже, но, видимо, не судьба.
Соглашусь про скорость компиляции. Ровно то же самое справедливо и для Scala, и для TypeScript. Вопрос в том, насколько будет большим прирост и насколько большой ожидается кодовая база.
Например, не так важно, занимает компиляция микросервис 20 или 30 секунд. Собственно как и неважно, занимает ли сборка 20 минут или 30 минут (и то, и другое — чудовищно много).
Что касается безопасности и поддержки, то не обладаю информацией, чтобы судить об этом. В любом случае, у Котлина есть мейнтейнер — уважаемая компания, которая должна на такого рода проблемы реагировать.
Ну если речь именно о библиотеках, то Kotlin ничем не уступает Java (все до единой библиотеки доступны)
С одной стороны, я согласен, что возможность писать микросервис на полностью новом стеке должна дать шанс менее мейнстримовым языкам и платформам. Но, к сожалению, я не думаю, что это происходит на практике. Мелким стартапа выгоднее иметь унифицированный стек, чтобы любой член команды мог работать над любой частью системы.
Более крупным компаниям бывает уже слишком поздно отказываться от устоявшихся практик.
Что касается мощности языка — чтобы писать круды, мощность не нужна, к сожалению.
Про заголовок — неплохо ;)
На самом деле вообще не было намерения восхвалять Го. Как я отметил, мне сам язык Но не нравится. Но, выходит, что на сегодня для меня лично это первый выбор на написание бэкенда общего назначения.
Что касается проблем Скалы:
1) я лично не считаю это такой уж большой проблемой. Ну да, нет совместимости, но я лично не вижу в этом проблемы. Даже переход между версиями java — это отдельные проект, где надо все проверить и убедиться, что ничего не сломалось.
2) ну тут тоже довольно странно: на java можно писать в объектном стиле, можно писать в процедурном, можно в "реактивном"… кроме того, безобразный код можно написать на любом языке. В любом случае каждый проект устанавливает свои стайл-гайды.
А про график, как только тебе нужно ребенка завезти в школу перед работой, твой график сразу становится нормированным.