Еще одна, 100500-я по счету статья ни о чем… простое перечисление фич.
Думал, хоть что-то из практики применения будет.
А тут очередная копипаста документации.
Я подобные предупреждения браузера воспринимаю просто как страховку.
Ну как ремень безопасности в машине. Вожу очень аккуратно, но я не один на дороге.
Сколько уже было историй, когда были проблемы с вполне легитимными сайтами.
И ломают, и забывают домен продлить и он уходит… и т.д. и т.п.
Да ладно, что там непонятного?
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
Да, я в курсе про то что эта аннотация, не является частью системы типов Java.
Просто судя по всему, эта аннтация перекрывает большинство кейсов применения.
Как круто… т.е. по вашей логике, если бы например, программу аполлон сделала команда из России, на деньги американцев, для американской компании, будучи просто наемными работниками… и назвала бы его именем острова где-то рядом с Россией, то это была бы победа России, аналогичная запуску первого космонавта?
Вы серьезно?
Фейспалм…
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…
Другими словами, ключевое отличие системы типов Kotlin от Java — это замена аннотации NotNull на синтаксический сахар в виде символа "?"… я правильно понял?
>Что еще брехня?
Все пункты, которые вы перечислили в первоначальном каменте, по сути не соответствуют действительности.
Ну и сейчас все равно передергивания же идут и введения в заблуждение людей…
> «что в РФ по дефолту ты сразу всем должен, и хорошие деньги»
1. Кому «всем»? Что за чушь. Только налоговой и только 1 фиксированный налог.
2. Этот налог можно вычитать из прибыли. Вычитать полностью.
Для вас 27т.р./год это действительно «хорошие» деньги? Серьезно?
3. Чтобы не платить этот фиксированный налог вообще, надо зарабатывать около 30т.р./мес.
Что далеко не фантастические деньги. И помешает по сути только тем, кто либо открыл ИП «по приколу» и не ведет деятельность. Либо тем, кто совсем по мелочи безнесом занимался. Опять же, зарабатывая меньше этого порога (30т.р.) всего лишь фиксированный налог не полностью вычитается, но все равно вычитается.
>«До 6% не спишешь, но до 15-20% понизить можно, с грамотным налоговым консультантом.»
Ну да, ну да, а все грамотные консультанты, как известно, работают бесплатно.
Ну и сам посыл «Лучше платить 15-20% налогов в ФРГ, чем 6% в РФ» конечно гениальная.
Как вы с таким подходом к финансам бизнесом-то занимаетесь?
Мда…
Люди, вы чего? Какие гении, продакшен код, преждевременная оптимизация и вот это вот все?
Ну блин никто же не пишет такой продакшен код, это же очевидно рассказ про другое…
У меня родственники живут в Европе, у них небольшой бизнес. Плюс я сам веду несколько лет свой небольшой бизнес как ИП. Так что мне есть с чем сравнивать…
Меня собственно зацепила откровенная брехня qde5n1k. Просто не надо передергивать и сгущать краски.
У меня нет иллюзий по поводу бизнеса в РФ. Многое видел собственными глазами еще с 90-х. И мне грустно наблюдать за тем, что происходит в глобальном плане с малым бизнесом.
Но повторю свое мнение. Если нечего сказать по существу и весь опыт из пальца высосан, то лучше помолчать. Чем вводить других людей в заблуждение…
Если уж говорить «справедливости ради», то надо упомянуть, что ИП в европе (там где живут родственники) платит поряджка 12-15% налогов. И они с завистью смотрят на мои 6%.
Да, у них вариантов вычетов больше. Но они не уменьшают налоги в 2 раза.
Если Европейцам предложить самостоятельно сходить с бумажками для регистрации ИП и потратить день на это. Но в замен дать 6% налогов вместо 12%, как думаете что они выберут?
Да, а поповоду оутсорса… у них в европе очень сильно развит аутсорс бухгалтерии. Потому как там прилично заморочек и все их помнить здоровья не хватит.
В общем концентрироваться надо на рельных проблемах. А не на детском лепете о том, что надо куда-то сходить для регистрации…
Надеюсь не прочтут. Потому что этот опыт, касательно РФ, уже несколько лет просто брехня.
Не все конечно идеально, местами совсем плохо. Но вот не люблю откровенную брехню с перегибами…
Регался несколько лет назад.
Открытие:
Зашел на сайт, зарегался. Приехал в контору, в удобное для меня время, очередей никаких нет, показал паспорт, получил цифровую подпись и все.
Обязательства:
Бумажка это просто брехня. Никто ничего не выдает. 40000 не было никогда, это тоже брехня.
Отчитываться раз в год. Если не знаешь, не надо вводить людей в заблуждение своим «опытом».
Неподготовленному человеку все кажется трудным. У ИП всегда была отчетность в виде пары простых бумажек. Всегда была куча контор которая за копейки ее сделает. А сейчас многие банки даже предоставляют такую услугу.
>И уже из этого сравнения понятно, почему в РФ ИП и предпринимателей мало
Из этого передергивания, на самом деле, вообще нифга не понятно. Потому что проблема вовсе не в отчености, которую якобы неподготовленные люди боятся. Если бы у qde5n1k был реальный опыт ведения бизнеса в РФ, он бы это знал и понимал. А так очень похоже на обычный наброс недалекого человека. (извините за резкие выражения)
Ну вот как всегда. Почему не рассматривали другие языки для JVM?
Думаю, если бы взяли Clojure, количество строк и файлов и времени потрачено было бы еще меньше…
И точно так же можно было писать и фронт и бек на одном языке используя «мощь фулстека».
А сам по себе язык гораздо более технологичен, что безусловно скажется в итоге.
К тому же замеры производительности вызывают вопросы. На сколько корретно было это сравнение?
Оптимально ли было написано JVM приложение?
Что-то я очень сомневаюсь, что JVM настолько проигрывает NodeJS в производительности.
Потому собственно и топчемся, что нет внятного ответа на вопрос, зачем нужна такая навороченная типизация обмена сообщениями. Есть только очень абстрактное «потому что с типами лучше чем без них». Но речь ведь идет не о сферическом коне «статика vs динамика», а конкретно об интерфейсе для сообщений в акторах. И вот тут нет внятного объяснения что вылечит весь этот геморрой с такой жесткой типизацией интерфейсов.
Потому что на практике все описываемые проблемы вообще никак не ощущаются. Все примеры проблем, здесь в каментах, очень абстрактные и ничего толком не объясняют.
Все что я пока вижу, это попытку сделать из акторов обычный ООП с интерфейсами. И я не понимаю зачем это? ООП уже есть, зачем из акторов делать ООП мне не понятно…
Да, безусловно компилятор на себя возмет часть работы. Но эта часть в общем-то небольшая.
И фишка в том, что объем тестирования это не уменьшит, т.к. все равно надо написать тесты на все сообщения получаемые актором. И в процессе этого дела я не представляю как можно пропустить что актор не обрабатывает нужное сообщение…
Я смотрю с чисто практической стороны.
Хорошо когда компилятор может проверить, что в акторе сть обработчик нужного типа сообщения и соответсвенно дать гарантию, что именно этот тип может обработаться актором. Соответсвенно при рефакторинге он может указать на ошибку этого типа.
Другой вопрос, что на практике я даже теоретически не вижу, где это мне поможет. По одной простой причине. На обработку сообщений всегда пишется тест. Не для проверки типа, а для того что бы быть уверенным — актор корректно обработает сообщение. На этом этапе сразу отсекаются ошибки типов сообщений. При чем AkkaTest позволяет как раз описать поведение акторов, т.е. например актор обязан получить сообщение обработать его.
Не просто может, а именно обязан получить.
Но если не писать тестов вообще, то конечно типы помогут в таких случаях.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал. Таких надо ссаными тряпками гнать из професии.
Умолчу уже о том, что писать систему (на важно на чем) без тестов это жесть и само по себе существенно снижает ценность типизации вызовов. Т.к. типизация сообщений (применительно именно к Акка конечно же) сама по себе может проверить лишь малую часть кода.
И она не стоит того, чтобы городить огород.
P.S. Прошу обратить внимание, что речь не про сферического коня «статика vs динамика». А конкретно про типизацию акторов в Акка. Потому что во всех других частях Акка с типами все отлично.
Еще раз повторю вопрос.
Как вы, с помощью статической типизации, интерфейсов и прочего сможете гарантировать, что актор послал сообщение тем, кому должен?
Вот по пунктам распишие.
Если конкретизировать, то выражение «Гарнтия того что актор послал сообщение тому кому должен», означает, что вы в компайл тайме проверили, что какое-то сообщение актор отправил и какое-то сообщение актор получил. Для этого компилятору необходимо знание о том, что вообще должно происходить.
Другими словами, компилятор должен знать, что если мы создали метод, то кто-то где-то должен его обязательно его «дернуть». Как вы себе представляете это решение использую статическую типизацию?
Статическая типизация поможет только провериь, что мы передаем конкретный тип сообщения, и этот тип может обработаться актором. Но никак не может гарантировать что мы вообще посылаем такое сообщение и уж тем более не может гарантировать доставку сообщений.
У вас все смешалось в кучу.
Если говорить про акторы в целом, то т.к. под акторам подразумевается распределенная система, говорят что нет гарантий доставки. Но не потому что это акторы, а потому что система распределенная. Это обычная для новичков подмена понятий. На классическом ООП с Future то же нет гарантий доставки.
В общем случае вообще нет гарантии доставки сообщений в распределенной среде. Это в принципе не решаемая сейчас проблема. Ее только можно минимизировать разными способами. Гуглите «Задача двух генералов».
В рамках же одного приложения, гарантия доставки сообщения ровно такая же как и при вызове обычного метода.
Т.е. единственная проблема акторов в Акка, это не забыть сделать обработку сообщения в акторе.
Но эту ошибку точно так же легко допустить в любом коде и без акторов, забыв дернуть нужный метод.
P.S. Интерфейс с типами, в который обернут актор не гарантирует, что сообщение именно будет отправлено. А только то, что оно может быть отправлено именно с таким типом.
Программист легко может забыть его отправить при рефакторинге)
Думал, хоть что-то из практики применения будет.
А тут очередная копипаста документации.
Ну как ремень безопасности в машине. Вожу очень аккуратно, но я не один на дороге.
Сколько уже было историй, когда были проблемы с вполне легитимными сайтами.
И ломают, и забывают домен продлить и он уходит… и т.д. и т.п.
Я писал, что не все, а подавляющее большинство.
Компания JetBrains, это обычная коммеческая, зарубежная компания.
Люди (ну или подавляющее большинство из них, если быть занудой), которые разрабатывают ее продукты, это и есть «просто наемный работник».
И надувать щеки, по поводу того, что кто-то из них Русский или нет, выглядит как дешевый пиар…
Просто судя по всему, эта аннтация перекрывает большинство кейсов применения.
Почитайте к чему я напиисал свой камент… а потом уже создавайте специальную олимпиаду и занимайте в ней призовое место…
Вы серьезно?
«JetBrains. Дата основания: 2000 г., Чехия».
А если вы так радуетесь, за то, что основатели из России, то где дифирамбы гуглу по каждому поводу?
Ведь «Сергей Михайлович Брин родился в Москве»…
Такие дела…
Поэтому и расшифровщика не будет.
Все пункты, которые вы перечислили в первоначальном каменте, по сути не соответствуют действительности.
Ну и сейчас все равно передергивания же идут и введения в заблуждение людей…
> «что в РФ по дефолту ты сразу всем должен, и хорошие деньги»
1. Кому «всем»? Что за чушь. Только налоговой и только 1 фиксированный налог.
2. Этот налог можно вычитать из прибыли. Вычитать полностью.
Для вас 27т.р./год это действительно «хорошие» деньги? Серьезно?
3. Чтобы не платить этот фиксированный налог вообще, надо зарабатывать около 30т.р./мес.
Что далеко не фантастические деньги. И помешает по сути только тем, кто либо открыл ИП «по приколу» и не ведет деятельность. Либо тем, кто совсем по мелочи безнесом занимался. Опять же, зарабатывая меньше этого порога (30т.р.) всего лишь фиксированный налог не полностью вычитается, но все равно вычитается.
>«До 6% не спишешь, но до 15-20% понизить можно, с грамотным налоговым консультантом.»
Ну да, ну да, а все грамотные консультанты, как известно, работают бесплатно.
Ну и сам посыл «Лучше платить 15-20% налогов в ФРГ, чем 6% в РФ» конечно гениальная.
Как вы с таким подходом к финансам бизнесом-то занимаетесь?
Люди, вы чего? Какие гении, продакшен код, преждевременная оптимизация и вот это вот все?
Ну блин никто же не пишет такой продакшен код, это же очевидно рассказ про другое…
Меня собственно зацепила откровенная брехня qde5n1k. Просто не надо передергивать и сгущать краски.
У меня нет иллюзий по поводу бизнеса в РФ. Многое видел собственными глазами еще с 90-х. И мне грустно наблюдать за тем, что происходит в глобальном плане с малым бизнесом.
Но повторю свое мнение. Если нечего сказать по существу и весь опыт из пальца высосан, то лучше помолчать. Чем вводить других людей в заблуждение…
Если уж говорить «справедливости ради», то надо упомянуть, что ИП в европе (там где живут родственники) платит поряджка 12-15% налогов. И они с завистью смотрят на мои 6%.
Да, у них вариантов вычетов больше. Но они не уменьшают налоги в 2 раза.
Если Европейцам предложить самостоятельно сходить с бумажками для регистрации ИП и потратить день на это. Но в замен дать 6% налогов вместо 12%, как думаете что они выберут?
Да, а поповоду оутсорса… у них в европе очень сильно развит аутсорс бухгалтерии. Потому как там прилично заморочек и все их помнить здоровья не хватит.
В общем концентрироваться надо на рельных проблемах. А не на детском лепете о том, что надо куда-то сходить для регистрации…
Не все конечно идеально, местами совсем плохо. Но вот не люблю откровенную брехню с перегибами…
Регался несколько лет назад.
Открытие:
Зашел на сайт, зарегался. Приехал в контору, в удобное для меня время, очередей никаких нет, показал паспорт, получил цифровую подпись и все.
Обязательства:
Бумажка это просто брехня. Никто ничего не выдает. 40000 не было никогда, это тоже брехня.
Отчитываться раз в год. Если не знаешь, не надо вводить людей в заблуждение своим «опытом».
Неподготовленному человеку все кажется трудным. У ИП всегда была отчетность в виде пары простых бумажек. Всегда была куча контор которая за копейки ее сделает. А сейчас многие банки даже предоставляют такую услугу.
>И уже из этого сравнения понятно, почему в РФ ИП и предпринимателей мало
Из этого передергивания, на самом деле, вообще нифга не понятно. Потому что проблема вовсе не в отчености, которую якобы неподготовленные люди боятся. Если бы у qde5n1k был реальный опыт ведения бизнеса в РФ, он бы это знал и понимал. А так очень похоже на обычный наброс недалекого человека. (извините за резкие выражения)
Думаю, если бы взяли Clojure, количество строк и файлов и времени потрачено было бы еще меньше…
И точно так же можно было писать и фронт и бек на одном языке используя «мощь фулстека».
А сам по себе язык гораздо более технологичен, что безусловно скажется в итоге.
К тому же замеры производительности вызывают вопросы. На сколько корретно было это сравнение?
Оптимально ли было написано JVM приложение?
Что-то я очень сомневаюсь, что JVM настолько проигрывает NodeJS в производительности.
Потому собственно и топчемся, что нет внятного ответа на вопрос, зачем нужна такая навороченная типизация обмена сообщениями. Есть только очень абстрактное «потому что с типами лучше чем без них». Но речь ведь идет не о сферическом коне «статика vs динамика», а конкретно об интерфейсе для сообщений в акторах. И вот тут нет внятного объяснения что вылечит весь этот геморрой с такой жесткой типизацией интерфейсов.
Потому что на практике все описываемые проблемы вообще никак не ощущаются. Все примеры проблем, здесь в каментах, очень абстрактные и ничего толком не объясняют.
Все что я пока вижу, это попытку сделать из акторов обычный ООП с интерфейсами. И я не понимаю зачем это? ООП уже есть, зачем из акторов делать ООП мне не понятно…
И фишка в том, что объем тестирования это не уменьшит, т.к. все равно надо написать тесты на все сообщения получаемые актором. И в процессе этого дела я не представляю как можно пропустить что актор не обрабатывает нужное сообщение…
Хорошо когда компилятор может проверить, что в акторе сть обработчик нужного типа сообщения и соответсвенно дать гарантию, что именно этот тип может обработаться актором. Соответсвенно при рефакторинге он может указать на ошибку этого типа.
Другой вопрос, что на практике я даже теоретически не вижу, где это мне поможет. По одной простой причине. На обработку сообщений всегда пишется тест. Не для проверки типа, а для того что бы быть уверенным — актор корректно обработает сообщение. На этом этапе сразу отсекаются ошибки типов сообщений. При чем AkkaTest позволяет как раз описать поведение акторов, т.е. например актор обязан получить сообщение обработать его.
Не просто может, а именно обязан получить.
Но если не писать тестов вообще, то конечно типы помогут в таких случаях.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал. Таких надо ссаными тряпками гнать из професии.
Умолчу уже о том, что писать систему (на важно на чем) без тестов это жесть и само по себе существенно снижает ценность типизации вызовов. Т.к. типизация сообщений (применительно именно к Акка конечно же) сама по себе может проверить лишь малую часть кода.
И она не стоит того, чтобы городить огород.
P.S. Прошу обратить внимание, что речь не про сферического коня «статика vs динамика». А конкретно про типизацию акторов в Акка. Потому что во всех других частях Акка с типами все отлично.
Как вы, с помощью статической типизации, интерфейсов и прочего сможете гарантировать, что актор послал сообщение тем, кому должен?
Вот по пунктам распишие.
Если конкретизировать, то выражение «Гарнтия того что актор послал сообщение тому кому должен», означает, что вы в компайл тайме проверили, что какое-то сообщение актор отправил и какое-то сообщение актор получил. Для этого компилятору необходимо знание о том, что вообще должно происходить.
Другими словами, компилятор должен знать, что если мы создали метод, то кто-то где-то должен его обязательно его «дернуть». Как вы себе представляете это решение использую статическую типизацию?
Статическая типизация поможет только провериь, что мы передаем конкретный тип сообщения, и этот тип может обработаться актором. Но никак не может гарантировать что мы вообще посылаем такое сообщение и уж тем более не может гарантировать доставку сообщений.
У вас все смешалось в кучу.
Если говорить про акторы в целом, то т.к. под акторам подразумевается распределенная система, говорят что нет гарантий доставки. Но не потому что это акторы, а потому что система распределенная. Это обычная для новичков подмена понятий. На классическом ООП с Future то же нет гарантий доставки.
В общем случае вообще нет гарантии доставки сообщений в распределенной среде. Это в принципе не решаемая сейчас проблема. Ее только можно минимизировать разными способами. Гуглите «Задача двух генералов».
В рамках же одного приложения, гарантия доставки сообщения ровно такая же как и при вызове обычного метода.
Т.е. единственная проблема акторов в Акка, это не забыть сделать обработку сообщения в акторе.
Но эту ошибку точно так же легко допустить в любом коде и без акторов, забыв дернуть нужный метод.
P.S. Интерфейс с типами, в который обернут актор не гарантирует, что сообщение именно будет отправлено. А только то, что оно может быть отправлено именно с таким типом.
Программист легко может забыть его отправить при рефакторинге)