Чёт желтушный заголовок, в интервью про другое же

Типичное интервью, ничего необычного

> Любая либа становится круче и удобнее, если ты просто начинаешь использовать её из Котлина, просто по факту использования Котлина. > У тебя аж голос изменился, так эмоционально всё описываешь.

https://habr.com/company/jugru/blog/421607/

его послушать, так горутины все неправильно делают, вот в котлине-то совсем иначе

это ж надо уметь, сука, выставлять недостатки за достоинства (на словах)

я помню мне в 2013 один кореш показывал в elixir потоки, как быстро они работают

Но как только я начну писать сложную бизнес-логику, делать какую-то иерархию классов, моделировать сложный домен, то в нетипизированном языке я очень быстро умру. Очень быстро. И всё это поддерживать будет невозможно. На этом строится философия Kotlin, он еще более типизированный, чем Java, еще более строгий. Это core belief в команде Kotlin, что язык промышленного масштаба должен быть строго типизированным

вот это чистой воды лицемерство

почему?

почему?

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

его послушать, так горутины все неправильно делают, вот в котлине-то совсем иначе

Да вообще, в котлине неправильно всё, что только можно. Мы тебя поняли.

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

именно то, что делается в, скажем, скале

ну так-то кроме скалы вообще все языки отстой

да не такая строгая эта типизация

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

вот это и бесит

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

че подпалился то?

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

> kotlin is object-oriented написано у них на сайте

по факту, это джава++, и в таком ключе котлин идеален

Java#

https://t.me/kotlin_lang/82711

XD

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

чому же сходу не получится, вот eta, например - просто взяли и начали делать, и вроде как процесс идёт и финасирование есть. собственно запиливают хаскель на жвм

да можно и без JVM)

чому же сходу не получится, вот eta, например - просто взяли и начали делать, и вроде как процесс идёт и финасирование есть. собственно запиливают хаскель на жвм

1) его пилить и пилить ещё 2) критично различие подходов "типичной" джавы (хайбернейты всякие) и хаскеля, они несовместимы

то есть, надо делать свою экосистему

и вот тут возвращаемся к моменту, почему мне не нравится котлин: они хотят сесть на два несовместимых стула

1) его пилить и пилить ещё 2) критично различие подходов "типичной" джавы (хайбернейты всякие) и хаскеля, они несовместимы

как будто ты в скале хотел бы видеть хайбернейты всякие. я их вот и в жаве видеть не могу , и собственно не вижу

как будто ты в скале хотел бы видеть хайбернейты всякие. я их вот и в жаве видеть не могу , и собственно не вижу

а в скале своя экосистема

ну то есть офк можно хайберы со спрингами, но это редкость

и вот тут возвращаемся к моменту, почему мне не нравится котлин: они хотят сесть на два несовместимых стула

в ту же копилку про 2 стула: развитие не-джвм таргетов так же заставляет делать свою экосистему

но тогда херится концепт джавы 2

и в итоге получается полная каша

в ту же копилку про 2 стула: развитие не-джвм таргетов так же заставляет делать свою экосистему

ну там можно реимплементить довольно большую часть стдлибы , так-то

ну там можно реимплементить довольно большую часть стдлибы , так-то

но котлин-джс по другому пути идут

можно, скала-джс так и делает

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

сделай они либу, вообще претензий не было бы но нет

а ты необучаемый

Есть вопрос, distinct удалит все элементы кроме первого встреченого?

речь про collection stream

Есть вопрос, distinct удалит все элементы кроме первого встреченого?

у тебя будут удалены все дубликаты

ну понятно что дубликаты

первый элемент останется, да

то есть 1 2 1 2 3 3 distinct даст 1 2 3

с цифрами то ок, а если {{key0, val0}, {key1, val1}, {key0, val2}}

то останется {{key0, val0}, {key1, val1}}

?

с цифрами то ок, а если {{key0, val0}, {key1, val1}, {key0, val2}}

у тебя List<List<X> > типа?

нет

лист пожо

но дистинкт по свойству

смотри на реализацию equals

пожо сравнивается через equals и hashcode

ох

первый элемент останется, да

это точно?)

ох

@javastart

это все понятно

не понятно первый или не первый)

может он их сортирует сначала или с конца идет

если equals возвращает true то они одинаковые

не понятно первый или не первый)

нет, он идёт с начала

не важно, первый или последний

важно

не важно

если eq сравнивает айдишники а кроме них есть другие поля

ERROR: S client not available

у тебя equals вообще определен?

важно

{a a} {b a} {b b} {b b} -> disctinct -> size == 3

что значиьт "если"?

если eq сравнивает айдишники а кроме них есть другие поля

Тогда это кривой дизайн

@javastart ?

если eq сравнивает айдишники а кроме них есть другие поля

переопредели equals так, как тебе надо

я обьект обернул

мне надо миграцию сделать, чтобы дубликаты убрать

да кароче быстрее эксперимент провести)

блин как ты в сет кладешь элементы?

здесь тоже самое

сделай new HashSet(list)

мне надо миграцию сделать, чтобы дубликаты убрать

смотри на реализацию конкретно нужного тебе класса, там equals какой

еще можно повесить @EqualsAndHashcode

для ленивых

Inline: public class EqualizeWrapper<T> { private T t; private Function<T, ?> getKey; public EqualizeWrapper(T t, Function<T, ?> getKey) { this.t = t; this.getKey = getKey; } public T unwrap() { return this.t; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; EqualizeWrapper<T> that = (EqualizeWrapper<T>) o; return Objects.equals(getKey.apply(this.t), getKey.apply(that.t)); } @Override public int hashCode() { return Objects.hash(getKey.apply(this.t)); } }

ну или создай класс-обертку, заэкстендься от нужного класа, override equals как тебе надо и в стриме .map юзай для получения нужного класса

совсем дикий вариант, но чё поделать)

дак так и есть

вопрос же был не как, а что будет)

XD

он сделает 100500 сравнений equals

с предыдущими

и где true - те будут выкинуты из стрима

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

по логике вещей последний)

первый останется

но тебя это не должно волновать

они же равны)

они не равны

они разные!!111

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