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

Golang

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

гошку

го ужасен для приложений с тяжелой доменной моделью

и развесистой бизнес-логикой

бедный язык

Зато сервак из коробки

го ужасен для приложений с тяжелой доменной моделью

да. bpm-движки в го не завезли и наврядли завезут.

да. bpm-движки в го не завезли и наврядли завезут.

да ладно

там даже дженериков нет

люди код копипастят

не менеджмента зависимостей

и куча косяков

зато не джава!

ну если MSA, то ничто не мешает писать маленький микросервисы на го, а когда нужна сложная БЛ, то кидаем сообщение в очередь, откуда ее читает bpm на явке и кладет ответ туда же.

но вроде как го и не создавался убийцей джавы

Зато быстрый

ну если MSA, то ничто не мешает писать маленький микросервисы на го, а когда нужна сложная БЛ, то кидаем сообщение в очередь, откуда ее читает bpm на явке и кладет ответ туда же.

например

но вроде как го и не создавался убийцей джавы

именно этим он и создавался

именно этим он и создавался

и ты считаешь, создатели свою цель достигли?

и ты считаешь, создатели свою цель достигли?

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

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

боже упаси

"blue-collar language" — вот эта ниша

люди код копипастят

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

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

он тогда частино поетряет свою нишу, он привлекает маскимальной простотой на грани примтивизма, если там будет свой аналог всеобъемлющего спринга, то вся его kiss идеология пойдёт лесом

он тогда частино поетряет свою нишу, он привлекает маскимальной простотой на грани примтивизма, если там будет свой аналог всеобъемлющего спринга, то вся его kiss идеология пойдёт лесом

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

он тогда частино поетряет свою нишу, он привлекает маскимальной простотой на грани примтивизма, если там будет свой аналог всеобъемлющего спринга, то вся его kiss идеология пойдёт лесом

ну я видел попытки притащить функциональщну в го, выглядело адовой хренью. аналогично выглядели попытки притащить хотя бы DI

посмотрим что в 2.0 будет на уровне языка. и какая концепция победит

ну я видел попытки притащить функциональщну в го, выглядело адовой хренью. аналогично выглядели попытки притащить хотя бы DI

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

@fundamentalparticle Опять что-то в ЕАПе поменяли. 3 дня ноут не перезагружал. Перезагрузил - внезапно шрифты на пол экрана 24' моника. В редакторе я ещё их назад вернул, а вот как это сделать в project view ваще без понятия

Может ты в курсе как это сделать?

Братишки, я вам тут покушать принес! https://jug.ru/2018/06/scala-digest-2/

scala, meh

@fundamentalparticle Опять что-то в ЕАПе поменяли. 3 дня ноут не перезагружал. Перезагрузил - внезапно шрифты на пол экрана 24' моника. В редакторе я ещё их назад вернул, а вот как это сделать в project view ваще без понятия

не в курсе. но только что сам обновился. посмотрим что там..

Там ещё завезли врапинг окошек. Если открыть консоль и любую из боковых менюшек(project view/etc), то боковая менюшка будет от верха экрана до низа. А консолька будет от конца правого экрана до боковой менюшки

Хорошо сделали

што такое bpm движки

што такое bpm движки

энтерпрайзная херня

scala, meh

на скале же есть Кафка-апи, значит это нормальный язык! val clicksPerRegion: KTableS[String, Long] = userClicksStream // Join the stream against the table. .leftJoin(userRegionsTable, (clicks: Long, region: String) => (if (region == null) "UNKNOWN" else region, clicks)) // Change the stream from <user> -> <region, clicks> to <region> -> <clicks> .map((_, regionWithClicks) => regionWithClicks) // Compute the total per region by summing the individual click counts per region. .groupByKey .reduce(_ + _) // Write the (continuously updating) results to the output topic. clicksPerRegion.toStream.to(outputTopic)

што такое bpm движки

Это стандарт по описанию бизнес процессов в xml, а ты можешь потом к шагам прицепить коллбеки.

на скале же есть Кафка-апи, значит это нормальный язык! val clicksPerRegion: KTableS[String, Long] = userClicksStream // Join the stream against the table. .leftJoin(userRegionsTable, (clicks: Long, region: String) => (if (region == null) "UNKNOWN" else region, clicks)) // Change the stream from <user> -> <region, clicks> to <region> -> <clicks> .map((_, regionWithClicks) => regionWithClicks) // Compute the total per region by summing the individual click counts per region. .groupByKey .reduce(_ + _) // Write the (continuously updating) results to the output topic. clicksPerRegion.toStream.to(outputTopic)

Ничего это не значит

Почему java community негативно относится к скале?

Такое ощущение что скала отбирает хлеб у некоторой части и мешает им жить :)

Почему java community негативно относится к скале?

Ненавидят Одерского и мстят ему за то, что он придумав такие кривые генерики (для Java).

Ненавидят Одерского и мстят ему за то, что он придумав такие кривые генерики (для Java).

Это надо просто отпустить и жить дальше.

Джависты и скалисты братья навеки! Два народа. Два языка. Одна jvm!

Почему java community негативно относится к скале?

Для любой технологии найдётся часть java community, которая относится к ней негативно

Почему java community негативно относится к скале?

С чего бы... Самое негативное у меня, это только шутки над ПоХаПешниками. Вот как скалисты ненавидят друг друга это я видел. Один за ООП другой за функционал.

Почему java community негативно относится к скале?

лул) то что я видел - максимум легкий троллинг, на тему ненужности языка

обычно скалисты заходят и начинают джавку обсирать

Почему java community негативно относится к скале?

не очень умные

обычно скалисты заходят и начинают джавку обсирать

это вот точно мех

не очень умные

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

Ненавидят Одерского и мстят ему за то, что он придумав такие кривые генерики (для Java).

Но он же как раз придумал reified генерики, только их не приняли.

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

нет, посыл был в другом, но ты вписался

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

шипилев недавно кстати делал реф на одерского в опенждк кодбазу

@avkomarov остановись, опомнись.

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

вот реф: http://hg.openjdk.java.net/jdk/jdk/file/6f548c41a4fc/test/langtools/tools/javac/generics/odersky/

Почему java community негативно относится к скале?

это не так

обычно скалисты заходят и начинают джавку обсирать

а вот это у некоторых пациентов в особой форме проявляется

это не так

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

а тут предъявы на все коммьюнити

Почему java community негативно относится к скале?

Неосиляторы

А вообще популярность Го и его простота немного настораживает. Наплодят программистов, и все... Будем работать за еду.

А вообще популярность Го и его простота немного настораживает. Наплодят программистов, и все... Будем работать за еду.

Перносыщенность рынка программистами может означать только падение самого рынка. В этом случае Ж настанет по-любому. Так что само по себе большое количество программистов никому плохо не сделает. А в случае здоровой экономики, наоборот, будет очень кстати

Ребят есть клиент серверное приложение. Клиент отправляет запрос на сервер. Сервер формирует файл и отправляет его клиенту. Как проверять на сервере что файл сформировался?

Ребят есть клиент серверное приложение. Клиент отправляет запрос на сервер. Сервер формирует файл и отправляет его клиенту. Как проверять на сервере что файл сформировался?

Проверять на чтение например

Кто знает как считать текст из страницы сайта? Именно текст, а не html-разметка.

Кто знает как считать текст из страницы сайта? Именно текст, а не html-разметка.

получить контент и распарсить jsoupом

Кто знает как считать текст из страницы сайта? Именно текст, а не html-разметка.

распарсить html регуляркой?

распарсить html регуляркой?

https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

https://pastebin.com/vnJMtJXn подскажите, как в классе GuessNumber я в этом классе реализую логику не могу понять почему у меня не повторяется когда никто не угадывает числа

лул) то что я видел - максимум легкий троллинг, на тему ненужности языка

А скала разве нужна? Какой же это троллинг

Есть SE проект - плагин для одного приложения. В нем есть много классов-менеджеров: CommandManager, EntityManager, RestoreManager и так далее. Все эти менеджеры отвечают за разные вещи и могут использоваться в различных частях программы - как в других менеджерах, так и в остальных классах, которые от них зависимы. Вообще, в системе должно существовать по одному инстансу такого менеджера. Большинство менеджеров зависят друг от друга, также многие из них зависят от инстанса плагина - PluginInstance. От остальных классов системы они не зависят. Вопрос в том, как грамотно организовать доступ к объектам-менеджерам . Мои варианты: 1. Самое первое, что приходит в голову - синглтоны. Для каждого менеждера делаем статический геттер и обращаемся к нему откуда угодно. Правда, ленивая инициализация подойдет не для всех менеджеров - некоторые нужно явно загрузить при старте и запустить выполнение некоторых задач, но это уже не так страшно. В общем, если полностью перевести систему на синглтоны: сделать ими и менеджер, и сам плагин, то проблема в итоге разрешается. Вопрос в том, насколько это грамотное решение, когда весь проект будет пестрить getInstance-ми. 2. Dependency Injection. Передавать классам через конструкторы менеджеров, которые им нужны. Здесь проблема в том, что некоторые классы порождаются не там, где создаются инстансы менеджеров, поэтому в отдельных случаях объекты менеджеров придется "тащить" через 2-3 класса, и такая структура будет очень громоздкой. Как вариант - инжектить поля рефлексивно, но в интернете пишут о том, что это ужасная практика (хотя, насколько я понимаю, в том же спринге она вполне себе применяется). 3. Создать класс, который просто будет держать ссылки на все существующие в системе менеджеры. Назвать как-нибудь вроде Core, System. В нем будут методы getCommandManager(), getEntityManager(), getRestoreManager() и т.д. Теперь вместо N объектов менеджеров нам достаточно протащить во все классы ссылку на System или вовсе сделать System синглтоном. Впрочем, здесь уже неважно, поскольку у нас в итоге получается одна ссылка вместо 10, и организовать к ней доступ уже явно не проблема. Итак, как будет правильней организовать такую систему зависимостей? Возможно, есть еще варианты?

https://pastebin.com/vnJMtJXn подскажите, как в классе GuessNumber я в этом классе реализую логику не могу понять почему у меня не повторяется когда никто не угадывает числа

Так ты в бесконечный цикл загони (а лучше в поток с циклом), у тебя сейчас логика выполняет один проход и всё

Есть SE проект - плагин для одного приложения. В нем есть много классов-менеджеров: CommandManager, EntityManager, RestoreManager и так далее. Все эти менеджеры отвечают за разные вещи и могут использоваться в различных частях программы - как в других менеджерах, так и в остальных классах, которые от них зависимы. Вообще, в системе должно существовать по одному инстансу такого менеджера. Большинство менеджеров зависят друг от друга, также многие из них зависят от инстанса плагина - PluginInstance. От остальных классов системы они не зависят. Вопрос в том, как грамотно организовать доступ к объектам-менеджерам . Мои варианты: 1. Самое первое, что приходит в голову - синглтоны. Для каждого менеждера делаем статический геттер и обращаемся к нему откуда угодно. Правда, ленивая инициализация подойдет не для всех менеджеров - некоторые нужно явно загрузить при старте и запустить выполнение некоторых задач, но это уже не так страшно. В общем, если полностью перевести систему на синглтоны: сделать ими и менеджер, и сам плагин, то проблема в итоге разрешается. Вопрос в том, насколько это грамотное решение, когда весь проект будет пестрить getInstance-ми. 2. Dependency Injection. Передавать классам через конструкторы менеджеров, которые им нужны. Здесь проблема в том, что некоторые классы порождаются не там, где создаются инстансы менеджеров, поэтому в отдельных случаях объекты менеджеров придется "тащить" через 2-3 класса, и такая структура будет очень громоздкой. Как вариант - инжектить поля рефлексивно, но в интернете пишут о том, что это ужасная практика (хотя, насколько я понимаю, в том же спринге она вполне себе применяется). 3. Создать класс, который просто будет держать ссылки на все существующие в системе менеджеры. Назвать как-нибудь вроде Core, System. В нем будут методы getCommandManager(), getEntityManager(), getRestoreManager() и т.д. Теперь вместо N объектов менеджеров нам достаточно протащить во все классы ссылку на System или вовсе сделать System синглтоном. Впрочем, здесь уже неважно, поскольку у нас в итоге получается одна ссылка вместо 10, и организовать к ней доступ уже явно не проблема. Итак, как будет правильней организовать такую систему зависимостей? Возможно, есть еще варианты?

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

Так ты в бесконечный цикл загони (а лучше в поток с циклом), у тебя сейчас логика выполняет один проход и всё

Так почему я наоборот сделал в бесконечный цикл , я понял цикл while так while(условие) если условие выполняется то выполняется ifы. Точно сейчас буду искать как делается бесконечный цикл

Так почему я наоборот сделал в бесконечный цикл , я понял цикл while так while(условие) если условие выполняется то выполняется ifы. Точно сейчас буду искать как делается бесконечный цикл

Вайл тру

так у меня так и написано

или сам метод ты имеешь ввиду в цикл?

А скала разве нужна? Какой же это троллинг

Толсто

или сам метод ты имеешь ввиду в цикл?

Сам метод попробуй. Сперва дебаггером пройдись, посмотри где проблема