Цікаво було б його порівняти з sbt2, особливо для Java проектів. Обіцяли теж неабияку швидкість, натхненну Bazel

Носяться Хаскелісти, через 5 років воно з’являється в Скалі, а через 10 в Джаві) Як і з тим само property-based тестуванням, про яке згадується на рівні В.
QA інженерний підхід, формальна верифікація академічна. Якщо є час і гроші, краще і те і інше

Але перш ніж щось критикувати, треба з’ясувати, що саме ми критикуємо та чому. Так створюються об’єктивні професійні погляди.

Two minutes later

Якщо ви не використовуєте успадкування, ви не використовуєте об’єктноорієнтоване програмування. Ви криворукий лайнокодер, що пише процедурний код. Мені за вас соромно.

О — об’єктивність.

Чомусь менша кількість фіч у Go одразу переходить в

Чистий та зрозумілий код

На практиці ж, це швидше вивчення мови, і довший код. Код буде скоріш «знайомим», а не простим. (Посилання на Simple made easy)

Половина з вказаного в Скалі є на рівні бібліотек. Інша половина з коробки

Ще й як має: простіші тести, легший рефакторінг, ідеальний метч з DDD

Монади можна пояснювати і абсолютно інженерно, прямо з коду. Хороший приклад бачив ось тут youtube.com/watch?v=...​Rc3aU?si=ugUIwZSJposRzmi3

Дуже гарна перша частина статті, прекрасні принципи. Мені як скалісту сподобалось.

А от по функторам і монадам дарма не згадали жодного слова про закони. Монада — не контейнер і не коробка. Таке пояснення погіршує ситуацію з розумінням ФП

++

State теж може бути монадою 🤷‍♂️ але ж тому ми і пишемо на фп, щоб від нього спекатись. Дехто полюбляє для стейту акторів використовувати. А комусь ІО монади з головою. Дарма ви так

Поза імперативно-ООП табором теж платять гроші :)

для написання юніт-тесту добре б її ізолювати

Чи правильно розумію, що це важливо тільки для випадку JDK проксі? Sub-classing та inline прожує відсутність інтерфейсу?

По джаві, згоджусь, але я не про це.

Не з’являлись би нові мови, і ринок поступово не змінювався. І як винайшли кобол, так би га ньому всі і писали. Там доречі нещодавно нова версія вийшла

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

З такою логікою ми б всі зараз писали на Коболі)

Java популярна не тому що така прекрасна мова, а тому що в неї влили величезну кількість грошей. І якщо вже чесно, то більшість ліб/фреймів з’явилося не від кращого життя, а більшість все ж портували га Джаву, а не навпаки. Якщо цікаво, можу аргументувати

Світочі Скали як раз говорять, що все добре. Хайп пройшов, ріст маленький, але стабільний і кожен рік. Джаву і Пітон навряд вдасться наздогнати будь-кому. Хіба що Раст займе нішу С++, десь у майбутньому, не точно.

Мені три вакансії Скали на Київ не подобається. Але дуже подобається компанія, в котрій працюю, і дуже не подобалось писати на Спрінг+Хібернейт. Бай зе вей, в нас наймають без досвіду Скали, аби той досвід був. Одиничні компанії готові піти на таке.

«Шоб шо» — оце дуже класне питання. Якщо розглядати програмування чисто як заробіток, з 9 до 5, то Скала точно не та мова. Це скорше для тих, хто шукає шляхи зробити свій код більш сек*юрним, кому подобається експерементувати, нові підходи в розробці, та й ФП вцілому. Треба визнати — не все спрацьовує як задумано. Акка, сбт — це перше що мені приходить в голову.
За усі інші мови, котрі йдуть цим шляхом, на жаль не платять, або не в наших широтах. Комерційні проекти на Хаскелі та Еліксирі існують. Є варіант писати вдень на Java за гроші, а по ночах на OCaml, такого багато на твічі. Закінчується зазвичай з появою сім*ї.

Ви знову повторили про «наркоманський синтаксис») Не імпортуйте cats. Це проблема між стільцем і клавіатурою. Команда заімпортувала — хай пише в описі вакансії, або вчить ньюкамера. Мова дозволяє робити страшні речі, with great power comes great responsibility :)
Найбільш слизькі місця виправили в Скала 3. Міграція простіша ніж в Пітоні, і частіше не про Скалу як таку.
Хороші штуки зі Скали тащать в інші мови, бо вони працюють, класні і зручні. Саме Скала показала, що це можливо зробити на JVM. Для Java ком*юніті ми лабораторія, котра перевіряє гіпотези. Для компаній — можливість об*єднати людей, котрим цікаво. А код за нас скоро і так буде писати ChatGPТ, по нашому опису і з нашим рев*ю :)

Я пишу цю довгу відповідь, оскільки бачу як вам було боляче. Зазвичай, такі яскраві описи швидко поширюються, а дописи кому подобається — ігнорують. Мені буде прикро, якщо ваш коментар відверне новачка, котрому могло сподобатись, але прочитавши, не наважиться навіть спробувати.

На яких ще мовах ви програмували, з чим порівнюєте?

Окрім Scala популярність набирають:
— F# якщо пишите на .Net
— OCaml захопив розум людей в твіттері
— Elixir для тих хто писав на Ruby

Питання кількості робочих місць

Не згоден з вами:

> кожен перший мамкін функціональщік вважає своїм священним обовʼязком присунути в код макросом

В лібах має своє місце. Зазвичай вони малі, і їх можна зрозуміти. Але як часто ви заходити в код Хібернейту, Джанго чи Ктору? Якщо бібліотека написана легко для використання, і є притомний мануал — рідко. Так само можна сказати про рефлексію і Спрінг.
У Rust println макросом реалізований. І шо?

> якщо є більш прагматичні і практичні мови з нижчим порогом входу?

Постійно повторюю — як мова Scala простіше за Java.

> спробувати комерційно тєрєбонькати монади

На Скалі спокійно можна писати без знання що таке монада. Java, Rust, Kotlin — йдуть по шляху Scala, і додають фічі які в ній є. Ktor явно надихався Akka-Http. В Java з*являється паттерн матчінг і рекорди.

> пасани я одною строчкою зробив

Мені прикро, що вам попадалися такі люди на проектах. Код на Скалі рідко коротше коду на Котліні або Пітоні, а в більшості випадків такий самий. Я за 6 років Скали бачив таке тільки один раз.

> обʼєктами компаньйонами

Інша назва static. В Kotlin так само було.

У Скали є проблеми, але вони не на стільки жаливі, як ви описали.
Скільки часу програмували на Скалі? І у яких роках?

Зазвичай такі коментарі пишуть ті, хто жодного разу не пробував вивчити Скалу/Котлін