тк это всё известно изначально, нечего прокидывать извне

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

насчет тестов. никто не знает как в scalatest сделать так, чтобы сравнение разных типов на всяких shouldEqual не в рантайме падало, а на компиляции?

где-то встречал === для scalatest, возможно что-то в сторону cats и Equals, не могу вспомнить, где именно

а вообще вот вроде http://www.scalatest.org/user_guide/using_matchers#checkingEqualityWithMatchers result should === (3) // can customize equality and enforce type constraints

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

на === надо посмотреть

https://youtrack.jetbrains.com/issue/IDEA-163208#comment=27-2418693

пилят ребята

спасибо

https://youtrack.jetbrains.com/issue/IDEA-163208#comment=27-2418693

идеальный экранчик чтобы писать туда типы)

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

и тут shapeles

показывать имплисит!

генерировать if(a!=nil)

генерировать if(a!=nil)

тебя опять гошник укусил

/toxic

/toxic

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

да, это и имел в виду

или тип выделенного выражения, который через cmd+W

/toxic

Вот сидишь такой, забил на чат, потом видишь тлгрм пишет последнее сообщение "/toxic" и уже не можешь не зайти

Вот сидишь такой, забил на чат, потом видишь тлгрм пишет последнее сообщение "/toxic" и уже не можешь не зайти

Это ли токсик

это кликбейт

и тут shapeles

и тут rust\futures

Вот сидишь такой, забил на чат, потом видишь тлгрм пишет последнее сообщение "/toxic" и уже не можешь не зайти

возьми себе никнейм @toxic

занято(

кстати русскоязычный канал

о скале?

KrivdaTheScala

Krivla

ну ты и токсик

Ребя а https://index.scala-lang.org/ открвыается у вас?

Ребя а https://index.scala-lang.org/ открвыается у вас?

неа

и тут rust\futures

Одна из моих Растоболей.

Ребят, подскажите, как поумней настроить CI и release management. Сейчас есть Travis, он что-то там тестирует-собирает, есть отдельные ветки для разных релизов, нужно ещё что-то для паблишинга придумать (джарники, докер etc.). Буду рад почитать о вашем опыте, ну либо статьи какие-нибудь.

блин, зачем я нажал на эту ссылку >_< С Докером можно через sbt-native-packager собирать и паблишить в регистри (хоть в свой, хоть docker hub)

https://www.youtube.com/watch?v=mT5U862_ydU

блин, зачем я нажал на эту ссылку >_< С Докером можно через sbt-native-packager собирать и паблишить в регистри (хоть в свой, хоть docker hub)

круто же, да)

не обязательно это видео, у фланта в целом хорошие есть

(случайно нажал)

блин, зачем я нажал на эту ссылку >_< С Докером можно через sbt-native-packager собирать и паблишить в регистри (хоть в свой, хоть docker hub)

Спасибо. Я им даже пользовался, вопрос был, скорее, про организацию и best practices. Сейчас более-менее представление есть уже.

куда уж лучше :)

https://scala.epfl.ch/minutes/2017/09/12/september-12-2017.html

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

слышьте, так расскажите мне - все ли тут юзают Future[Either] / DBIO[Either], или только говорят что это круто, а в проде хэндлят эксепшены в рековери?

гугли EitherT =)

да я знаю про eithert

вот говоришь гугли, а юзаешь ли ты сам?

да

не вижу смысла в Future[Either] если честно, Future итак имеет ошибку внутри

хотя если только Either чтот отличное от ошибки содержит

смысле есть

я про кейс где там ошибка слева

может быть не эксепшен, а что-то свое простое

именно

не пишу проблем написать Future.failed

ну вот типа пишут что сайд эффекты и все такое

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

если делать один общий тип - тогда на самом деле не особо то понятно - ведь реально можно сделать Future.failed там где надо

и будет куда проще

и код менее захламленный обертками EitherT

видимо никто не юзает, ибо поднимая этот вопрос - никто его не поддерживает)

trait Error

и все =)

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

а ну я еще не знаю, но наверное это тоже минус для разработки как минимум - когда теряется стэк трейс, не?

ну у нас есть разные подтипы

ну это не объясняет приемущества)

ну я и не вызывался объяснить приемущества

ну ладно

но вообще конечно фримонады

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

ну потому что удобно

вот мне интересно как там в тинькове делают

есть стандартные ошибки

внутри метода кидаются они

ну в левую ветку

удобно )

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

или там какие-то ошибки бизнес логики

С эксепшнами теряется referential transparency

да не фига не удобно и никто не знает как жить одновременно с исключениями и в прекрасном мире railway oriented programing

все это костыли и смирение

да не фига не удобно и никто не знает как жить одновременно с исключениями и в прекрасном мире railway oriented programing

let it crash

ну эксепшны финч ловит )

короче днище

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

@fly_style йо

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

там про обработку ошибок особо и нет ничего

идея то ловить их по возможности ещё при компиляции :)

недавно видел трюк как делать персонализированные сообщения про ошибки компиляции в идрисе кстати https://groups.google.com/forum/m/#!topic/idris-lang/Po1_a4dUzIU