А уж определяется ли он как ссылка на уже существующее имя:
foo().map_err(handle)?
или же лямбда туда сразу отдается:
foo().map_err(|err| ...)?
это уже мелкая и незначительная деталь.
Вообще-то это очень существенная деталь. Во втором случае будет невозможно использовать один и тот же обработчик в нескольких разных местах. Собственно, handle в Go и понадобился, чтобы в том числе избежать дублирования кода обработки ошибок.
Ну а то, что эти handle связаны порядком следования, а не явными вызовами (как было бы в случае использования функций), по мне — так больше недостаток, чем достоинство. Чтобы понять, как будет обработана ошибка в конкретном месте, придется просматривать весь код выше и считать handle. Если между двумя разными check будет находиться некоторый handle, то придется держать в голове то, что эти check обрабатываются по-разному, хотя синатуры обработчиков и строк вызовов об этом нам не говорят.
А она вообще нужна? В смысле, цепочка, в которой элементы связаны неявно. Не приведет ли такой подход к проблемам с пониманием того, что именно произойдет во время ошибки в данном конкретном месте?
Ну вы хотели пример обработчика, который определяется перед тем, как диагностирована ошибка. Rust легко позволяет такое сделать. Если вы хотите еще и цепочку обработчиков — просто вызывайте из одного другой.
Возможно, это разные типы характера. Для кого-то и работать из-под палки — это плюс. Лично мне больше нравится, когда необходимо воспитывать дисциплину и организовывать свою работу самостоятельно, потому что такой навык требуется и в личных делах.
Конечно, домашние должны понимать, что вы — на работе, даже если физически присутствуете дома. Лично я прекрасно уживаюсь с женой и ребенком в двухкомнатной квартире. В однокомнатной, если с ребенком, конечно будет сильно сложнее. Но среди моих знакомых-удаленщиков есть и такие, которые прекрасно работали, живя в одной комнате с женой и младенцем. Так что не для всех это проблема. А если вы не можете договориться со своей супругой (а такие случаи я знаю), то по-моему нужно задуматься: а с тем ли человеком вы вообще живете?
2-3 часа перерыва можно себе позволять и оговаривать это на этапе найма.
Ох, это не просто. Часто за "особые" (в глазах нанимателя) условия, требуют и особой отдачи. То есть, как только ты заикаешься о каких-то доп. условиях, сразу начинается торг. И вроде-бы в итоге договариваешься, но осадочек остается. Но даже если удастся без проблем получить себе поблажки от руководства, то напряженность в коллективе все равно остается. Я уже проходил через это, когда выторговал себе в офисе четырехдневную рабочую неделю.
По поводу поломки оборудования: пару раз у меня бывало, что на сутки отключали интернет. Это напрягало, но никаких санкций за это небыло. У всех случается, обычно к такому относятся с пониманием, если это не происходит слишком часто.
а есть ещё и вроде рабочее, но не формальное
Такой формат общения сильно нужен на раннем этапе в профессии. Когда ты еще толком не умеешь решать серьезные проблемы самостоятельно. Во всяком случае мне это сильно помогло в первый год работы. Я бы советовал новичкам начинать работу с офиса, где пришлось бы работать бок-о-бок с опытными. Но дальше… Таким ментором уже становишься ты сам, и проблемы, если возникают, вполне нормально решаются через чат. Это чуть дольше, но зато остаются записи обсуждений на будущее.
Вы сами называете ещё два минуса: необходимость планировать и организовывать :)
Так это же плюсы :)
Насчет остального: маленький ребенок не сильно мешает (если тебе самому есть возможность им не заниматься во время работы) — проверил на себе. Отдельный кабинет — отличный вариант, но даже без него комфортнее, чем в офисном боксе. Когда любой подъем из-за стола для разминки или хождения туда-сюда во время размышлений начинают бесить всех присутствующих в офисе и создают тебе лишнее нервное напряжение.
гибкий график часто вырождается
Ну если получается (или необходимо по внешним причинам) работать всегда в одно и то же время — это неплохо. Лично мне нужен гибкий график для возможности расставить перерывы так, как мне удобно и как нужно для поддержания организма в рабочем состоянии. Например, если я работаю одним куском 4 часа, то после мне нужен двухчасовой перерыв как минимум, чтобы успеть не только поесть, но и восстановиться психически и физически.
Что касается обеспечения техникой… Я думаю 99% программистов и так ей обеспечены дома :) Дополнительно, я могу обеспечить себе стоячее и лежачее рабочее место, чего в офисе сделать крайне трудно.
А вот про неполноценность коммуникаций — ущерб чувствуешь только в плане отсутствия личного, внерабочего общения. Что же касается рабочего общения, то и в офисе оно ведется в 90% случаев дистанционно (по крайней мере у нас так было). Собственно, это послужило для меня одним из толчков к уходу из офиса: программировать за компьютером и переписываться в чате или электронной почте с коллегами я могу и из дома (или из парка/поезда/гостиницы) без ущерба для рабочего процесса.
Из своего 10-ти летнего стажа я только 3 года в самом начале проработал в офисе. И этого мне хватило выше крыши, чтобы больше туда не возвращаться.
Работая удаленно по гибкому графику, ты можешь сам планировать свой рабочий день и сам организовывать свое рабочее место. Это снимает кучу минусов офисной работы, хотя и добавляет один новый: развиваться в одиночестве труднее. Зато о большинстве остальных проблем можно забыть. Хорошо, что с каждым годом такой формат работы становится все популярнее.
Кстати, в книге Крайтона энергосистему запускал Тим, а не Лекс. И там был сенсорный дисплей, потому и блочно-кнопочный UI. Unix, насколько я помню, не упоминалась.
Если не читали книгу Крайтона — настоятельно рекомендую ознакомиться, это эталон жанра «технотриллер». В фильме и десятой доли не показали того, что творилось в Парке с технической частью.
Правда на русском языке самый адекватный перевод от Нерсесянц и Шишовой 93-го года. Последующие — намного хуже, они там «листинг исходного кода» называют «страницей кодировок» и прочее в таком духе.
А эта библиотека предоставляет прямой доступ к Vulkan: https://github.com/MaikKlein/ash
Вот вам простейший пример вулканического кода, выводящего на консоль свойства первого устройства:
main.rs (69 строк)
#[macro_use]
extern crate ash;
use ash::{vk, Entry, Instance};
use ash::version::{EntryV1_0, InstanceV1_0, V1_0};
use std::ptr;
use std::ffi::CString;
struct Vulkan {
entry: Entry<V1_0>, // Must have the same lifetime as the instance
instance: Instance<V1_0>,
}
impl Vulkan {
fn create() -> Self {
let entry = Entry::new().unwrap();
let app_name = CString::new("Vulkan test").unwrap();
let app_info = vk::ApplicationInfo {
p_application_name: app_name.as_ptr(),
s_type: vk::StructureType::ApplicationInfo,
p_next: ptr::null(),
application_version: 0,
p_engine_name: app_name.as_ptr(),
engine_version: 0,
api_version: vk_make_version!(1, 0, 36),
};
let instance_info = vk::InstanceCreateInfo {
s_type: vk::StructureType::InstanceCreateInfo,
p_next: ptr::null(),
flags: Default::default(),
p_application_info: &app_info,
pp_enabled_layer_names: ptr::null(),
enabled_layer_count: 0,
pp_enabled_extension_names: ptr::null(),
enabled_extension_count: 0,
};
let instance: Instance<V1_0> = unsafe { entry.create_instance(&instance_info, None) }
.expect("Instance creation error");
let physical_devices = instance
.enumerate_physical_devices()
.expect("Physical device error");
let physical_device_properties = instance
.get_physical_device_properties(physical_devices[0]);
println!("{:#?}", physical_device_properties);
let physical_device_features = instance
.get_physical_device_features(physical_devices[0]);
println!("{:#?}", physical_device_features);
Vulkan {
entry,
instance,
}
}
}
impl Drop for Vulkan {
fn drop(&mut self) {
unsafe {
self.instance.destroy_instance(None);
}
}
}
fn main() {
Vulkan::create();
}
Cargo.toml
[package]
name = "vulkan_test"
version = "0.1.0"
[dependencies]
ash = "0.24"
Есть два разных подхода к разработке фронтэнда: первый — это статически описывать разметку в шаблоне и добавлять вкрапления исполняемого кода; второй — это создавать фронтенд программно, а для упрощения кода по созданию отдельных элементов использовать вкрапления DSL-синтаксиса, описывающего структуру элементов. Вот как раз второй подход и используется в yew, как и в React/JSX.
pub struct S<'a> {
link: &'a i32 // иммутабельная ссылка
}
struct S2<'a> {
vec: Vec<S<'a>> // глобальный массив объектов, которые будут разделять владение переменной
}
impl<'a> S2<'a> {
fn create_vector(&mut self) {
self.vec = Vec::new(); // создаем массив
let x = 170239; // переменная, на которую будем ссылаться
for _ in 0..10 {
let s = S {
link: &x
};
self.vec.push(s);
}
}
fn change_vector(&mut self) {
let x = 239017; // другая переменная, некоторые ссылки из массива мы обновим на нее
for _ in 0..20 {
// обновляем случайный элемент
let ind = rand::random::<usize>() % 10;
let s = S {
link: &x
};
self.vec[ind] = s;
}
}
}
И как вы может убедиться сами, несовпадение времен жизни ссылок приведут к ошибкам компиляции:
error[E0597]: `x` does not live long enough
--> src/main.rs:17:24
|
17 | link: &x
| ^ borrowed value does not live long enough
...
21 | }
| - borrowed value only lives until here
|
note: borrowed value must be valid for the lifetime 'a as defined on the impl at 11:1...
--> src/main.rs:11:1
|
11 | impl<'a> S2<'a> {
| ^^^^^^^^^^^^^^^
И? Переведете кодовую базу в режим сопровождения и начнете писать новый код на Rust?
Собственно, почему бы и нет? )
Но, конечно, чтобы такое провернуть нужны средства и время. И главное — уверенность в том, что этот переход будет действительно стратегически выгоден. А без этого разумно оставить все как есть. В лучшем случае остается только следить и ждать. Но и в этом случае можно прогадать, время может оказаться упущенным.
Вообще-то это очень существенная деталь. Во втором случае будет невозможно использовать один и тот же обработчик в нескольких разных местах. Собственно,
handleв Go и понадобился, чтобы в том числе избежать дублирования кода обработки ошибок.Ну а то, что эти
handleсвязаны порядком следования, а не явными вызовами (как было бы в случае использования функций), по мне — так больше недостаток, чем достоинство. Чтобы понять, как будет обработана ошибка в конкретном месте, придется просматривать весь код выше и считатьhandle. Если между двумя разнымиcheckбудет находиться некоторыйhandle, то придется держать в голове то, что этиcheckобрабатываются по-разному, хотя синатуры обработчиков и строк вызовов об этом нам не говорят.… как только появится
map_err(handle),handleбудет участвовать в обработке ошибки.Вообще-то может, так как в качестве типа ошибки в
Result::Errможет использоваться любой тип.Вы так говорите, будто функция, принимающая
Result::Errможет обрабатывать что-то другое, кроме ошибки.Конечно, саму лямбду мы можем и не передать вовсе в
map_err. Но и просто наличиеhandleв Go еще не означает, что будет вызванcheck.Почему бы и нет:
Еще в Rust'е у типа
Resultесть методor_else, в котором обработчик может вернуть не только ошибку, но и Ok.Возможно, это разные типы характера. Для кого-то и работать из-под палки — это плюс. Лично мне больше нравится, когда необходимо воспитывать дисциплину и организовывать свою работу самостоятельно, потому что такой навык требуется и в личных делах.
Конечно, домашние должны понимать, что вы — на работе, даже если физически присутствуете дома. Лично я прекрасно уживаюсь с женой и ребенком в двухкомнатной квартире. В однокомнатной, если с ребенком, конечно будет сильно сложнее. Но среди моих знакомых-удаленщиков есть и такие, которые прекрасно работали, живя в одной комнате с женой и младенцем. Так что не для всех это проблема. А если вы не можете договориться со своей супругой (а такие случаи я знаю), то по-моему нужно задуматься: а с тем ли человеком вы вообще живете?
Ох, это не просто. Часто за "особые" (в глазах нанимателя) условия, требуют и особой отдачи. То есть, как только ты заикаешься о каких-то доп. условиях, сразу начинается торг. И вроде-бы в итоге договариваешься, но осадочек остается. Но даже если удастся без проблем получить себе поблажки от руководства, то напряженность в коллективе все равно остается. Я уже проходил через это, когда выторговал себе в офисе четырехдневную рабочую неделю.
По поводу поломки оборудования: пару раз у меня бывало, что на сутки отключали интернет. Это напрягало, но никаких санкций за это небыло. У всех случается, обычно к такому относятся с пониманием, если это не происходит слишком часто.
Такой формат общения сильно нужен на раннем этапе в профессии. Когда ты еще толком не умеешь решать серьезные проблемы самостоятельно. Во всяком случае мне это сильно помогло в первый год работы. Я бы советовал новичкам начинать работу с офиса, где пришлось бы работать бок-о-бок с опытными. Но дальше… Таким ментором уже становишься ты сам, и проблемы, если возникают, вполне нормально решаются через чат. Это чуть дольше, но зато остаются записи обсуждений на будущее.
Так это же плюсы :)
Насчет остального: маленький ребенок не сильно мешает (если тебе самому есть возможность им не заниматься во время работы) — проверил на себе. Отдельный кабинет — отличный вариант, но даже без него комфортнее, чем в офисном боксе. Когда любой подъем из-за стола для разминки или хождения туда-сюда во время размышлений начинают бесить всех присутствующих в офисе и создают тебе лишнее нервное напряжение.
Ну если получается (или необходимо по внешним причинам) работать всегда в одно и то же время — это неплохо. Лично мне нужен гибкий график для возможности расставить перерывы так, как мне удобно и как нужно для поддержания организма в рабочем состоянии. Например, если я работаю одним куском 4 часа, то после мне нужен двухчасовой перерыв как минимум, чтобы успеть не только поесть, но и восстановиться психически и физически.
Что касается обеспечения техникой… Я думаю 99% программистов и так ей обеспечены дома :) Дополнительно, я могу обеспечить себе стоячее и лежачее рабочее место, чего в офисе сделать крайне трудно.
А вот про неполноценность коммуникаций — ущерб чувствуешь только в плане отсутствия личного, внерабочего общения. Что же касается рабочего общения, то и в офисе оно ведется в 90% случаев дистанционно (по крайней мере у нас так было). Собственно, это послужило для меня одним из толчков к уходу из офиса: программировать за компьютером и переписываться в чате или электронной почте с коллегами я могу и из дома (или из парка/поезда/гостиницы) без ущерба для рабочего процесса.
Работая удаленно по гибкому графику, ты можешь сам планировать свой рабочий день и сам организовывать свое рабочее место. Это снимает кучу минусов офисной работы, хотя и добавляет один новый: развиваться в одиночестве труднее. Зато о большинстве остальных проблем можно забыть. Хорошо, что с каждым годом такой формат работы становится все популярнее.
Если не читали книгу Крайтона — настоятельно рекомендую ознакомиться, это эталон жанра «технотриллер». В фильме и десятой доли не показали того, что творилось в Парке с технической частью.
Правда на русском языке самый адекватный перевод от Нерсесянц и Шишовой 93-го года. Последующие — намного хуже, они там «листинг исходного кода» называют «страницей кодировок» и прочее в таком духе.
Можете вот здесь посмотреть примеры использования OpenGL из Rust напрямую (с помощью gl-rs): https://github.com/bwasty/learn-opengl-rs
А эта библиотека предоставляет прямой доступ к Vulkan: https://github.com/MaikKlein/ash
Вот вам простейший пример вулканического кода, выводящего на консоль свойства первого устройства:
Возможно стоило такой обзор отдельным хабропостом сделать. )
Есть два разных подхода к разработке фронтэнда: первый — это статически описывать разметку в шаблоне и добавлять вкрапления исполняемого кода; второй — это создавать фронтенд программно, а для упрощения кода по созданию отдельных элементов использовать вкрапления DSL-синтаксиса, описывающего структуру элементов. Вот как раз второй подход и используется в yew, как и в React/JSX.
Поясните, а зачем нам template engine, если мы можем компонетны с кусками html определять прямо в коде?
Вот как будет выглядеть такой код на Rust:
https://play.rust-lang.org/?gist=dd87625906cb942982ab1b4388695f2d&version=stable&mode=debug&edition=2015
И как вы может убедиться сами, несовпадение времен жизни ссылок приведут к ошибкам компиляции:
Собственно, почему бы и нет? )
Но, конечно, чтобы такое провернуть нужны средства и время. И главное — уверенность в том, что этот переход будет действительно стратегически выгоден. А без этого разумно оставить все как есть. В лучшем случае остается только следить и ждать. Но и в этом случае можно прогадать, время может оказаться упущенным.