Если язык в принципе плохо применим для прикладной разработки, то никакой прикладной экосистемы у него не будет. Если же сам язык для этого подходит, то со временем разовьется и его экосистема.
Я написал статью о том, чем Rust как язык силен в том числе в прикладной разработке. В надежде на то, что будет больше применений Rust не только для решения системных, но и прикладных задач. Следствием чего станет развитие его прикладной экосистемы.
Вам это не нравится? Что же, поклонником Rust вас не назвать, скорее — противником. А если ты делаешь что-то, что не нравится твоему противнику, то это значит, что ты поступаешь правильно. Вот о чем мне говорят ваши комментарии.
Да, все так. GAT не заменяет HKT, но это уже хоть что-то на пути в эту сторону. Ведется поиск, идут дискуссии и эксперименты. То есть имеются ориентиры, и развитие языка направлено к ним, хоть достигнуть некоторых из них и не получится (либо мы пока не знаем как).
Проблема не в том, что вы можете принять в функцию примитивный тип, а в том, что в большинстве случаев в других прикладных языках вы не можете сделать иначе.
Потому что как только вы перейдете от примитивных типов к объектам, ваша программа может просесть по производительности в разы. С этим приходится считаться и жертвовать удобством работы с "высокоуровневыми" производными типами в пользу "низкоуровневых" примитивных типов.
Если для этого и подобного мне нужно каждый раз писать собственную [системную] библиотеку, этот язык не годится для прикладного программирования.
Простите, не пойму вашей логики. Но ведь все библиотеки, которые можно использовать в любом зыке, кто-то же их когда-то написал? То есть для всего, что вам нужно — написана библиотека, а значит, следуя вашей логике, "для подобного пришлось всякий раз написать библиотеку", то есть ни один язык не годится для прикладного программирования, так что ли?
OLE там родное, потому что оно изначально под C++ и делалось.
Извините, если никто не будет использовать язык в прикладных целях, то откуда в его экосистеме появятся развитые библиотеки для прикладного программирования? Вы путаете возможности самого языка и его удобство для прикладной разработки с развитостью экосистемы. Экосистема у Rust пока еще не достаточно хорошо развита, хотя и развивается бешеными темпами.
Я вам не могу написать реально работающего примера, так как программированием под Windows не занимаюсь. Из примера выше должна быть понятна общая идея: в Rust есть низкоуровневые возможности, а значит в принципе реализовать можно работу со всем, чем угодно, при этом можно сделать удобный и безопасный высокоуровневый API.
На вскидку, я думаю, что внешний API может быть представлен в виде атрибута, который вешается на статически определенную структуру. А если вам требуется динамика и на момент компиляции вы точно не знаете структуру данных — то дополнительно можно сделать API для работы с такими данными на основе АТД. Так сделано в библиотеке serde_json: вы можете распарсить JSON из строки в АТД Value, либо в собственную структуру, если формат JSON-объекта известен заранее.
Обратите внимание, что в исходном примере на Delphi динамика скорее мешает — она никак по-сути не используется, все записано статически, а контроля типов при этом нет.
Сейчас все-таки ситуация меняется.
Напишите статью с контр-аргументами, с удовольствием почитаю.
Если язык в принципе плохо применим для прикладной разработки, то никакой прикладной экосистемы у него не будет. Если же сам язык для этого подходит, то со временем разовьется и его экосистема.
Я написал статью о том, чем Rust как язык силен в том числе в прикладной разработке. В надежде на то, что будет больше применений Rust не только для решения системных, но и прикладных задач. Следствием чего станет развитие его прикладной экосистемы.
Вам это не нравится? Что же, поклонником Rust вас не назвать, скорее — противником. А если ты делаешь что-то, что не нравится твоему противнику, то это значит, что ты поступаешь правильно. Вот о чем мне говорят ваши комментарии.
Силен сам Rust или в каких областях больше развита его экосистема?
Да, все так. GAT не заменяет HKT, но это уже хоть что-то на пути в эту сторону. Ведется поиск, идут дискуссии и эксперименты. То есть имеются ориентиры, и развитие языка направлено к ним, хоть достигнуть некоторых из них и не получится (либо мы пока не знаем как).
Этот человек — из "группы поддержки" языка D, как я понял. Так что да, Rust для D все-таки конкурент и у D дела пока идут хуже, чем у Rust.
Можно посмотреть на Haskell и представить, как это все может заработать в императивном языке, заточенном под эффективность и без сборщика мусора )
Если серьезно, то одного единственного документа, наверное, нет. Но кое-что вырисовывается из набора RFC: https://github.com/rust-lang/rfcs/tree/master/text
Им пока и как системным не очень сильно пользуются.
В Rust не принято использовать полиморфизм подтипов, вместо этого есть параметрический полиморфизм.
Думаю, скорее ее нет потому, что она пока особо никому и не нужна.
Проблема не в том, что вы можете принять в функцию примитивный тип, а в том, что в большинстве случаев в других прикладных языках вы не можете сделать иначе.
Потому что как только вы перейдете от примитивных типов к объектам, ваша программа может просесть по производительности в разы. С этим приходится считаться и жертвовать удобством работы с "высокоуровневыми" производными типами в пользу "низкоуровневых" примитивных типов.
Как небыло, так и нет. И не будет )
Но у меня к вам 2 вопроса:
1) Что вы понимаете под ООП?
2) А это вам точно нужно?
Простите, не пойму вашей логики. Но ведь все библиотеки, которые можно использовать в любом зыке, кто-то же их когда-то написал? То есть для всего, что вам нужно — написана библиотека, а значит, следуя вашей логике, "для подобного пришлось всякий раз написать библиотеку", то есть ни один язык не годится для прикладного программирования, так что ли?
OLE там родное, потому что оно изначально под C++ и делалось.
Извините, если никто не будет использовать язык в прикладных целях, то откуда в его экосистеме появятся развитые библиотеки для прикладного программирования? Вы путаете возможности самого языка и его удобство для прикладной разработки с развитостью экосистемы. Экосистема у Rust пока еще не достаточно хорошо развита, хотя и развивается бешеными темпами.
Прочитайте пожалуйста весь раздел статьи, из которого взят этот пример. Особенно — последний абзац.
Парсер языка Rust, кстати, относительно простой.
Здесь C++ тоже демонстрирует хороший дизайн, но исходный пример со
sleepвзят из PHP.Вот вы и попались: "так как обычно sleep в мс". Пример взят из проблемных мест PHP, там в sleep передается задержка в секундах.
Ну, в этом же и была его концепция, если кратко :)
Я вам не могу написать реально работающего примера, так как программированием под Windows не занимаюсь. Из примера выше должна быть понятна общая идея: в Rust есть низкоуровневые возможности, а значит в принципе реализовать можно работу со всем, чем угодно, при этом можно сделать удобный и безопасный высокоуровневый API.
На вскидку, я думаю, что внешний API может быть представлен в виде атрибута, который вешается на статически определенную структуру. А если вам требуется динамика и на момент компиляции вы точно не знаете структуру данных — то дополнительно можно сделать API для работы с такими данными на основе АТД. Так сделано в библиотеке
serde_json: вы можете распарсить JSON из строки в АТДValue, либо в собственную структуру, если формат JSON-объекта известен заранее.Обратите внимание, что в исходном примере на Delphi динамика скорее мешает — она никак по-сути не используется, все записано статически, а контроля типов при этом нет.