свои коллекции писать? монады?

Щас бы в 21 веке делать язык с общим воркспейсом для всех проектов и говорить, что это фича

Щас бы в 21 веке делать язык с общим воркспейсом для всех проектов и говорить, что это фича

он не общий лол

конкретные кейсы назовите когда там нужны генерики)

да их 100500 этих кейсов да банально контейнеры как жить? как до 5-й java класть туда Object и кастить туда-сюда обратно?

он не общий лол

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

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

$GOPATH переключай просто между проектами и все

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

да их 100500 этих кейсов да банально контейнеры как жить? как до 5-й java класть туда Object и кастить туда-сюда обратно?

учитывая что в джаве они затираются...

если это недостаточное обоснование их нужности, то я даже не знаю

$GOPATH переключай просто между проектами и все

Да, определенно, это лучшее решение проблемы, которую создаёт ЯЗЫКОВАЯ ФИЧА

есть array/map/channel, которые отчасти генерики)

Вы тут снова спецолимпиаду проводите? :)

А так говоря, действительно, зачем в Го дженерики? Там же даже ООП в присущем ему виде нет, там и без дженериков хорошо живётся

[]interface{} - почти тот же Collection<T>, один хер в рантайме нельзя до типа T достучаться)

при компиляции можно

котлин нейтив будет сильно конкурировать с гошкой, когда релизнется

и "у нас есть генерики" это как-то не самый сильный аргумент)

учитывая что в джаве они затираются...

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

У нас кроме генериков есть весь остальной котлин, нормальный типобезопасный интероп с сями и обжом, возможность с первой версии генерировать юзабельные .a / .so, мульти-платформа, и это всё только первое, что в голову пришло. Но любители отключать себе систему типов могут продолжать писать на Го :)

По моему, Сережа нас просто троллит :)

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

давай вспомним CNCF проекты, которые почти все написаны на го и о боже их поддерживают)

По моему, Сережа нас просто троллит :)

я тоже так думаю )

?

котлин нейтив будет сильно конкурировать с гошкой, когда релизнется

Будет ли? Мне казалось, что эти языки всё-таки слишком разные, чтобы конкурировать. Даже конкуренция Go и Rust выглядит не так уж убедительно.

Будет ли? Мне казалось, что эти языки всё-таки слишком разные, чтобы конкурировать. Даже конкуренция Go и Rust выглядит не так уж убедительно.

будут, Бреслав говорил

Понял

котлин с корутинами и своей моделью памяти vs golang

там они в принципе будут на равных

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

конкретные кейсы назовите когда там нужны генерики)

Это такой троллинг?)

Это такой троллинг?)

да, жирновато

генерики везде нужны0

давай вспомним CNCF проекты, которые почти все написаны на го и о боже их поддерживают)

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

писать можно на чем угодно, вон сколько проектов на пхп 4м написано и ниче)

и на перле!

О!

есть такой вопрос - на сколько это идеоматичный код?

а, чщерт, минус стикерпаки

и как сделать правильнее?

жесть какая

Клевые стикоры, спасибо

как сделать на clj понятно - some-> и вперед

как на java тож

а как на kotlin пока не очень понятно

во-первых познакомся с early returns

Клевые стикоры, спасибо

Какая от них польза, если их нельзя покидать в этом чате (

"when (...) null -> " не идиоматично, есть же ?: и safe-call операторы

ну вот с let? как раз попытка обработки если есть

Выдели null ветку в отдельную функцию, можно в локальную, и when замени на if

но ощущение "через жопу" остается и непонятно

if (depth >= MAXDEPTH) return null val avail = exchangeRates[from] ?: return null val rate = avail[to] if (rate != null) return Path.... return avail.map(..)

ага то есть надо поближе к java < 8

if (depth >= MAXDEPTH) return null val avail = exchangeRates[from] ?: return null val rate = avail[to] if (rate != null) return Path.... return avail.map(..)

if (rate != null) в Котлине не нужен

if (rate != null) в Котлине не нужен

let это не замена ему

let это не замена ему

Есть run

?.someStuff()?.someMoreStuff() ?: defaultValue

Зачем if'ом на null проверять?

вот вам код, сделайте лучше)

не ударяясь во вложенность

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

если целиком

при том что такого пути может не существовать вообще

Черт ногу сломит

Зачем if'ом на null проверять?

rate ?: return null

Вот вам и однострочники идиоматичные

Лол. Тогда можно без элвиса же.

ну ок сорян, вот обновленная версия if (depth >= MAXDEPTH) return null val avail = exchangeRates[from] ?: return null val rate = avail[to] ?: return Path.. return avail.map(..)

Я не понимаю желания сделать кучу return'ов в одной функции, неудобно же читать

наоборот же

Я не понимаю желания сделать кучу return'ов в одной функции, неудобно же читать

Человек делает по квикфиксам в IntelliJ

val avail = exchangeRates[from] if (depth >= MAXDEPTH || avail == null) return null val rate = avail[to] return if (rate != null) Path(...) else avail.map(..)

Я бы так написал

А avail.map(...) выделил бы в отдельную функцию

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

И да, принято писать avail .map(...) .sortedBy { ... } .filterNotNull() ?.let { }

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

вообще что стоит почитать чтобы понять "как принято"?

вообще что стоит почитать чтобы понять "как принято"?

https://kotlinlang.org/docs/reference/coding-conventions.html

наоборот же

это троллинг надеюсь?

это троллинг надеюсь?

конечно же лучше такое function() { HRESULT error = S_OK; if(SUCCEEDED(Operation1())) { if(SUCCEEDED(Operation2())) { if(SUCCEEDED(Operation3())) { if(SUCCEEDED(Operation4())) { } else { error = OPERATION4FAILED; } } else { error = OPERATION3FAILED; } } else { error = OPERATION2FAILED; } } else { error = OPERATION1FAILED; } return error; }

Очередное утрирование ?

1 return не всегда "читаемей" чем несколько, тут главное в крайности не впадать

Конечно, вообще ранний выход это хорошая практика

Избавляет от лишней вложенности и контекста

отрезаешь по пути все прекондишены и невалидные условия, а в конце возвращаешь результат

конечно же лучше такое function() { HRESULT error = S_OK; if(SUCCEEDED(Operation1())) { if(SUCCEEDED(Operation2())) { if(SUCCEEDED(Operation3())) { if(SUCCEEDED(Operation4())) { } else { error = OPERATION4FAILED; } } else { error = OPERATION3FAILED; } } else { error = OPERATION2FAILED; } } else { error = OPERATION1FAILED; } return error; }

https://medium.com/@lupajz/you-either-love-it-or-you-havent-used-it-yet-a55f9b866dbe

https://medium.com/@lupajz/you-either-love-it-or-you-havent-used-it-yet-a55f9b866dbe

и нахуя?)

Убирает кучу дупликации как раз в таких случаях

ранний выход нужен если в теле функции происходит не только полезная работа, но ещё и валидация

зачем их засовывать в одну функцию - хз

https://medium.com/@lupajz/you-either-love-it-or-you-havent-used-it-yet-a55f9b866dbe

в таком случае тебе всегда нужно учитывать что у тебя либо результат, либо ошибка. с early return ты ошибки сразу отсекаешь и работаешь только с результатом. контекст на много уже

вообще такое ощущение что Clean Code никто не читал, там это все описано было хз сколько лет назад

Так у тебя контекста не меньше получается в функции, error code это вообще зло ж

Но там еще явно не указано, что "error", оказывается, не только ошибку может означать, но и успешное выполнение

конечно же лучше такое function() { HRESULT error = S_OK; if(SUCCEEDED(Operation1())) { if(SUCCEEDED(Operation2())) { if(SUCCEEDED(Operation3())) { if(SUCCEEDED(Operation4())) { } else { error = OPERATION4FAILED; } } else { error = OPERATION3FAILED; } } else { error = OPERATION2FAILED; } } else { error = OPERATION1FAILED; } return error; }

Тут явно напрашивается when

зачем их засовывать в одну функцию - хз

+