А что плохого в го?

Все хорошо)

А потом заходишь в код проектов на этих динамических языках и тянешься за веревкой с мылом, особенно, если эта борода падает тебе на поддержку

взаимодействие микросервисов по-хорошему и должно быть асинхронным.

глубоко

Облака тот же бэкенд, просто приправлен красиво? Ведь так?

забота о масштабировании и оркестрации ложится на облачную платформу

выросла нагрузка - у тебя автоматически по твоим правилам поднимаются дополнительные ресурсы

А потом заходишь в код проектов на этих динамических языках и тянешься за веревкой с мылом, особенно, если эта борода падает тебе на поддержку

Легаси что на динам что на статик языках ад. Пока джавист обмазывается тонной врапперов над врапперами, питонщик сливает все данные в один словарь и надрачивает его. Что тут хуже и у кого, не понятно

если вы боитесь легаси, вы не ту профессию выбрали)

выросла нагрузка - у тебя автоматически по твоим правилам поднимаются дополнительные ресурсы

Это уже вопрос хостинга, на самом деле раньше так и было, только кластер прикручивали (а сейчас, наверное, ползунок в админке хостинга двигается?)

Словари в динамических языках хуже. Никогда не знаешь что является ключом на этот раз - 1 или "1"

Словари в динамических языках хуже. Никогда не знаешь что является ключом на этот раз - 1 или "1"

на "1" - ужас какой)

Словари в динамических языках хуже. Никогда не знаешь что является ключом на этот раз - 1 или "1"

так что лучше как-нибудь обойтись без динамических языков :)

по моим наблюдениям, пока джависты решают проблемы созданные им самим (оборачивая в оборачивание), какой-нибудь питонщик, решает ту задачу кратно проще (тупо объединив данные, потому что все данные у него подобие словаря). Вопрос в том, что на джаве действительно можно написать модульный код, то есть буквально слоями за слоями положить его (как бы в противовес спаггети коду, когда меняя состояния в одном слое падает другой). Но так писать еще надо уметь и это не фишка джавы, а фишка ООП и IoC

То есть на динам языках решается проще и быстрее, но порой ценной спаггети кода

Те же задачи

Кроме архитектурных задач, например мультипоточности

выросла нагрузка - у тебя автоматически по твоим правилам поднимаются дополнительные ресурсы

если бы всё было так просто, потом упираешься в базу, в mq, в транзакции

Динамические языки не дают гарантий, что такое-то свойство и такой-то метод вообще существует.

А разве не на любом языке можно писать спагетти? Такое чувство, что вы все в стартимах сидите с идеальным заказчиками и менеджментом

А разве не на любом языке можно писать спагетти? Такое чувство, что вы все в стартимах сидите с идеальным заказчиками и менеджментом

да вот жеж

если бы всё было так просто, потом упираешься в базу, в mq, в транзакции

да, это проблемы, но которые люди уже научились решать.

О_О

где?

гыы, @kotlin_lang превращается в @jvmchat :)

гыы, @kotlin_lang превращается в @jvmchat :)

всё свои

А разве не на любом языке можно писать спагетти? Такое чувство, что вы все в стартимах сидите с идеальным заказчиками и менеджментом

Так я про это и говорю что статик. типизация не дает ничего кроме самых банальных ошибок "запутался пока писал"

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

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

прикладная область, заказчик

Корпоративщики должны страдать, да

где?

да те же сервера распределенных транзакций

Так я про это и говорю что статик. типизация не дает ничего кроме самых банальных ошибок "запутался пока писал"

так эти ошибки как раз и возникают в динамических языках!

Динамические языки не дают гарантий, что такое-то свойство и такой-то метод вообще существует.

Как будто есть разница - завалиться от NPE или NameError (я вас умоляю ? )

Так я про это и говорю что статик. типизация не дает ничего кроме самых банальных ошибок "запутался пока писал"

а как же рефакторинг?

Как будто есть разница - завалиться от NPE или NameError (я вас умоляю ? )

От NPE есть спасение — не использовать null или писать на Котлине. От вызова несуществующей функции — нет, потому что нет средств языка, которые обяжут вызывать только существующие функции.

с рефакторингом печалька, да и с автокомплитом порой

Как будто есть разница - завалиться от NPE или NameError (я вас умоляю ? )

конечно есть

Как будто есть разница - завалиться от NPE или NameError (я вас умоляю ? )

есть. В динамических языках тоже есть NPE, но плюс к тому ещё и NameError'ы. Для прототипирования - годится, для чего-то серьезного надо быть наркоманом, чтобы выбрать динамический язык

да те же сервера распределенных транзакций

Так это же очень медленно

От NPE есть спасение — не использовать null или писать на Котлине. От вызова несуществующей функции — нет, потому что нет средств языка, которые обяжут вызывать только существующие функции.

Вы не понимаете философию динам языков, NPE есть динамическое состояние, которые вы так же будете проверять в коде, даже в котлине. Так вот динам языки, ставят акцент на динамичность (полностью), давая в замен полную (или почти полную) рефлексию в коде. Поэтому очень глубо звучит, когда берут питон и возмущаются про типы в переменных. Это как взять теплоход и возмущаться что он плохо по рельсам катится (но с горки катится ? )

с рефакторингом печалька, да и с автокомплитом порой

я когда начинал после жавы писать на жс (реакт+редукс), было так приятно писать код "с нуля", быстро, четко, минимум бойлерплейта. но потом понадобилось поддерживать и рефакторить уже написанный код, и, в силу слабого опыта разработки на динамических языках, это была настоящая боль, когда ты правишь что-то в одном месте, и у тебя отваливается часть функционала в другом, при этом это все только тестами можно выяснить, а если их нет или они не учитывают конкретный случай - только в рантайме можно узнать, что ты забыл проперти переименовать

я когда начинал после жавы писать на жс (реакт+редукс), было так приятно писать код "с нуля", быстро, четко, минимум бойлерплейта. но потом понадобилось поддерживать и рефакторить уже написанный код, и, в силу слабого опыта разработки на динамических языках, это была настоящая боль, когда ты правишь что-то в одном месте, и у тебя отваливается часть функционала в другом, при этом это все только тестами можно выяснить, а если их нет или они не учитывают конкретный случай - только в рантайме можно узнать, что ты забыл проперти переименовать

вообще, по JS-коду порой видно, что его писал джавист ?

Вы не понимаете философию динам языков, NPE есть динамическое состояние, которые вы так же будете проверять в коде, даже в котлине. Так вот динам языки, ставят акцент на динамичность (полностью), давая в замен полную (или почти полную) рефлексию в коде. Поэтому очень глубо звучит, когда берут питон и возмущаются про типы в переменных. Это как взять теплоход и возмущаться что он плохо по рельсам катится (но с горки катится ? )

динамическое состояние в ООП должно разрешаться полиморфизмом

Так это же очень медленно

где про это почитать можно?

где про это почитать можно?

Мыло.ру пишет у себя где-то, про хайлоад и реляционки

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

поэтому будущее джава энтерпрайза за бутом, за вертиксом, за бутиком, спаркаджава и т..д.

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

Писать на джеэс вообще сулит проблемы

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

это очевидно, поэтому серьезный бизнес берет языки со статической типизацией

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

Pivotal, создатель Spring - чем не серьезная компания?

я когда начинал после жавы писать на жс (реакт+редукс), было так приятно писать код "с нуля", быстро, четко, минимум бойлерплейта. но потом понадобилось поддерживать и рефакторить уже написанный код, и, в силу слабого опыта разработки на динамических языках, это была настоящая боль, когда ты правишь что-то в одном месте, и у тебя отваливается часть функционала в другом, при этом это все только тестами можно выяснить, а если их нет или они не учитывают конкретный случай - только в рантайме можно узнать, что ты забыл проперти переименовать

На динам языках надо уметь писать, ты получаешь более простое решение чем в статик языках, ценой контроля кода (самому). На самом деле, что в тех языках придется тесты писать, что в тех. Реальная проблема, кроме ужасов рефакторинга и отсутствия автокомплита это производительность и порой отсутствие вменяемой многопоточности. Ставя противовес джавы и питона, я скажу что без IDE на джаве вообще попаболь писать. Так что весь этот рефакторинг превращается в тыкву, если в этот момент нет норм IDE. А вот динамизм (рефлексия) она всегда нужна, даже спринг делает прокси-обертки, чтобы достичь уровня мета-программирования динам языков.

Pivotal, создатель Spring - чем не серьезная компания?

что касается EE, у рэдхат есть темплэйты под микросервисы с вилдфлай.

и да, нод.жс это же адок

Ну учитывая, насколько двигаютсья всякие ts и flow в js, и то, что в питоне думают про анотации типов, походу уже всем ясно, что без типов никуда. И чем они строже, тем лучше. Про скорость на дин. языках - миф, на стат. языках можно так же бысть писать, если посадить макаку и отключить ей моск

На динам языках надо уметь писать, ты получаешь более простое решение чем в статик языках, ценой контроля кода (самому). На самом деле, что в тех языках придется тесты писать, что в тех. Реальная проблема, кроме ужасов рефакторинга и отсутствия автокомплита это производительность и порой отсутствие вменяемой многопоточности. Ставя противовес джавы и питона, я скажу что без IDE на джаве вообще попаболь писать. Так что весь этот рефакторинг превращается в тыкву, если в этот момент нет норм IDE. А вот динамизм (рефлексия) она всегда нужна, даже спринг делает прокси-обертки, чтобы достичь уровня мета-программирования динам языков.

рефлексия нужна в довольно узком круге задач

Pivotal, создатель Spring - чем не серьезная компания?

тем что основной продукт опенсорс, нужная развитая платная поддержка решения. основная задача, которую решают ЕЕ-сревера - стратегическое прикрытие задницы. вот наковнокодили что-то, например, в типичной конторе с жесткой вертикальной иерархией и хуевой тучей обязатесльтв (госконтора, банк, например) - и оно ебанулось. если это опенс-сорс - все получают пизды "- вы чо сука нахуй! - да тут спринг-микросервис не так настроили! - да у нас убытки, блеать. пермии лишу!". а теперь та же самая сиутация с жирным и дорогим апп.севером "- вы чо сука нахуй! - аяй ая яй, это же вебсфера упала, оркал, купленная за миллионы! как же так, как же так... - да ладно! мы же за миллионы эту хуйню купили, как же так?!". и пока все устравиают длинное разбирательство, ссылаются на вендора, все стороны успевают прикрыть задницу, а если не получается - вызывают вендора

цены видел на продукты? даже консерваторы смотрят в сторону опенсорса

рефлексия нужна в довольно узком круге задач

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

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

рефлексия нужна в довольно узком круге задач

сразу же нужна, как только начинает не хватать полиморфизма в рантайме. Чем "больше полиморфизма", тем удобнее и красивее всякие фреймворки получаются.

сразу же нужна, как только начинает не хватать полиморфизма в рантайме. Чем "больше полиморфизма", тем удобнее и красивее всякие фреймворки получаются.

красиво != надёжно и поддерживаемо

цены видел на продукты? даже консерваторы смотрят в сторону опенсорса

эх если бы смотрели... с одной стороны летит задача, где IBM MQ и Oracle с другой сейчас архитеткор впаривает wildFly / weblogic

если уровень разработчика норм и он не ставит целей гадить, то красиво == надежно, и поддерживаемо

эх если бы смотрели... с одной стороны летит задача, где IBM MQ и Oracle с другой сейчас архитеткор впаривает wildFly / weblogic

вилдфлай бесплатный

веблоджик тонны нефти стоит

вилдфлай бесплатный

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

Ну никто не будет удалять в структуре важные данные, так же как и никто не будет делать приватные поля публичными. Беря в руки динам язык и самому вставлять палки и потом возмущаться, что компилятор тут бы мне помог - это глупо слегка

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

где работаешь?

где работаешь?

сбертех

оооооо

у вас же есть вроде проекты с упором в опенсорс

даже скала есть

видимо проект у тебя старый или..?

хех)

у вас же есть вроде проекты с упором в опенсорс

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

АС - это что?

автоматизированная система. в ТЗ так называют почти любую систему, сервис

На динам языках надо уметь писать, ты получаешь более простое решение чем в статик языках, ценой контроля кода (самому). На самом деле, что в тех языках придется тесты писать, что в тех. Реальная проблема, кроме ужасов рефакторинга и отсутствия автокомплита это производительность и порой отсутствие вменяемой многопоточности. Ставя противовес джавы и питона, я скажу что без IDE на джаве вообще попаболь писать. Так что весь этот рефакторинг превращается в тыкву, если в этот момент нет норм IDE. А вот динамизм (рефлексия) она всегда нужна, даже спринг делает прокси-обертки, чтобы достичь уровня мета-программирования динам языков.

чем на динамических языках решения будут проще чем на статических?

чем на динамических языках решения будут проще чем на статических?

быстрее разрабатывать, быстрее сборка. каждой задачи свой инструмент, как говорится

быстрее разрабатывать, быстрее сборка. каждой задачи свой инструмент, как говорится

ты спешишь куда то?

быстрее разрабатывать, быстрее сборка. каждой задачи свой инструмент, как говорится

вот про "быстрее разрабатывать" все часто пишут, но эт спорно, я не представляю, как можно быстро писать, на том, где ты не уверен что возвращает какаой метод и вообще какой контракт

быстрее разрабатывать, но дольше проверять, не поломал ли чего

быстрее разрабатывать, быстрее сборка. каждой задачи свой инструмент, как говорится

на счет скорости разработки это спорно. да сборка быстрее будет, но само приложение от этого стартовать быстрее не будет у нас в пхп первый старт приложухи после изменения в коде занимает около минуты(кодовая база 500к строк наших исходников)

быстрее разрабатывать, но дольше проверять, не поломал ли чего

открываешь какой-нибудь метод на питоне и жсе, и гадаешь че пришло и че происходит внутри

четкие контракты в сигнатурах и вывод типов, вот что быстро

мы в пхп тайпхинтами упарываемся не от хорошей жизни с динамическим языком

by the way, динамический шаблонизатор — не так уж и плохо

вот про "быстрее разрабатывать" все часто пишут, но эт спорно, я не представляю, как можно быстро писать, на том, где ты не уверен что возвращает какаой метод и вообще какой контракт

простой пример. тебе прилетала задача прототипного характера на веб-сервис. требования размыте и постоянно меняются. ты задолбаешься менять там всякие pojo/dao, роуты итд. или ты просто берешь какой-нибудь expressJS и у тебе пара простых движений все это сделать, а поддержка json уже есть в самом язык

пхп как шаблонизатор в пхпшных приложухах тоже не используется) для этого отдельные темплейтовые фреймы есть

простой пример. тебе прилетала задача прототипного характера на веб-сервис. требования размыте и постоянно меняются. ты задолбаешься менять там всякие pojo/dao, роуты итд. или ты просто берешь какой-нибудь expressJS и у тебе пара простых движений все это сделать, а поддержка json уже есть в самом язык

бери Map<String,Object> и меняй до усирачки)

простой пример. тебе прилетала задача прототипного характера на веб-сервис. требования размыте и постоянно меняются. ты задолбаешься менять там всякие pojo/dao, роуты итд. или ты просто берешь какой-нибудь expressJS и у тебе пара простых движений все это сделать, а поддержка json уже есть в самом язык

а потом null и undefined

чем на динамических языках решения будут проще чем на статических?

Если по питоняче: за счет утиной типизации (не важное что это главное чтобы крякало - имело метод тот или иной). Все есть объект, полная рефлексия, мета-программирование, все данные есть последовательности, данные контекста - обычный словарь и чаще отделены от исполнения. Пока твоя программа компилируется, скриптовой язык уже исполнился. Ну и меньше кода, намного его меньше. Меньше кода - качественней бизнес логика программы и меньше ошибок.

Так гайз, особенно Дима, оффтоп такой лучше для jvmchat подходит

простой пример. тебе прилетала задача прототипного характера на веб-сервис. требования размыте и постоянно меняются. ты задолбаешься менять там всякие pojo/dao, роуты итд. или ты просто берешь какой-нибудь expressJS и у тебе пара простых движений все это сделать, а поддержка json уже есть в самом язык

вот именно, прототипирование = постоянные изменение, постоянно прийдется отлавливать баги из-за изменений и рефакторинга. правда если никакой стабильности вообще не нужно ни разу, то может быть и да.

Если по питоняче: за счет утиной типизации (не важное что это главное чтобы крякало - имело метод тот или иной). Все есть объект, полная рефлексия, мета-программирование, все данные есть последовательности, данные контекста - обычный словарь и чаще отделены от исполнения. Пока твоя программа компилируется, скриптовой язык уже исполнился. Ну и меньше кода, намного его меньше. Меньше кода - качественней бизнес логика программы и меньше ошибок.

кода не меньше

сравнить PHP-код с Kotlin-кодом — разница будет в изящности, надёжности, но никак не в размере

на котлине будет в разы меньше кода