PHP — народжений щоб померти :))

Тільки це жарт не про мову програмування в цілому, а про життєвий цикл обробки запиту :)

Список посилок в новому додатку значно гірше виглядає. В старому значно легше зорієнтуватись де яка посилка. А в новому просто купа тексту на купі.

Виділити активні посилки жирним текстом — це «геніальне рішення» ... це так щоб весь текст ще більше зліз.

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

Прибрати номер посилки зі списку ... може й не критично, але не звично.

Короч, таке враження, що дизайнер тут не працював... виглядає так, що розробники зробили список як best effort без дизайну ... і так і пішло в реліз.

----

Але в новому додатку є величезний плюс: можна вимкнути промо сповіщення.
А то цей спам вже добряче діставав.

Якщо чесно, я перестаю розуміти яку саме ідею ви намагаєтесь донести :)

ЛАМП — це стек, що зробив інтернет

І разом з тим ви питаєте чим таким критичним є Open Source.

Знову ж «маленька» чи «бідна»?

Коли невелика компанія намагається автоматизувати черговий склад, то це, напевно, і маленька і бідна. У вашій системі координат, малих розробників існувати не повинно? Є безліч компаній, які ледве справляються з оплатою зарплат і поточних витрат. Це можна сказати «бідні» компанії? Це погано, що вони існують?

не знаю сценарії коли розробники на цьому стеку реально дивились код СУБД чи патчив апач

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

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

Ну... цей світ не ідеальний. Не всі, навіть гарні ідеї, отримують підтримку.

Але гіпотетична відмова від відкритого коду до нічого доброго не призведе.

Open Source виріс з академічного середовища, де прийнято ділитися зі світом своїми наробками, цитувати один одного, доповнювати і продовжувати роботи інших. При цьому про гроші в цьому ланцюжку не йдеться. Не все навколо на цій планеті крутиться навколо грошей. Якщо компанія зробила продукт, заробила на ньому грошей, і виклала частину своїх наробок в світ — це круто. Компанія і грошей заробила і поділилась досвідом.

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

А те що, хтось колись щось виклав дуже цінне, і хтось інший зумів на цьому заробити ... ну ... це не зовсім так. Той хтось заробив не на самому продукті, а на його впровадженні. І його ціна — це ціна впровадження, а сам продукт — безкоштовний, яким його і автор зробив.
Ейншнейн теж наврядчи отримав девіденди від подальшого створення ядерної бомби.

Але не наводите як саме вони критичні для виживання чи розвитку ІТ.

Протягом дискусії наводились багато прикладів. Кожен з них може й не є чимось визначним, але все одразу має великий вплив. Open source рух дозволяє набагато легше «стати на плечі гігантів» і зробити свій крок.

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

Це якийсь ідеалізований світ у вас. Ваш баг може роками висіти в трекері комерційному там саме як і в open source, тільки в останньому ви можете взяти і самі виправити, а в першому — ні.

Згадайте win32 api ... скільки міфів і легенд про нього писали, скільки статей про те як «хакнути» те чи інше апі щоб добитися свого. Цілі книги про те «як це в дійсності працює». Скільки багів перетворили в фічі. І ніхто ніякої підтримки вам там не дасть, поки ви маленька рибка.

спробуйте закімтитити або якось повзаємодіяти з гуавою, гуава

Пробував, знаю .... я відносно часто пишу тіккети в різні репи з недоліками. З наболілого, такі речі як java modules ще досі в купі популярних ліб не працюють нормально, хоч і java 9 вже вийшла давно-давно. Тільки от справа в тому, що з комерційними лібами буде гірше. Тут ви можете, хоч форк зробити під себе.

Часто буває таке, що проект погано підтримується і не встигає з оновленнями якимось. В 90% випадків можна знайти форк з потрібними змінами: хтось зробив для себе і не проти щоб комусь то згодилось.

Та і ключове тут сам безкоштовність, а не «відкритість коду»

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

В інфраструктурі відкритого коду, саме доступ до коду є важливим, навіть якщо використання обмежується ліцензією.

Код для бібліотек — це перший рівень документації. В своєму досвіді купу разів доводилось дебажити саме наявні ліби більше ніж власний код.

Відкритий код дозволяє проводити аудит будь-яким зацікавленим особам ... чи то «бо треба» чи то «цікаво, а чого той бінарник виріс в два рази?»

Відкритий код — це прозорість: «наш софт робить саме те, що ми кажемо і нічого іншого: як хочете, ось код, робіть білд самі». Є навіть цілий рух в сторону reproducible builds.

Відкритий код спонукає авторів писати «гарно». Скажу з власного досвіду... багато речей, які ми робим в компанії нам не шкода викласти в публічний доступ ... але на поточний момент поки не викладаємо — трохи соромно — треба багато рефакторити.

Для багатьох, відкритий код — це історія аля «зробив для себе — поділився зі світом» + макретинговий бонус (аля «подивіться що ми вмієм»). Частково, так ми маєм той самий react, annoy, faiss, guava, grpc, і купу іншого добра.

Власне дотНет ...

Так, це гарний приклад. Він не єдиний. Були ще ті ж Borland Delphi і багато чого іншого. Там є/були платні ліби. Але так чи інакше то все теж обросло певним шаром open source від сніппетів на форумах до реп в github... просто в меншому масштабі.

На фронт-енді ...

Мені складно сказати про ЕкстДжС, оскільки з ним не знайомий. Але тут я б не сказав що open source був ключовим в розвитку фронта. Історія розвитку веба — це більше про історію розвитку браузерів... JQuery був популярний не із-за того що він крутий, а із-за того, що браузери були туповаті.

Доречі, тут важливий феномен firefox — тут open source стоїть на варті privacy.

що там по докеру і солярним зонам? :)

Тут мені складно коментувати, я не знайомий з solaris. Єдине що скажу, що докер — не така вже й відкрита екосистема. Але ідея дуже потужна. Якщо на Solaris це було раніше — вони круті. На win та на mac цього так і по нормальному не зробили.

це не моя цитата

Вибачте, не подивився на автора... то вище по дереву.

Все те саме... були б платні бібліотеки

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

лінукс вбив демпінгом купу класних систем

При цьому, побудував навколо себе розгалужену екосистему. Хай би на скільки круті були б ті системи класні, результат був би не краще ніж те, що зараз є під win чи macos. Ці, доречі, дуже навіть вижили.

Та й ... вбив класних систем ... хз ... індустрія зараз досить капіталізована. Грошей в ІТ достатньо. Кожен individual contributor є досить ефективним, оскільки має багато готових і доступних інструментів. Без відкритого коду, людей тут працювало б набагато більше, робили б вони набагато більше однакової роботи, при цьому досягали менше результату, платили б всім менше, індустрія розвивалася б повільніше.

просто подарунок людоїдським режимам

Ці режими без проблем користуються і сучасним дуже платним але дуже ломаним софтом.
Та й не ломаним теж ... та й не софтом теж. Подивіться як працюють санкції — вони працюють але набагато менш ефективно ніж нам хотілося б.

Приплітати сюди open source — таке собі ... це як на підручники з матана робити обмеження на експорт і забороняти виносити з бібліотеки.

Таке собі твердження.
Якщо ви програмуєте, спробуйте поставити собі питання: а що ви можете написати без open source бібліотек/інструментів?
Уявіть собі світ без linux, де є лише windows server :)

RxJavaPlugins.setErrorHandler()

Це обробник останньої надії — глобальне налаштування — і, як наслідок, антипаттерн. Тобто, його ставити і логувати — то необхідно. Але якусь логіку туди дописувати — то дуже «таке собі» рішення.

стабільність гнучкість та лаконічність pipeline-iв основна перевага RxJava.

В нас, напевно, дуже різний досвід ... з мого досвіду, воно НЕ стабільне, НЕ гнучке і НЕ лаконічне :)
Не стабільне — в тому сенсі, що легко попасти в OOM, легко зловити непотрібний unsubscribe при onError, якого «бути не могло».
Не гнучке та не лаконічне — для роботи в режимі promise — виключно лінійний workflow. Будь-яка нелінійна логіка, робить pipeline таким, що складно читати.

Я розумію, що оператори там круті, і, якщо робити pipeline подій, то оператори можуть «зробити магію» — і це виглядає лаконічно — тут згоден з вами. Але ж воно розвалиться на першому ж onError, який ви не чекаєте, а той самий retry розчистить всі буфери і викине дані і спрацює лише на частині pipeline-у. ... не хочу повторювати всі тези з статті :)

-----

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

Можливо, ви могли б поділитись своїм досвідом, коли це круто спрацювало? Можливо, у вас є свої підходи до особливостей, згаданих в статті?

Як раз керує ... Немає блокуючого виклику.

Знову ж, мова про ресурс у вигляді потоку. Я це не намагаюсь заперечити. Але стверджую, що kotlin coroutines з цим впорається значно краще. Саме в частині, що з корутинами логіка може бути нелінійною і код стає виглядати як «звичайний». Тобто ви пишете код, що дуже схожий на звичайний, а він при цьому скаче по різним pool-ам і чекає зовнішні «сигнали» в non-blocking режимі (але код виглядає так саме як і в blocking)

Kotlin не завжди підтримує останню JVM

Не зіштовхувався з цим, проте, якщо навіть в compile-time не використовуються останні фічі, то в runtime запускається на останній (як мінімум, проблем не пригадую з цим). Єдине що з котліном потрібно білд скрипти адаптовувати — що не зручно.

Т. Нуркевича

Проглянув цю книгу по діагоналі. Ви знаєте, дуже шкода, що я її не бачив тоді, коли сам з цим розбирався. Ця книга — мала б бути частиною документації :) Реально круто.

Зверніть увагу, я НЕ кажу, що проблемою є поріг входу. Поріг входу багато де високий. Я стверджую, по суті, дві тези:
— Rx архітектурно схильний до неочікуваної поведінки.
— Для будь-яких випадків, де корисним може бути Rx, вже є кращі альтерантиви.

переглядаючи реалізації операторів, я відкриваю для себе щось нове.

Розумію вас ... але кожен раз, коли доводилось це робити, виникала думка: «випилювати це все треба з цього проекту, а то буде біда» :)

легко реалізувати за допомогою Coroutines + Flows.

Якщо я вірно зрозумів, про що ви, то тут Rx дуже погано справлявся. Звісно, закинути задачу в scheduler — це не проблема. Але тут ми натягуєм «послідовне виконання коду» на Rx. А там, де послідовне виконання, дуже швидко треба обробити помилку, дописати if, а то і взагалі цикл — і тут Rx повністю капітулює перед Coroutines.

combineLatest + flatMap + replay + zip + debounce,

Оператори в Rx — прекрасні, хоч і не ідеальні :) Але, як на мене, лише з точки зору ідеї.

Rx дозволяє лаконічно реалізувати складну бізнес-логіку, таку як послідовність combineLatest + flatMap + replay + zip + debounce,

Якщо я вірно зрозумів, це можна віднести до класу «стабільних pipeline-ів» зі статті.
Могли б ви поділитись досвідом що ви робите з помилками? Адже все ж розвалюється при першій ж проблемі.

Дві речі яуі вирішує ця технологія.

Я не намагаюсь критикувати підхід. Схожі ідеї зараз багато де успішно використовуються. В статті критика лише конкретної реалізації.

1. Це підхід до ресурсів.
2. Це конкаренсі.

Не впевнений, що ви маєте на увазі у випадку ресурсів, адже RX ними не керує ... хіба за потоки мова, але про це ви написали другий пункт :)
В другому ж, ... якщо я вас вірно зрозумів ... то корутини в kotlin вирішують, практично, все, що тут можна зробити, ... навіть краще. Якщо масова обробка, то overhead самого rx буде суттєвий (бачив випадки, коли overhead ArrayBlockingQueue вже суттєвий).

Spring теж має — Reactor

Не користувався цим ... бачу, що в основі Reactive Streams — конденсована специфікація на основі ReactiveX. Скоріше за все, там успадковані ті ж граблі.

У Java світі, коли не було ні kotlin coroutine, ні project loom, цей Reactive Streams виглядав значно притомніше (адже альтернативи не було). Станом на сьгодні ж — то переускладнено все і не ефективне (ні по часу на розробку, ні по використанню ресурсів).

Доречі, про сам підхід ... в певному сенсі, Netty був зроблений на схожому (з натяжкою) підході, і працює там все просто казково. Вони почали ще раніше — з 2004го: про асинхронність (у вузькому сенсі) тоді ще мало хто чув (хіба, автори epool), а Netty вже використовували ці ідеї. Використали б вони RX (хоча його тоді ще не існувало) — нічого доброго не вийшло б.

Оператори — чудові — я їх перелік, інколи, використовую як «довідник ідей» :)
Реалізація — «таке».

Трохи дописаний код з документації:

import { fromEvent, auditTime } from 'rxjs';

const clicks = fromEvent(document, 'click');
const result = clicks.pipe(auditTime(1000));
result.subscribe((x) => {
  console.log(x);
  throw Error();
});

Якась сумнівна порада.

Скоріше всього, ця порада — то дуже особисте враження. Коли я переходив з Java/Android на Flutter — це був як ковток свіжого повітря: перестаєш думати за життєвий цикл Activity, про Fragment забуваєш як про сутність, корутини інтегровані з коробки в gui thread — не треба винаходити «свою» асинхронщину, та й gui стає єдиним signle thread середовищем — як і має бути ... схопити race практично неможливо, Null Safety — окрема плюшка, тощо.

Єдине, що якщо потрібно, дійсно, робити якийсь background compute — то трохи складніше ... але якщо хочеться, це можна і на Java написати — інтегрується досить просто ... єдине, що під iOS теж доведеться це писати на Swift.

В контексті статті ж ... думка була в тому, що RX там впроваджувати не варто. Flutter — це одна з альтернатив. Якщо щось менш кардинальне, то як в сусідньому коментарі згадували, що Kotlin з корутинами — теж гуд.

використовувати RX для обробки натискань на кнопку у 2023 це нездорова історія.

Rx, взагалі, то нездорова історія ))

Згоден з вами, mvvm + coroutines — це гарний підхід. По великому рахунку, той самий Flutter на цьому побудований. Та і React теж. Здавалося б ... наче близнюки фреймворки, але відчуваються вони якось зовсім по різному, наче спільного й нічого немає.

Щодо Jetpack Compose ... я на нього не дивився, але підхід, бачу, схожий. Відносно нова штука ... я так зрозумів 2021 появились перші версії. Flutter — теж новий відносно, але появився десь 2018 року.

Завжди притримувався думки, що поки є шанс, потрібно отримувати максимально складну освіту яку тільки мозок здатен опанувати.

Якщо ж хочеться працювати — то працювати паралельно. Всі так роблять :) Тут проблеми немає.

До CS можна багато чого віднести, але базові знання — must have.

Звісно, ви, як і багато інших, можете зробити собі життя простіше і «воно не дуже й треба». У вас буде шанс на достойне життя :) Але раджу так робити лише, якщо ви розумієте, що фізично не здатні то опанувати.

ChatGPT видалив цей коментар, оскільки він не схожий на інші.

Я, власне, це і мав на увазі, що null safety — там проблема.

Про оператори — це я про про те, що їх додати легко, і хоч null safety це не зробить, але код стане значно чистішим.

Друге не вважаю скільки-небудь критичним.

Я б з вами погодився ... але тут є до певної міри справа звички. Зараз якийсь час вже працюю з Dart. Там відносно нещодавно впровадили null safety схожим чином як в котліні. Міграція там була дууже масштабна (це трохи біль). Але після досвіду використання такого підходу, коли повертаєшся до проекту на Java, відсутність такого механізму «дуже чешиться».

В цілому, я слабо собі уявляю nullable типи в Java (занадто багато міняти). З іншої сторони, не бачу жодної проблеми зробити оператори ?? та ?. — це легко зробити, і значно спростило б життя.

Ми використовуємо kotlin на server side.

І для цього є єдина причина: корутини.
Це дуже велика killing feature. Яка в Java відсутня. Project Loom обіцяє альтернативу. Але це трохи інше і ще не пробували його в проектах.

Далі я б вказав null safety, string interpolation та equals в String.

Решта фіч теж цікаві ... але тут я б почав перераховувати недоліки.

1. Погана підтримка java modules. Ця штука вже є з java 9. І я, якщо чесно, очікував, що всі великі важливі бібліотеки це будуть підтримувати. Не впевнений що там зараз, але коли я останній раз дивився ktor — він не працював з java modules. Чому? Хз ... напевно, тому що ліньки порефакторити і випустити для цього мажорний реліз.

2. Той самий ktor ... давайте подивимось приклад:
github.com/...​FileListingApplication.kt
Подивіться стрічки 30-40 та 45-161. З моєї суб’єктивної точки зору, навіть якщо мова програмування дозволяє таке писати — то це точно антипаттерн і йому не місце в офіційних семплах. Такий стиль дуже схожий на зловживання define-ами в C, C++. Воно виглядає гарно. І можна навіть здогадатись що воно робить. Але що конкретно відбувається (в якого об’єкту і що викликається) — абсолютно не ясно. Тобто щоб зрозуміти що тут написано треба не просто знати котлін. Потрібно вивчати також «псевдомову» кожного конкретного фреймворку.

3. Чомусь Kotlin позиціонуть як щось для розробки під Android. Це трохи дивно. Це те ж саме, що сказати, що Java — це розробка під Android )) Це я до того, що Kotlin не зав’язаний на мобілках і може використовуватись кругом де і Java.

4. Статичні методи як companion object — це відверто дивне рішення.

В цілому, додати б в Java корутини та null-safety, і вагомих причин працювати з котліном майже не залишиться.