Статья просто великолепна, спасибо большое! Очень здорово и очень классным языком рассказано про то, как удобно и быстро на Go делать достаточно сложные приложения.
1. Видимо, чтобы не спамить сервер запросами.
2. +1
3. То же самое, что не делать close() в Java. ИМХО ресурсы всегда надо за собой подчищать, это вообще должно войти в привычку.
4. Нет, нету. А зачем, если Set по, сути, есть Map в {1, 0}?
Написал бы в личку, но не нашёл, как :( поэтому пишу здесь. Может быть, кто-то подскажет, как писать в личку?
В английском, как правило, названия каких-то произведений или работ, а также довольно часто и названия разделов/секций в статьях и работах пишут С Большой Буквы Каждое Слово, за Исключением Предлогов. В русском языке такой традиции нет, поэтому названия статей, например, нужно переводить «Как обычно, но всё название в кавычках». Для заголовков справедливо то же самое, только без кавычек. Если оставляют регистр букв как в оригинале, то это очень режет глаз.
А ещё PDD-NOS — это совершенно точно не «не иначе указанная», это скорее что-то вроде «Неопределённое первазивное расстройство психического развития». Но это тоже не совсем корректно. Поэтому такие вещи нужно искать в специализированной литературе.
Такой геймпад появился не сразу, а только вместе с PSone. До него был PSX, у геймпада которого аналоговых стиков не было. Мой брат на нём играл в Medal of Honor первый. До сих пор не понимаю, как :)
Никогда не понимал вообще, как можно в игры от первого лица играть с контроллером. А такие игры были ещё как минимум на PS1, когда даже аналоговых стиков не было…
Контроллер просто прелесть. Valve просто молодцы, что придумали что-то свежее и необычное.
Ага, есть — viewnior называется. Перешёл на неё с gpicview (он жрёт ОЧЕНЬ много памяти, если смотреть много картинок подряд, особенно если они есть анимированные gif), очень удобна и легковесна.
Юникс, всё же, это немного другое. Проектирование изолированных сущностей, взаимодействующих между собой стандартными способами и решающих каждый свою задачу — это общий принцип, он применим и к ООП, и к комплексам отдельных программ.
То, что описывает автор, всё-таки, есть самая натуральная акторная модель:
1. отдельные сущности;
2. обмениваются сообщениями;
3. работают в отдельных потоках;
4. решают свои отдельные задачи.
Посмотрел на пакет container/heap. Очень интересный подход, практически не свойственный другим языкам, однако дженерики там не причём. Он вполне реализуется на интерфейсах той же джавы, пусть и с некоторыми костылями, связанными с отсутствием в Java решения expression problem.
А вот то, что методы Push() и Pop() тамошнего интерфейса Interface используют interface{} в качестве типа для данных — это очень печально и как раз есть то, с чем бы дженерики очень помогли. В некотором роде, их отсутствие даже странно, потому что Go позиционируется как язык с довольно строгой системой типов (отсутствие неявных преобразований тому подтверждение). И то, что для написания достаточно обобщённого кода приходится обращаться к динамическим кастам, сильно разочаровывает.
А параметрический полиморфизм — это и не есть фича функциональных языков)
У Go меньше возможностей в языке заложено, он проще. Про стабильность уже говорили, в Go код генерируется достаточно качественный. С другой стороны, код на Rust поддерживает за счёт системы типов и указателей больше инвариантов => больше безопасность, особенно в случае многопоточности. Плюс в Rust очень удобные ADT и паттерн-матчинг на них.
Inherent mutability — тоже очень интересная фича, я ни в одном другом языке такого не видел. Сначала может показаться, что с этим непонятно как жить, но гибкий механизм impl'ов здесь спасает.
Но вот что мне больше всего не нравится в Go — это отсутствие любого рода дженериков. Это очень серьёзное упущение для современного языка. В Rust дженерики есть, и достаточно мощные.
Вообще раст — очень годный язык. Я следил за ним почти с самого его появления, и с тех пор он очень сильно поменялся, причём в лучшую сторону. Многие лишние фичи выкинули, новые более удобные добавили, что-то привели в гораздо более приятную форму.
Сейчас язык потихоньку устаканивается, по крайней мере, с внешней стороны. Кстати, вот буквально в июне его перевели на новый рантайм, написанный на самом расте. Это показатель того, что язык довольно-таки пригоден для системных приложений.
Но, как правильно было сказано, он сейчас довольно трудно юзабельный на нетривиальных вещах. И дело тут даже не в «немного» непривычной семантике (из наличия unique-типов следует очень много весёлых вещей, вроде явных lifetime'ов у borrowed pointer'ов и средств работы с ними), а в общей сырости компилятора. При использовании каких-нибудь сложных штук есть очень большой риск получить ICE, Internal Compiler Error. Но над этим работают очень активно, и баги на багтрекере принимаются от всех желающих.
Ну, на самом деле именно из этого куска наличие стирания типов не следует (где-нибудь в скале без дополнительных рефлективных действий тоже ничего не сделаешь с параметром типа T), но по факту да, в Rust присутствует стирание типов. Они ближе к шаблонам, чем к дженерикам.
Если честно, никогда не понимал, почему reflection в этом контексте переводят рефлексией. Имхо, «отражение» гораздо более точно передаёт суть этого явления — программа «видит» некое представление, отражение себя. Кстати, именно поэтому в Scala в новой reflection-библиотеке основные объекты, с помощью которых reflection и производится, называются зеркалами (mirror) — ClassMirror, MethodMirror и прочие.
Поздравляю, вы изобрели монаду Error! А в Scala, например, такая конструкция называется Try.
Ещё несколько шагов (введение flatMap-метода и других полезных функций, кпрощение внутренней структуры вроде совершенного лишнего флажка successful), и получится весьма популярное в функциональном программировании решение для обработки ошибок.
flow не подойдёт, потому что flow — это скорее процесс «течения», в отличие от stream, который как раз есть сущность этого самого течения.
Тут ещё надо вспомнить, что в русском языке потоки ещё могут означать потоки выполнения, те что threads…
Но, имхо, I/O streams и streams данных достаточно различаются, и по контексту всегда можно понять, что есть что. То же касается и потоков в русском языке.
Получал не так давно загран в УФМС — там на всех компах KDE3. По крайней мере, интерфейс программы, в которой вводились мои данные, очень напоминал стандартную тему KDE3 для Qt3. А вот в пенсионном — винда, хз только, лицензионная или нет.
2. +1
3. То же самое, что не делать close() в Java. ИМХО ресурсы всегда надо за собой подчищать, это вообще должно войти в привычку.
4. Нет, нету. А зачем, если Set по, сути, есть Map в {1, 0}?
В английском, как правило, названия каких-то произведений или работ, а также довольно часто и названия разделов/секций в статьях и работах пишут С Большой Буквы Каждое Слово, за Исключением Предлогов. В русском языке такой традиции нет, поэтому названия статей, например, нужно переводить «Как обычно, но всё название в кавычках». Для заголовков справедливо то же самое, только без кавычек. Если оставляют регистр букв как в оригинале, то это очень режет глаз.
А ещё PDD-NOS — это совершенно точно не «не иначе указанная», это скорее что-то вроде «Неопределённое первазивное расстройство психического развития». Но это тоже не совсем корректно. Поэтому такие вещи нужно искать в специализированной литературе.
Контроллер просто прелесть. Valve просто молодцы, что придумали что-то свежее и необычное.
То, что описывает автор, всё-таки, есть самая натуральная акторная модель:
1. отдельные сущности;
2. обмениваются сообщениями;
3. работают в отдельных потоках;
4. решают свои отдельные задачи.
Этот способ написания программ уже очень давно используется, например, в рамках языка Erlang или в Scala с помощью замечательной библиотеки Akka.
А вот то, что методы
Push()иPop()тамошнего интерфейсаInterfaceиспользуютinterface{}в качестве типа для данных — это очень печально и как раз есть то, с чем бы дженерики очень помогли. В некотором роде, их отсутствие даже странно, потому что Go позиционируется как язык с довольно строгой системой типов (отсутствие неявных преобразований тому подтверждение). И то, что для написания достаточно обобщённого кода приходится обращаться к динамическим кастам, сильно разочаровывает.А параметрический полиморфизм — это и не есть фича функциональных языков)
Inherent mutability — тоже очень интересная фича, я ни в одном другом языке такого не видел. Сначала может показаться, что с этим непонятно как жить, но гибкий механизм impl'ов здесь спасает.
Но вот что мне больше всего не нравится в Go — это отсутствие любого рода дженериков. Это очень серьёзное упущение для современного языка. В Rust дженерики есть, и достаточно мощные.
Сейчас язык потихоньку устаканивается, по крайней мере, с внешней стороны. Кстати, вот буквально в июне его перевели на новый рантайм, написанный на самом расте. Это показатель того, что язык довольно-таки пригоден для системных приложений.
Но, как правильно было сказано, он сейчас довольно трудно юзабельный на нетривиальных вещах. И дело тут даже не в «немного» непривычной семантике (из наличия unique-типов следует очень много весёлых вещей, вроде явных lifetime'ов у borrowed pointer'ов и средств работы с ними), а в общей сырости компилятора. При использовании каких-нибудь сложных штук есть очень большой риск получить ICE, Internal Compiler Error. Но над этим работают очень активно, и баги на багтрекере принимаются от всех желающих.
Если честно, никогда не понимал, почему reflection в этом контексте переводят рефлексией. Имхо, «отражение» гораздо более точно передаёт суть этого явления — программа «видит» некое представление, отражение себя. Кстати, именно поэтому в Scala в новой reflection-библиотеке основные объекты, с помощью которых reflection и производится, называются зеркалами (mirror) — ClassMirror, MethodMirror и прочие.
Ещё несколько шагов (введение flatMap-метода и других полезных функций, кпрощение внутренней структуры вроде совершенного лишнего флажка successful), и получится весьма популярное в функциональном программировании решение для обработки ошибок.
По-моему, эти утверждения слегка противоречат друг другу, нет?
Тут ещё надо вспомнить, что в русском языке потоки ещё могут означать потоки выполнения, те что threads…
Но, имхо, I/O streams и streams данных достаточно различаются, и по контексту всегда можно понять, что есть что. То же касается и потоков в русском языке.