Раст супер сложный язык, но когда смотришь на шаблонный C++, понимаешь что там настолько можно сделать все, что просто ППЦ

Раст супер сложный язык, но когда смотришь на шаблонный C++, понимаешь что там настолько можно сделать все, что просто ППЦ

мЕньшее зло

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

Концепции эти все вкусить примерно так же тяжело, как первое время в ерланг писать.

Раст супер сложный язык, но когда смотришь на шаблонный C++, понимаешь что там настолько можно сделать все, что просто ППЦ

Да, в Rust-е местами перебарщивают, могли бы и проще сделать.

Но по сравнению с C++ Rust уже минималистичен ?

Чет в последнее время меня сахар бесит в расте

Читаешь код - бред написан

А оказывается - при таких-то условиях он обозначает то-то

Кзлы блин

И так хрен разберешься

cachex началь юзать недавно, проблем пока не наблюдали

https://gist.github.com/liveforeverx/5f6426e1060ea2c234201dc0da35dba6

cachex началь юзать недавно, проблем пока не наблюдали

Вот это я имею ввиду, ключи разные, но транзакции блокируются. А еще он внутренности транзакции копирует в другой процесс, т.е. транзакции гонять через один GenServer - это не очень хороший дизайн.

Чет в последнее время меня сахар бесит в расте

странно читать эту предъяву в канале про элексир:)

В эликсире вроде норм пока что

странно читать эту предъяву в канале про элексир:)

В Elixir-е весь сахар можно на пальцах пересчитать.

Хотя я читал вчера RFC по сокращённому матчингу мапов

Что то типа /%{x, y}s -> %{x: x, y: y}

Но к счастью такого пока не сделали

А будет херово если сделают

Хотя я читал вчера RFC по сокращённому матчингу мапов

Вроде уже раз 10 предлагали такое))

И делают это года так эдак с 2015 точно.

Ну вот другого сахарка я не видел пока что

Хотя... Менторю exercism, там очень хорошо видно как люди не понимают по гангста фичам

Но иногда такое выкапывают...

https://github.com/meyercm/shorter_maps

Кстати, есть библиотека, которая sigil-у дает для этого, кому очень уж нужна эта фишка.

https://hex.pm/packages/shorter_maps - даже 9 других библиотек ее используют.

Вот и пусть лежит в библиотеке

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

В плюсах просто шаблоны выриглазные, вот в D - это другое дело.

Заметил кстати, что много людей любит cond

Хотя я ни разу в жизни его не использовал

Вообще бы выкинул его из эликсира нафик

А из хорошего - чары через ?

Крче в эликсире сахарка мало, но все равно есть лишний) А в Расте его либо очень много, либо так кажется потому что я редко на нем пишу

Между cond и if, я бы выкинул if.

if - частный случай cond и от того намного больший сахар в сравнении с cond.

If я использую

А cond - нет)

Есть места для ифов, дефолтные из СТД

Типа if Code.ensure_compiled

И дальше простыня

Есть core разработчик Elixir-а, кто использует cond и не использует if.

А конд точно всегда можно в кейс переписать

Это же субьективно.

if частный случай case

А есть места, где cond просто идеален и case с if-ом будут субоптимальны: cond do count < max_count -> ... value > min -> .... true -> ... end

ну бывает тоже) обычно там, где лень отрефакторить и побить на более мелкие функции)

Как по мне так if выглядит по другому

А cond|case одинково

Вообще if - это макро, а cond и case - специальные формы.

if - это сахар.

А case|cond - это база языка.

ну бывает тоже) обычно там, где лень отрефакторить и побить на более мелкие функции)

К примеру, в примере с 3-мя условиями (равноправными) - разбив на функции - это будет будет 3 функции с короткими телами, где when count < max_count и when value > min, либо аналогичный case с такими же whens.

when ограничен гвардами

да не, конд нужен иногда. но и отрефакторить тоже всегда можно)))

Отрефакторить, чтобы было сложнее читать?

cond в данном случае самый простой в чтении и понимании.

ну это же все субъективно)

и зависит от ситуации)

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

а так - пофик ваще)

@Nekifirus name = cond do is_nil(name) -> {self(), mod} is_atom(name) -> {:local, name} is_tuple(name) -> name end

ERROR: S client not available

Ну, не знаю, местами это лучшее решение и зачем рефакторить в худшую сторону?

субъективно. я бы снизу сделал 3 функции приватных. и матчил бы. ну вот так нравится). а тебе вот так нравится)

Вот ни разу не встречал реальных мест где нужен конд

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

Дай угадаю, под рефакторингом тут подразумевается объявление нескольких вариантов функций с паттернматчингом параметров?)

Где вы берете такой код...

Дай угадаю, под рефакторингом тут подразумевается объявление нескольких вариантов функций с паттернматчингом параметров?)

Это же cursed

Дай угадаю, под рефакторингом тут подразумевается объявление нескольких вариантов функций с паттернматчингом параметров?)

ну вот в случае с неймом, да, матчил бы параметры. а где-то в другом месте по-другому. это ж от контекста зависит.

Где вы берете такой код...

Из самого Elixir-а.

Я знал, что пишу лучше мейнтейнеров Эликсира Ж)

ну вот в случае с неймом, да, матчил бы параметры. а где-то в другом месте по-другому. это ж от контекста зависит.

cond do is_nil(function) or is_nil(arity) -> {"undefined function", false} is_nil(module) -> formatted_fun = Exception.format_mfa(module, function, arity) {"function #{formatted_fun} is undefined", false} function_exported?(module, :module_info, 0) -> message(:"function not exported", module, function, arity) true -> message(:"module could not be loaded", module, function, arity) end

И так далее, все это конечно можно разбить на функции с when

ну вот в случае с неймом, да, матчил бы параметры. а где-то в другом месте по-другому. это ж от контекста зависит.

Рефакторинг должен упрощать чтение когда, а подход с объявлением множества одинаковых функций с матчингом аргументов - сложно читать. case/cond в этих случаях как-то логичней, мне кажется

Но по сути это будет в основном единственный refactoring, но я считаю вынесение именно условий в одно место, как в случае с cond в основном читается проще.

можно подумать это я написал "Вот ни разу не встречал реальных мест где нужен конд" "Я конд не использую" "Вообще бы выкинул его из эликсира нафик"

cond do - норм. бывает нужен.

А, да, написано "скорее всего".

Меня не переубедили

Все равно

Ну, у меня просто, cond не частая вещь, но где есть, оттуда не убрать.

Меня не переубедили

так мне и не интересно тебя переубеждать )

Даже в самых запущенных случаях мне матрицу легче воспринимать

Меня не переубедили

Да, ну понятно, ты Бог, лучше чем ментейнеры Elixir-а знаешь, как писать Elixir или на Elixir-е... Тебя ни в чем не переубедить ?

iex(4)> b = << 63, 102, 111, 111 >> "?foo" iex(6)> padding_size = 1024 - bit_size(b) 992 iex(7)> b <> <<0 :: size(padding_size)>> <<63, 102, 111, 111, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...>>

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

Куда нам смертным ?

Типа case {foo?(a), bar?(b), bazz?(c)} do {true, false, _} -> ...

Там конечно надо смотреть по ленивости

Вот именно, сразу во всех приведенных выше случаях case-ом не заменишь.

Разве, что when-ы добавлять.

Либо рефакторить в приватные функции с when-ами.

лично мне when - сложный синтаксис. вероятно, потому, что я его использую еще реже, чем cond do