Pull to refresh
14
0
Send message

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

impl<SinkT, ServerRpcVersion, ClientRpcVersion, T> Handler<SendClientRpc<ClientRpcVersion, T>> for Session<SinkT, ServerRpcVersion, ClientRpcVersion>
where
    SinkT: Sink<SinkItem = Bytes, SinkError = std::io::Error> + 'static,
    ServerRpcVersion: rpc::deserializer::ServerProtocol,
    ClientRpcVersion: rpc::serializer::ClientProtocol,
    T: Into<ClientRpcVersion::ClientRpcKind>,
{
    type Result = std::io::Result<()>;

    fn handle(&mut self, rpc: SendClientRpc<ClientRpcVersion, T>, _ctx: &mut Context<Self>) -> Self::Result {
        self.send(rpc.data).map(|_| ())
    }
}

Оставлю это здесь как аргумент против типов. Желающие могут попытаться найти ошибку

Стоило rozetked выпустить видео - так сразу и отдали деньги.

Очень нехватало этой информации!

Сколько агрессии и спихивания ответственности на руководителя, однако. Наверное, статья многих задела за живое, ведь автор не отрицал никак своей функции

Про prefetch можете ещё раз объяснить, пожалуйста?

Теперь я могу отозвать согласие на автоматическую обработку моих фотографий в вк (которое не давал). Ура, товарищи!

это значит, что если события эмитируются быстрее, чем их обрабатывают, они будут скапливаться в памяти до тех пор, пока она не закончится.
Строго говоря, bufferCount, windowCount и bufferTime не относятся к backpressure. Backpressure это механизм (говорю своими словами), который учитывает скорость обработки подписчиков. Например,
interval(1).subscribe(...)
взорвется, потому что скорость выдачи результатов почти всегда будет быстрее скорости их обработки. В rxjava же у Observable есть метод
range(int start, int count)
, который учитывает скорость работы подписчика и не дает обвалиться программе.

У меня вопрос немного не в тему, почему в rxjs нет выбора backpressure стратегии, как в джаве, например? Я даже находил упоминание о ней в документации. Как работать в таком случае, если у меня есть, допустим, бесконечный источник данных и потери данных не допустимы?

Молодцы, деньги нужно зарабатывать легко, денег надо много

Вообще не трогают и не вызывают агрессии такие люди. Скорее восхищение даже и стимул улучшить свои навыки презентации. Ведь компания, которая наняла на должность senior программиста с двухмесячным стажем узнаёт об этом. Может через неделю, может через пару месяцев. И в итоге усложнит процесс приема для всех. Это реальный минус

В том и отличие, что в хаскеле есть исключения, а в расте нет. То-есть, в расте я могу по сигнатуре функции понять, возможна ли ошибка или нет.
Например, функция из стандартной библиотеки хаскеля:
read :: Read a => String -> a

Ничего в сигнатуре не говорит о том, что может вылететь иключение (хоть функция и чистая):
read "five"::Int
*** Exception: Prelude.read: no parse
Я ждал, когда кто-то заговорит об этом. На мой взгляд, rust сейчас самый стабильный язык из тех, с которыми я работал. На нем почти реализованы монады, но при этом, нет исключений, которые непонятно зачем сделали в хаскеле. В итоге, я всегда знаю, какая функция может не вернуть значение – Option (Maybe), либо же она может вернуть ошибку – Result<T, Error> (Either). Мне не нужно делать пометок в стиле «throws ...» как в джаве. Мне не нужно заглядывать внутрь метода и разбираться, какие исключения отлавливать в блоке catch, я знаю заранее, какую ошибку (одну!) может вернуть функция. Если функция в расте возвращает u32, значет она возвратит его всегда.

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

Отличный разбор, только разницы между &’static и: ‘static не понял. Первое является подмножеством второго, правильно? То-есть частный случай, когда который работает только для случаев аля &’static str?

Да, это ведь не диалект питона

2

Information

Rating
5,979-th
Registered
Activity