На Rust запилили Coroutine, Go можно выкидывать?

Т.е. по твоему типичный код на ржавчине - это ffi и низкоуровневые оптимизации? :)

Нет, это просто для примера. client может просто прийти неинициализированным. И в итоге функция радостно выплюнет информацию в никуда либо будет до упора (таймаута) ждать чего-нибудь. Т.е. никаких гарантий Result не дает по сравнению с Go. Вот и все что я хотел сказать.

Тебе явно надо учиться выражать свои мысли.

Возможно.

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

Так и в Go нельзя. Кроме как явно через _

Впрочем, если это ты выше делил на 0, то просто не думай об этом.

Не я.

Жуть-то какая, хосподя.

Да ладно?

Весьма слабовато, но пока есть еще шанс не стать новым Lisp.

Это смотря с чем сравнивать. Всё-таки язык новый, да и старые проекты никто переписывать не бросился бы. А интерес к языку есть. На гитхабе, опять же, проектов много.

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

Ну так и в Go тоже нельзя просто взять и написать client :=. Тоже заставят получить и расписаться.

Впрочем, если это ты выше делил на 0, то просто не думай об этом.

Это ты отвечал другому анонимусу. Я поставлю себе подпись.

// 1

1/v

Это совсем другое. К алгебраическим типам отношения не имеет.

Ну и опять же, тут паника с вполне конкретным поведением, а не UB. Так в чём проблема?

Ну и опять же, тут паника с вполне конкретным поведением, а не UB. Так в чём проблема?

Напомню - это ты придрался к моему примеру по поводу проверки client. Проблема очевидно на твоей стороне.

// 1

Вас спрашивают «зачем», а вы не можете привести примеров. И объяснить не можете.

Конечно, могу. Для удобства. Как-никак, мой основной инструмент - С++. И я был бы очень рад, если бы либы подключались так же легко, как в языках, где есть свой «менеджер пакетов».

Плюс карго - это ещё и система сборки. В С++ же полный зоопарк.

По моему, это очевидно всем, кроме тех, кто будет доказывать, что всё хорошо и мейкфайлов хватит всем.

Т.е. никаких гарантий Result не дает по сравнению с Go.

Вообще-то даёт.

То, что ты показал - это говорит только о том, что язык не предоставляет дополнительных гарантий для арифметических операций. Но тут и у Go и С++ ситуация абсолютно такая же.

Так и в Go нельзя. Кроме как явно через _

Это другое. Ты можешь, пусть и явно, проигнорировать ошибку, а потом обратиться к nil. В расте так (без unsafe) нельзя.

Проблема очевидно на твоей стороне.

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

Но я всё-таки ещё раз попытаюсь. Для примера пусть будет вообще С.

void f(int* ptr)
{
    // Можем использовать без проверки.
    *ptr = 10;
}

Ага. write-only код

для арифметических операций.

И опять ты ничего не понял. Это может быть null, арифметические операции, закрытый файл, пустое имя или любые другие некорректные данные. И тупая проверка:

name, err := input_name(...);
if( len(name) > 0 )
    return err;

в 100500 раз надежней, чем твой match.

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

Так и в Go нельзя. Кроме как явно через _

Вечно забываю, что там запрещены неиспользуемые переменные. Но от ошибок это не страхует:

package main

import "fmt"
import "errors"

func f1(arg int) (int, error) {
    if arg == 42 {
	 return -1, errors.New("can't work with 42")
    }
    return arg + 3, nil
}

func main() {
	res, err := f1(42)
	if err != nil {
		fmt.Println(res);
	}
}

Это другое. Ты можешь, пусть и явно, проигнорировать ошибку, а потом обратиться к nil. В расте так (без unsafe) нельзя.

Возвращаемся к unwrap (c)

// 1

А в расте (без unsafe) так нельзя. Вот и всё.

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

// 1

Это может быть null
закрытый файл, пустое имя

Нет, не может.

Никто не спорит, что это не серебрянная пуля и данные проверять надо. Но ты почему-то не можешь понять простую мысль: если у нас есть опциональное нечто (не важно указатель или какой-нибудь boost::optional), то С++ тебе позволит работать с ним независимо от того есть ли там что-то. Раст - нет. Аналогично с парой (результат/ошибка) или большим количеством значений.

Ну и тут дело даже не в match, хотя он адски удобен.

Возвращаемся к unwrap (c)

Ну давай вернёмся. unwrap кидает панику, так что опять же, если ты написал:

let res = get_some().unwrap();
println!("{}", a);

тебя уже понесло совсем в другую степь.

Почему в другую? Я никогда не утверждал, что раст спасает от всех ошибок. Изначально как раз говорил о том, что растовые Option/Result удобны как раз тем, что избавляют от некоторых проблем.

Возможно, было недопонимание, но я ни к чему не придирался, а пытался объяснить преимущества.

Нет, не может.
данные проверять надо

Окай.

Раст - нет

Option + unwrap в rust ничем не безопасней optional. Абсолютно. И unwrap и unwrap_or это то, что повсеместно используется в servo, единственном крупном проекте на rust.

А Go реально взлетит, если НА НЕМ, Б...Ь, АНДРОИД ПЕРЕПИШУТ. Или хотябы позволят ваять на нем свои поделки с гуйней и доступом к системе.

Пиши

Rust будет игрушкой до тех пор пока не будет серьезных проектов. Go уже взлетел и уже начинает меня раздражать своей популярностью

У вас может какие другие источники, но насклько я наблюдаю гитхаб тренды, то по Go всякая ерунда вокруг docker или переписывают очередной ls с Си на Go.

По Ржавому сейчас в основном всякие либы пилят, но новые проекты в фиде появляются даже чаще, чем в Go.

Вот даже, щас глянул, по расту новую либу запилили rust-bloom-filter, а по Go rocker-compose - Docker composition tool бла-бла-бла, смотрю дальше watchtower - Automatically update running Docker containers

И я не специально как-то подгатавливался, даже перед тем, как написать, что по Go пишут одни докер обвязки, я не заглядывал в фид, а заглянул только после тех предлложений. Просто это уже приелось, как не глянешь в тренды Go, обязательно какая-нить хренотень для докера.

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

То или у тебя в res будет значение или до строки с println дело вообще не дойдёт. Видишь разницу?

Так и С может, тоже мне супер-пупер проверка.

И unwrap и unwrap_or это то, что повсеместно используется в servo

Ты уверен, что unwrap и unwrap_or вообще следует упоминать в одном контексте? %)

Ты уверен, что unwrap и unwrap_or вообще следует упоминать в одном контексте? %)

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

оба позволяют игнорировать обработку ошибок в коде

Мде. Ты «// 1», но перестал подписыватья?

Для удобства.

«Удобства во дворе»(с)

Это необъективный аргумент. Сам факт наличия спора это подтверждает. Одним удобно одно, а другим - другое.

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

А теперь подумай над тем, что они бы так легко и подключались, если бы все пользовались одной системой сборки, одним компилятором и одним менеджером пакетов. После этого подумай, почему так сложилось. Когда речь о кроссплатформенности у тебя всегда два варианта. Или ты делаешь песочницу, которую таскаешь везде(в случае нативных технологий это только подходы в духе docker), или же ты учишься работать с разными компляторами/менеджерами пакетов/etc. Системы сборки так же могут быть разные, т.к. решаемые задачи разные, что приводит к разным видам организации проектов.

В С++ же полный зоопарк.

Полный зоопарк в мире нативных разработок, а не в C++. Просто C++ используется много где. А ты все с ног на голову переворачиваешь. Язык вообще вторичен.

Ты можешь, пусть и явно, проигнорировать ошибку, а потом обратиться к nil. В расте так (без unsafe) нельзя.

И чем же так сильно _ отличается от unsafe в данном случае?=)

Не говоря уже о том, что панику можно и перехватить.

ы? panic! он же вроде на то и сделан, чтобы грохнуться быстро и громко. Эксепшенов в расте нет, поэтому так.

Ну где ты увидел месиво из unwrap(), аноним? Вот код https://github.com/jedisct1/rust-bloom-filter/blob/master/src/bloomfilter/lib.rs, всего два unwrap'a на либу.

Мде. Ты «// 1», но перестал подписыватья?

Да. Вот вся разница между ними:

    pub fn unwrap(self) -> T {
        match self {
            Some(val) => val,
            None => panic!("called `Option::unwrap()` on a `None` value"),
        }
    }
    pub fn unwrap_or(self, def: T) -> T {
        match self {
            Some(x) => x,
            None => def
        }
    }

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

Мде. Ты «// 1», но перестал подписыватья?

Да.

Ясно. Подписываться - отличная идея, не забывай это делать.

ват?

У тебя из функции возвращается, допустим, Result<T, err> соответственно никакой null тебе не вернётся, если функция тебе его не вернула как T, т.е. как валидный результат. А если у тебя T - enum, то null тебе даже если очень захочется не вернут.

Да, я понимаю, что у людей пишущих на динамических языках профессиональная травма и они null ждут везде, но думать-то головой надо хоть иногда.

Ну где ты увидел месиво из unwrap(), аноним? Вот код https://github.com/jedisct1/rust-bloom-filter/blob/master/src/bloomfilter/lib.rs, всего два unwrap'a на либу.

Отличный пример. На полноценную либу не тянет даже с натяжкой, зато видно, что в данном небольшом куске кода вообще нет проверок, кроме «двух unwrap'ов». Как и нет match.

// 1

try!

ИМХО тоже костыль в общем-то

Ясно. Подписываться - отличная идея, не забывай это делать.

Да, вот тебя например хорошо знают, как старпера-неудачника-недотеоретика ;)

Option + unwrap в rust ничем не безопасней optional.

Да ладно? Мы о каком optional? Тот, что в стандарт добавить хотят, насколько я помню, ничего не проверяет. То есть неопределённое поведение в лучших традициях С++. И это не говоря о том, что вместо optional может быть указатель.

unwrap_or

А к этой функции какие претензии?

unwrap в либе - адовое зло. Если у тебя либа, то будь добр обрабатывать ошибки внутри, а что не получается, отдавать наружу в Result.

иначе паника будет происходить в самое неожиданное время.

Исключение встроенные тесты - там можно.

У тебя из функции возвращается, допустим, Result<T, err> соответственно никакой null тебе не вернётся, если функция тебе его не вернула как T, т.е. как валидный результат. А если у тебя T - enum, то null тебе даже если очень захочется не вернут.

Ясно, пример с null был неудачен, дальше разжевано для тех, кто не видит проблему в целом.

Да, я понимаю, что у людей пишущих на динамических языках профессиональная травма и они null ждут везде, но думать-то головой надо хоть иногда.

Читай дальше и думай.

// 1

try!

ИМХО тоже костыль в общем-то

Это хотя бы годный, идеологически верный костыль.

Да ладно? Мы о каком optional? Тот, что в стандарт добавить хотят, насколько я помню, ничего не проверяет. То есть неопределённое поведение в лучших традициях С++. И это не говоря о том, что вместо optional может быть указатель.

Проверяет и кидает исключение. Насчет указателя - в rust тоже можно не заморачиваться с Option.

А к этой функции какие претензии?

Аналогично - игнорирование и «съедание» ошибки. Легкий способ, что не писать обработку и не заметить, а что вообще происходит и почему.

Так и С может, тоже мне супер-пупер проверка.

Ты о том, что можно написать аналог unwrap? Конечно, можно. Вот только мы возвращаемся к тому с чего начали - в расте нельзя обратиться к не инициализированному значению. И это контролируется на уровне языка, а не руками, то есть надо не забыть и что-то дополнительно писать.

Да, вот тебя например хорошо знают, как старпера-неудачника-недотеоретика ;)

Ну да, и все, кто считает нужным, могут меня заигнорить, с помощью движка ЛОР или органолептически. Красота.

Ес-но, оба позволяют игнорировать обработку ошибок в коде.

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

в расте нельзя обратиться к не инициализированному значению

Можно - unsafe, а еще можно выпасть в panic через unwrap. И, повторюсь, так и делают в том же servo. А это по сути эталонный код на rust.

// 1

Одним удобно одно, а другим - другое.

Ага, мазохистам может быть «удобна» сложившаяся ситуация. Или ты правда хочешь сказать, что подключение библиотеки добавлением одной строчки в проекты хуже чем скачать сорцы и разбираться как это собрать? При том, что хватает любителей «оригинальных» систем сборки.

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

Забавно, да. Учитывая, что я говорю, что удобно иметь тулзу «из коробки», а ты отвечаешь, что их много. Как раз потому что стандартных и нет.

Полный зоопарк в мире нативных разработок, а не в C++.

В расте зоопарка нет, например. Или он не нативный?

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

Тут всё дело в том, что новые языки появляются уже с готовыми инструментами. А за С++ не стоит кого-то одного, кто мог бы их продвинуть.

позволяют игнорировать обработку ошибок в коде.

Это не соответствует действительности
Это может быть опциональный парамер, а не ошибка.

Тебе не кажется, что ты сам себе противоречишь?

// 1

И чем же так сильно _ отличается от unsafe в данном случае?=)

Тем, что у Option/Result нет unsafe методов. То есть тебе надо будет написать руками больше кода для доставания значения. В ногу, разумеется, выстрелить можно - язык-то системный.

Но даже не это главное отличие. Но главное отличие в другом - в расте ты не сможешь случайно забыть проверить. В Го - можешь.

client, err := listener.Accept()
if client == nil {
    fmt.Printf("couldn't accept: " + client.String())
}

Это неофициальный костыль, который работает еще хуже, чем Qt на андроиде.

https://github.com/getlantern/lantern

116 звезд сегодня, проекты на Rust - раз в 10 меньше. Интерес к Go огромен, куда не ткнись на том же reddit, slashdot или hn. И врядли тут какой-то платный пиар.

Но популярность конечно не всегда гарантирует лучшую реализацию.