У меня частенько бывает паника из-за забытого пин-кода, потому что его спрашивают чуть чаще, чем никогда, а как спросят — начинаешь в голове крутить цифры 6 карт, что дома лежат, и других карт, которые уже давно кончились.
В том смысле, что LedisDB является фронтендом для LMDB/RocksDB/LevelDB/итд, то есть размер данных ограничен лишь вместительностью диска, а не объёмом оперативной памяти.
Redis выигрывает у всех бекендов, так как сидит непосредственно в памяти.
> банально []string как модель принять не может «Это временные трудности на пути к царству света!»
Самый адекватный хак здесь это сделать метод func At(i int) string, тогда можно будет использовать как модель длину слайса, а внутри элемента модели через .At(index) получить искомую строку. Так можно слайс любых объектов завернуть.
Если не очевидно, могу пример привести.
Какой-то заученный ответ, падения не из-за nil, а из-за невозможности продолжения выполнения программы. И если программа продолжила там, где не должна была, то это ошибочка-то посерьёзнее падения будет.
Здесь тред немного политический, хоть и хабр и в не политики. Так что оставляя здесь комментарий не в пользу Rust вы рискуете быть неправильно понятым, так как все нейтрально мыслящие иронию поняли как надо, мне кажется :)
Меня тоже достали сравнения, но блин, это как в ситуации с Android vs iOS — первые сравнивают и критикуют, вторые берут и пользуются. Меня интересует расклад дел и прогноз на будущее, так что я много читаю мнений. И вот почему-то «нелюбителям» Go не лень каждый раз сравнивать его с Rust и прочими хаскелями, подчеркивая ничтожность, почему бы не заметить здесь обратное наблюдение? Что как ни крути, а один из главнейших минусов разработчики «по-настоящему правильного» языка взяли да оставили без новизны подхода :)
Go имеет свою конкретную, вполне узкую область — это язык для написания бэкендов
Один брякнул и все повторяют из уст в уста, что значит для бекэндов? Нет, я не спорю, что в realtime задачах при ограниченном наборе ресурсов или при большом количестве данных требуется специализированный подход, но Go привязывать к «backend» смысла нет. Вот я бы поспорил, удобнее ли на Rust писать GUI программы, чем на Go.
Да, забавно смотрится, как абсолютно такой же подход к обработке ошибок просто оброс Rust-specific синтаксисом.
Цитирую документацию:
// This is a three level match pyramid!
match checked::div(x, y) {
Err(why) => fail!("{}", why),
Ok(ratio) => match checked::ln(ratio) {
Err(why) => fail!("{}", why),
Ok(ln) => match checked::sqrt(ln) {
Err(why) => fail!("{}", why),
Ok(sqrt) => sqrt,
},
},
}
они будто бы даже гордятся тем, что можно городить пирамидку из вызовов и проверок их Result на ошибки.
Пф, кто-то более успешный потратил 4 года на изучение языка и стал чуть более успешным (кумулятивно). Разумеется, немало хейта к такому событию от тех, кто вообще не отводит времени на саморазвитие и с трудом понимает базовый английский ;)
Ну мне просто показалось, что она была настолько непродолжительной и невыразительной, что «играл» это как-то громко сказано, тут всё-таки полноценная роль на весь фильм, как у смоделированного Высоцкого, например.
Не очень удачный пример, а вот в Троне Наследие сделали правда классно (хотя и видно, что пока есть куда расти)
«Клу должен был выглядеть, говорить и двигаться в точности, как молодой Джефф», — говорит обладатель «Оскара» Эрик Барба, главный специалист по визуальным эффектам. — «Джефф великолепно отработал свою роль, но Клу должен был выглядеть как настоящий человек, а конкретнее — как Джефф Бриджес начала 80-х. Мы продвинули технологию E-motion Capture на совершенно новый уровень. Планка поднялась гораздо выше, чем раньше».
Джефф Бриджес — первый актёр в истории кино, встречающийся на экране с омоложенным собой.
Redis выигрывает у всех бекендов, так как сидит непосредственно в памяти.
Это для тех, кто планирует использовать Redis, но не уверен насчёт памяти.
то же самое, когда вы делаете Component для ListView.
«Это временные трудности на пути к царству света!»
Самый адекватный хак здесь это сделать метод func At(i int) string, тогда можно будет использовать как модель длину слайса, а внутри элемента модели через .At(index) получить искомую строку. Так можно слайс любых объектов завернуть.
Если не очевидно, могу пример привести.
Нечто среднее это как маркетинг, что-то вроде честности 90% :)
Меня тоже достали сравнения, но блин, это как в ситуации с Android vs iOS — первые сравнивают и критикуют, вторые берут и пользуются. Меня интересует расклад дел и прогноз на будущее, так что я много читаю мнений. И вот почему-то «нелюбителям» Go не лень каждый раз сравнивать его с Rust и прочими хаскелями, подчеркивая ничтожность, почему бы не заметить здесь обратное наблюдение? Что как ни крути, а один из главнейших минусов разработчики «по-настоящему правильного» языка взяли да оставили без новизны подхода :)
Один брякнул и все повторяют из уст в уста, что значит для бекэндов? Нет, я не спорю, что в realtime задачах при ограниченном наборе ресурсов или при большом количестве данных требуется специализированный подход, но Go привязывать к «backend» смысла нет. Вот я бы поспорил, удобнее ли на Rust писать GUI программы, чем на Go.
Цитирую документацию: они будто бы даже гордятся тем, что можно городить пирамидку из вызовов и проверок их Result на ошибки.