У акторов достаточно большие накладные расходы, плюс с сильной типизацией в растё не очень удобно их использовать. Для сетевых приложений есть лучшие и более производительные подходы.
Не думаю что можно обобщить регистрацию синхронного и асинхронного кода без специализации. В вашем случае R в типаже NamedWith, то есть можно но нужно всегда конкретный тип указывать а с комбинаторами это не возможно пока не завезут impl Trait в типажах. либо пока не стабилизируют specialization.
Это о времени когда происходит проверка на соответствие типов. В динамических языках это происходит вотвремя исполнения, из-за этого легко получить ошибки в раньайме. Языки со статической типизацией выигрывают в этом.
Почему же? У меня похожий опыт, особенно на больших проектах. Статически типизированный язык очень помогает, другое дело на интерпретированном языке писать быстрей.
Я что-то не уловил про баги? Какие баги? Я довольно близко знаком с tokio, не могу припомнить никаких, по крайней мере никаких фиксов в комит логе не вижу. если для вас потеря 20% это нормальн для не меня это не приемлемо.
В этом то и прикол что hyper даунгрейдеулся на версию tokio-core="=0.1.12" в которой tokio не используется. Я сделал тоже самое, и в своих проектах сделал также. Каждому своё конечно, но как-то терять 20% не очень
Моё многопоточное приложение стало на 20% медленнее. Если что tokio-core не ограничивает количество потоков. К тому же забавно смотреть как hyper откатывает tokio на старую версию tokio-core чтобы в бенчмарках выглядеть лучше.
зато выглядит круто, HKT, тайп классы, карринг. ну и всегда будешь востребован, никто же не сможет разобраться что там происходит без тебя
Тестовый проект уже работает. Сейчас работаю над большим проектом.
Я главный разработчик actix. Активно использую раст и actix в azure iot. Хотя пруфы показать не смогу
У акторов достаточно большие накладные расходы, плюс с сильной типизацией в растё не очень удобно их использовать. Для сетевых приложений есть лучшие и более производительные подходы.
Не думаю что можно обобщить регистрацию синхронного и асинхронного кода без специализации. В вашем случае
Rв типаже NamedWith, то есть можно но нужно всегда конкретный тип указывать а с комбинаторами это не возможно пока не завезут impl Trait в типажах. либо пока не стабилизируют specialization.Работа с базой происходит в отдельном потоке, обработчик http запроса асинхронный и останавливаться не будет
Как же? Пишу на расте, хотя и не хочется но клепаю много логических ошибок :)
Никто с этим не спорит. Статическая типизация не спасёт от логических ошибок. Но рефакторинг делать намного проще со статический типизацией
Это о времени когда происходит проверка на соответствие типов. В динамических языках это происходит вотвремя исполнения, из-за этого легко получить ошибки в раньайме. Языки со статической типизацией выигрывают в этом.
Это о статической типизации
Хорошо, вы правы.
Я предполагаю что автор описывал популярные языки, и обращался к тем кто их использует повседневно.
Почему же? У меня похожий опыт, особенно на больших проектах. Статически типизированный язык очень помогает, другое дело на интерпретированном языке писать быстрей.
Я что-то не уловил про баги? Какие баги? Я довольно близко знаком с tokio, не могу припомнить никаких, по крайней мере никаких фиксов в комит логе не вижу. если для вас потеря 20% это нормальн для не меня это не приемлемо.
В этом то и прикол что hyper даунгрейдеулся на версию tokio-core="=0.1.12" в которой tokio не используется. Я сделал тоже самое, и в своих проектах сделал также. Каждому своё конечно, но как-то терять 20% не очень
Моё многопоточное приложение стало на 20% медленнее. Если что tokio-core не ограничивает количество потоков. К тому же забавно смотреть как hyper откатывает tokio на старую версию tokio-core чтобы в бенчмарках выглядеть лучше.
Единственно tokio медленней на 20% чем tokio-core, а так все хорошо
Да нету там ничего общего, разве что epoll and kqueue
"(Any) -> Any?" как-то хреново выглядит для статически типизированного языка
Вот видео в митапа, в котором про то что dropbox делает. Потом та же команда искала rust разработчика
https://air.mozilla.org/rust-meetup-may-2017/
К сожалению, пока нет. Сложно в большой компании продавить новый язык. Есть один проект в разработке, возможно он пойдёт в продакшен на actix’е