Хм, ну я бы не говорил так однозначно, что «компиляция» — это английское слово :) Оно есть ещё у Даля.
Сборка (в отношении программ), вообще говоря, будет «build». Обычно сборка включает в себя, в частности, компиляцию и линковку (кстати, вспомнил ещё один синоним linking — компоновка).
Сборка исполняемого файла — это линковка (linking, «редактирование связей»). Трансляция — перевод программы на любом языкы в программу на любом другом языке. Компиляция — подмножество трансляции, когда перевод осуществляется с высокоуровневого языка в низкоуровневый, чаще всего машинный.
У акторов нет общих данных. Это, в общем-то, ключевой момент этой парадигмы. Но связи со stateless действительно нет никакой — у самих акторов вполне себе может быть состояние.
Прошу прощения, что влазию в дискуссию)
Long polling != long pooling. Второго термина вообще не существует, насколько я знаю. Long polling так называется, потому что клиент poll'ит (опрашивает) сервер на наличие эвентов, а long — потому что это длинное HTTP-соединение.
Странно, что Future'ы обозвали Promise'ами. Обычно под Promise понимается особый род Future, который может быть завершён юзерским кодом. Они нужны для создания собственных Future'ов или для написания комбинаторов над Future'ами. Но Promise'ы в JS такой фичи не имеют, ну или, по крайней мере, из статьи этого не видно.
В математике существует достаточно обобщений базовых арифметических операций. Вся абстрактная алгебра — включая теории групп, полей, колец и прочих структур, — на этом построена. Там есть всевозможные обобщения сложения, умножения, вычитания, деления, возведения в степень, взятия корня и всего остального. Чем оно вас не устраивает?
Спасибо за перевод.
Только всё-таки, насколько я знаю, каноническим переводом слайсов на русский является «срез». Имхо, «срез» больше передаёт суть этого явления.
Хм, а если закончил специалитет и обучаюсь в аспирантуре, это «Специалитет (оконченное)» или «Аспирантура (неоконченное)»? Или последнее только для тех, кто аспирантуру бросил?
Да я пока только язык изучаю, кондишны вот, например, ни разу ещё не использовал) но идея хорошая, спасибо. Может, и в самом деле что-нибудь про Rust напишу, как будет время…
Ну всё-таки «systems programming language» — это не написание демонов, а системное программирование — драйверы там, ОС, низкий уровень и прочее. Демоны и системное программирование могут пересекаться, да, но это не одно и то же. И вот как раз Rust к «systems programming» ближе, чем Go)
Очевидно, что $* развернул аргументы неправильно. Для передачи всего набора аргументов в другой скрипт всегда нужно использовать "$@" — именно так, с кавычками.
Насколько я понимаю, к сожалению, сейчас со стектрейсами всё не очень радужно. Если возникает ошибка, приводящая к раскрутке стека и завершению таски, то мы увидим только то место, где она произошла — имя файла и строку, без стектрейса. Правда, у меня такое ощущение, что так происходит из-за того, что я не совсем правильно собрал сам компилятор. Странно, но я не могу найти упоминаний про проблемы со стектрейсом в интернете. Есть пара упоминаний годичной давности про проблемы со стектрейсом, если LLVM собран не с теми флагами, но я хз насколько информация актуальна. Спрошу в списке рассылки, наверное.
Насчёт стектрейсов в кондишнах — это вряд ли возможно, потому что их обработка не приводит к раскрутке стека. Но вы можете передавать в обработчики произвольные даные (и получать обратно тоже), это должно скомпенсировать проблему.
Обработка ошибок в Rust — смесь разных подходов из функциональных языков. Там на самом деле ничего сложного нет.
1. если функция может вернуть как успешный результат, так и ошибку, причём нам не важна конкретная ошибка (или ошибка может быть только одна — вроде отсутствия ключа в мапе), то нужно использовать Option — это как тип Maybe в хаскелле или Option в Scala;
2. если функция может вернуть как успешный результат, так и ошибку, причём конкретная ошибка важна, и разные виды ошибок нужно обрабатывать по-разному (например, файл нельзя открыть из-за неправильно указанного пути или нет прав на это), то нужно использовать Result<T, E> — это как тип Either или монада Error в Haskell или Either/Try в Scala;
3. если произошло что-то совсем терминальное, и нет никакого способа восстановить нормальную работу задачи, то нужно использовать fail!() для обваливания текущего потока. Это что-то типа неотлавливаемых внутри потока исключений — снаружи потока их можно отловить и обработать. Это похоже на процессы Erlang;
4. если произошла ошибка, после которой всё же можно продолжить, но произошла она в глубине кода и продолжать тоже нужно там же, а не экстренно завершаться, то нужно использовать conditions. Тут немного трудно придумать краткий пример, можно посмотреть описание кондишнов в документации. Кто знаком с Common Lisp, сразу поймёт о чём речь, хотя в Rust кондишны немного послабее, чем в CL. По сути, это такие исключения, обработчики для которых ставятся снаружи кода, который может получить ошибку, но выполняются непосредственно по месту ошибки. Если ни один обработчик не установлен, получаем пункт 3. Это довольно интересная концепция, непривычная после обычных развёртывающих стек исключений.
Как видите, тоже четыре пункта :)
Блин, хабр почему-то не понимает нумерованный список :(
Да, по какой-то причине при первом прочтении документации Rust кажется именно что переинженереным. Но когда попробуешь на нём что-нибудь написать и когда поймёшь идеологию языка и его основные паттерны, то это ощущение гарантированно пропадает. Иногда даже становится непонятно, как без некоторых вещей живут в других языках :) Со Scala, кстати, то же самое, даже ещё в большей степени. Но в Scala совершенно необязательно знать и применять самые сложные вещи вроде path-dependent types или higher kinds. Не так давно читал краткую статью про уровни Scala-программистов, но ссылку потерял уже :( там это как раз объяснялось.
Да, есть такое дело. Это из-за отражения. Вроде бы даже бинарники на Go нежелательно подвергать stirp'у, а то могут сломаться библиотеки, которые пользуются отражением.
Кстати, это один из минусов раста пока что — отсутствие отражения в принципе. По крайней мере, я пока не видел, как его использовать. Другое дело, что с наличием трейтов как в расте не так уж и часто оно и нужно.
На мой взгляд, Go был бы идеальным, если бы в нём были хоть какие-нибудь дженерики. Вот их очень не хватает. А так Go действительно классный язык.
Сборка (в отношении программ), вообще говоря, будет «build». Обычно сборка включает в себя, в частности, компиляцию и линковку (кстати, вспомнил ещё один синоним linking — компоновка).
Long polling != long pooling. Второго термина вообще не существует, насколько я знаю. Long polling так называется, потому что клиент poll'ит (опрашивает) сервер на наличие эвентов, а long — потому что это длинное HTTP-соединение.
Только всё-таки, насколько я знаю, каноническим переводом слайсов на русский является «срез». Имхо, «срез» больше передаёт суть этого явления.
$*для передачи параметров, вы рискуете нарваться на проблемы, если в аргументах будут пробелы. Простой тест:Вызов скрипта как
./script.sh a b c dвыдастА вызов его же как
./script.sh a b "c d"выдастОчевидно, что
$*развернул аргументы неправильно. Для передачи всего набора аргументов в другой скрипт всегда нужно использовать"$@"— именно так, с кавычками.Насчёт стектрейсов в кондишнах — это вряд ли возможно, потому что их обработка не приводит к раскрутке стека. Но вы можете передавать в обработчики произвольные даные (и получать обратно тоже), это должно скомпенсировать проблему.
1. если функция может вернуть как успешный результат, так и ошибку, причём нам не важна конкретная ошибка (или ошибка может быть только одна — вроде отсутствия ключа в мапе), то нужно использовать Option — это как тип Maybe в хаскелле или Option в Scala;
2. если функция может вернуть как успешный результат, так и ошибку, причём конкретная ошибка важна, и разные виды ошибок нужно обрабатывать по-разному (например, файл нельзя открыть из-за неправильно указанного пути или нет прав на это), то нужно использовать Result<T, E> — это как тип Either или монада Error в Haskell или Either/Try в Scala;
3. если произошло что-то совсем терминальное, и нет никакого способа восстановить нормальную работу задачи, то нужно использовать fail!() для обваливания текущего потока. Это что-то типа неотлавливаемых внутри потока исключений — снаружи потока их можно отловить и обработать. Это похоже на процессы Erlang;
4. если произошла ошибка, после которой всё же можно продолжить, но произошла она в глубине кода и продолжать тоже нужно там же, а не экстренно завершаться, то нужно использовать conditions. Тут немного трудно придумать краткий пример, можно посмотреть описание кондишнов в документации. Кто знаком с Common Lisp, сразу поймёт о чём речь, хотя в Rust кондишны немного послабее, чем в CL. По сути, это такие исключения, обработчики для которых ставятся снаружи кода, который может получить ошибку, но выполняются непосредственно по месту ошибки. Если ни один обработчик не установлен, получаем пункт 3. Это довольно интересная концепция, непривычная после обычных развёртывающих стек исключений.
Как видите, тоже четыре пункта :)
Блин, хабр почему-то не понимает нумерованный список :(
Кстати, это один из минусов раста пока что — отсутствие отражения в принципе. По крайней мере, я пока не видел, как его использовать. Другое дело, что с наличием трейтов как в расте не так уж и часто оно и нужно.
На мой взгляд, Go был бы идеальным, если бы в нём были хоть какие-нибудь дженерики. Вот их очень не хватает. А так Go действительно классный язык.
Мне кажется, или тут что-то не то?