Comments 38
Не очень очевидный список. Visual Basic .NET — седьмой (выше JavaScript), и при этом за год поднялся на 6(!) позиций.
Objective С упал с 3 места на 14, но при этом Swift только 15. Не могли же все Apple разработчики пропасть куда-то.
Ну а Rust поздравляю и желаю дальнейших успехов.
Objective С упал с 3 места на 14, но при этом Swift только 15. Не могли же все Apple разработчики пропасть куда-то.
Ну а Rust поздравляю и желаю дальнейших успехов.
Если я правильно понимаю, они просто считают сколько было поисковых запросов по языку.
То есть если в каком-то языке (назовем его RHR) все двусмысленно и не очевидно, молчаливые ошибки и возвращаемые нули вместо исключений и по нему много гуглят, а в другом языке (назовем его Crypton) все понятно, просто и выразительно, что даже гуглить приходится меньше, последний станет ниже в позициях?
Ваш пример хорошо иллюстрируется этим рейтингом:
Как видите, популярность Rust скорее «позитивная», чем «негативная».
Как видите, популярность Rust скорее «позитивная», чем «негативная».
Все равно непонятно, почему это VB.NET так вырос. Допустим, относительно высокий уровень можно объяснить наличием legacy. Но рост на 40% за 2015 год?
Просто индекс TIOBE — плохой. Мне кажется RedMonk куда более адекватным: redmonk.com/sogrady/category/programming-languages
В нем Go на 15 месте, Rust — на 48.
В нем Go на 15 месте, Rust — на 48.
Как фанат С++ могу сказать только одно:
У меня когнитивный диссонанс, Rust руками Go атакует C++.
У меня когнитивный диссонанс, C++ использует printf.
Хм. Верное замечание. Сработала привычка — я не очень-то люблю std::cout с его перегруженными операторами.
Как вас при таких еретичных взглядах коллеги по языку ещё не придали анафеме?
Коллеги приветствовали и поддержали.
— Во-первых, перегруженные операторы для девяноста процентов классов — спорная фича. Она делает код короче, это да. Но, с другой стороны, часто усложняет его восприятие и таит в себе подводные камни. Даже в случаи работы с математическими векторами на работе не использовали перегруженные операторы. Это делалось чтобы было визуально удобнее понять количество операций и не угадывать постоянно типы переменных, с которыми происходят математические действия.
— Во-вторых, форматированный вывод в половине случаев нужен для логирования, которое в релизе должно быть отключено. Отключение на уровне компиляции удобнее всего делать через макросы. И тут — если не хочется какого-нибудь очередного синтаксического извращения — перегруженные операторы никак не помогут.
На самом деле одна из проблем С++ это, на мой взгляд, наследие подходов С с его стремлением к лаконизму и, одновременно, к оптимизациям всего и вся в ущерб прозрачности и предсказуемости кода. Отсюда всякие безумные пляски с шаблонами к месту и без, операторы, возвращающие классы с операторами, использование идентификаторов в стиле mn_str, и проч.
После года программирования на objective-C, я излечился от желания делать код короче и он сразу стал намного прозрачнее. С желанием всё оптимизировать бороться труднее, но тут помогают архитектурные подходы. Оптимизированный код можно изгнать в специальные резервации фрического кода и тогда с ним будет иметь дело лишь кучка избранных, а обычные программисты будут жить в неведении о таких тайнах, используя лишь няшный интерфейс.
— Во-первых, перегруженные операторы для девяноста процентов классов — спорная фича. Она делает код короче, это да. Но, с другой стороны, часто усложняет его восприятие и таит в себе подводные камни. Даже в случаи работы с математическими векторами на работе не использовали перегруженные операторы. Это делалось чтобы было визуально удобнее понять количество операций и не угадывать постоянно типы переменных, с которыми происходят математические действия.
— Во-вторых, форматированный вывод в половине случаев нужен для логирования, которое в релизе должно быть отключено. Отключение на уровне компиляции удобнее всего делать через макросы. И тут — если не хочется какого-нибудь очередного синтаксического извращения — перегруженные операторы никак не помогут.
На самом деле одна из проблем С++ это, на мой взгляд, наследие подходов С с его стремлением к лаконизму и, одновременно, к оптимизациям всего и вся в ущерб прозрачности и предсказуемости кода. Отсюда всякие безумные пляски с шаблонами к месту и без, операторы, возвращающие классы с операторами, использование идентификаторов в стиле mn_str, и проч.
После года программирования на objective-C, я излечился от желания делать код короче и он сразу стал намного прозрачнее. С желанием всё оптимизировать бороться труднее, но тут помогают архитектурные подходы. Оптимизированный код можно изгнать в специальные резервации фрического кода и тогда с ним будет иметь дело лишь кучка избранных, а обычные программисты будут жить в неведении о таких тайнах, используя лишь няшный интерфейс.
Извините, у вас EXC_BAD_ACCESS отклеился.
Ну ржавчина начинает потихоньку проникать в мозги разработчиков C++, уже вовсю обсуждают введение lifetime'ов.
Неужели Go такой непопулярный, судя по этому рейтингу…
Да, это очень странно, что Go не попал а Rust попал
Так у него := как у паскалей! Если убрать это двоеточие, то язык ждёт успех. Мы недавно не сговариваясь, сидя удалённо решили использовать на новом проекте раст когда все помимо теоритических знаний о языке — посмотрели на синтаксис.
Ничего не понятно…
Да нет, просто у Роба Пайка нет бороды. Из троих создателей языка только у Кена Томпсона есть.
</irony>
</irony>
Синтаксис очень на любителя, и видимо влияет ваш бекграунд языка с каким-то похожим синтаксисом.
Если верить правилам оценки язык активно используется в реальной работе:
Скажу по опыту, стал использовать Rust примерно пару месяцев назад и я практически сразу заметил интересную закономерность: сообщество Rust очень активное. Крейты выходят и обновляются так быстро, что я не успел почувствовать недостаток функционала, бывало, думаешь над проблемой, и буквально через день-два появляется что-то подобное в виде оформленного продукта. Например, драйвер MongoDB, пока разбирался в Rust, драйвер созрел до вполне стабильного, работает хорошо, структура удобная.
Но даже когда чего-то не хватает, я просто затягиваю форк и одной командой собираю тот же проект с бенчмарками, тестами. Это позволяет мне его «подпилить» и вернуть как PR назад на github. Это очень круто ускоряет разработку на языке, который по-сути системный.
Или когда я сталкивался отсутствием какого-то биндинга, я просто из голого Rust вызывал нужный мне нативный метод (требовался HDF5 и Lua, хотя их уже покрыли удобными обёртками). Не бывает, в принципе, такого, что библиотека с трудом собирается под Win. Как это бывает в том же Python. Переносимость просто отличная.
При этом компилятор очень хитромудрый, чувствую что пишу на OCaml, если программа скомпилировалась, она на 99% правильно работает. В этом, конечно, помогает монадная обработка ошибок, отсутствие исключений. Ошибки чисто технически нельзя оставить «на потом». Есть, конечно, unwrap, но на нём не уедешь, далеко, и почти сразу его приходится заменить на человеческий код.
В итоге, комфорт и удобство в работе вынуждают меня генерировать море рабочего кода, которым иногда удаётся поделиться, отправив PR. Язык просто лёг к рукам, хотя до этого я очень долго себя убеждал, что люблю сусликов и Go, наклеечки везде клеил…
Что касается убийцы всех и вся, и что якобы у C++ скоро повиснет указатель, то тут очень трудно что-то прогнозировать. Я люблю Rust больше, но по сути это OCaml, в который добавили фигурные скобочки, чтобы народ мог похоливарить. Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
Скажу по опыту, стал использовать Rust примерно пару месяцев назад и я практически сразу заметил интересную закономерность: сообщество Rust очень активное. Крейты выходят и обновляются так быстро, что я не успел почувствовать недостаток функционала, бывало, думаешь над проблемой, и буквально через день-два появляется что-то подобное в виде оформленного продукта. Например, драйвер MongoDB, пока разбирался в Rust, драйвер созрел до вполне стабильного, работает хорошо, структура удобная.
Но даже когда чего-то не хватает, я просто затягиваю форк и одной командой собираю тот же проект с бенчмарками, тестами. Это позволяет мне его «подпилить» и вернуть как PR назад на github. Это очень круто ускоряет разработку на языке, который по-сути системный.
Или когда я сталкивался отсутствием какого-то биндинга, я просто из голого Rust вызывал нужный мне нативный метод (требовался HDF5 и Lua, хотя их уже покрыли удобными обёртками). Не бывает, в принципе, такого, что библиотека с трудом собирается под Win. Как это бывает в том же Python. Переносимость просто отличная.
При этом компилятор очень хитромудрый, чувствую что пишу на OCaml, если программа скомпилировалась, она на 99% правильно работает. В этом, конечно, помогает монадная обработка ошибок, отсутствие исключений. Ошибки чисто технически нельзя оставить «на потом». Есть, конечно, unwrap, но на нём не уедешь, далеко, и почти сразу его приходится заменить на человеческий код.
В итоге, комфорт и удобство в работе вынуждают меня генерировать море рабочего кода, которым иногда удаётся поделиться, отправив PR. Язык просто лёг к рукам, хотя до этого я очень долго себя убеждал, что люблю сусликов и Go, наклеечки везде клеил…
Что касается убийцы всех и вся, и что якобы у C++ скоро повиснет указатель, то тут очень трудно что-то прогнозировать. Я люблю Rust больше, но по сути это OCaml, в который добавили фигурные скобочки, чтобы народ мог похоливарить. Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
якобы у C++ скоро повиснет указательвесёлая формулировка :)
А вообще отличный мини-обзор на опыт использования Rust получился, пишите ещё!
Тот момент, когда комментарий содержательнее статьи
Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.Да ну, как по мне Rust достаточно далек от абстрактных материй Haskell, и мне в его освоении как раз помогло осознание того, как все это работает «на голом железе».
Единственное, чем сильно мешал прошлый опыт C/C++, это тот факт, что
&foo в Rust означает совсем не тоже самое, что в С/C++, хотя на первый взгляд как-будто одно и тоже.Но у Раста пока чуть слабовато с метапрограммированием. Или я просто после плюсом не понимаю что делать.
Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?
Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?
trait Trait1 {
type Output;
}
trait Trait2 {
type Output;
}
impl Trait1 for Foo {
type Output = Bar;
}
impl Trait2 for Foo {
type Output = Baz;
}
<Foo as Trait1>::Output // Bar
<Foo as Trait2>::Output // Baz
И в терминологии Rust это не метапрограммирование, а обычный полиморфизм.
Это что-то вроде спецификации шаблонов в стиле Rust? Или в Rust есть обычные шаблоны?
Есть «обычные шаблоны» (насколько они там могут быть, учитывая что в Rust нет понятия класса):
С имплементациями все еще интересней, поскольку можно писать что-то вроде:
Что можно прочесть как «Для каждой пары типов T и U реализовать трейт Foo<U> для типа T, если тип T реализует трейт Bar<U>». Другими словами, вы можете написать шаблонную имплементацию сразу множества интерфейсов для множества структур, связанных каким-то условием.
А в моем комментарии выше вы увидели ассоциированные типы.
// Полиморфная структура
struct Decorator<T> {
item: T
}
// Полиморфный трейт
trait From<T> {
fn from(x: T) -> Self;
}
С имплементациями все еще интересней, поскольку можно писать что-то вроде:
impl<T, U> Foo<U> for T where T: Bar<U> {
...
}
Что можно прочесть как «Для каждой пары типов T и U реализовать трейт Foo<U> для типа T, если тип T реализует трейт Bar<U>». Другими словами, вы можете написать шаблонную имплементацию сразу множества интерфейсов для множества структур, связанных каким-то условием.
А в моем комментарии выше вы увидели ассоциированные типы.
Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?
Если правильно понял проблему, такие конфликты разрешаются через Universal Function Call Syntax.
Пример (положил в playground):
trait First {
type Output;
fn conflict(&self) -> Self::Output;
}
trait Second {
type Output;
fn conflict(&self) -> Self::Output;
}
struct Both;
impl First for Both {
type Output = String;
fn conflict(&self) -> Self::Output {
"First<Output=String>".to_owned()
}
}
impl Second for Both {
type Output = String;
fn conflict(&self) -> Self::Output {
"Second<Output=String>".to_owned()
}
}
fn main() {
let its_both = Both;
println!("{}", First::conflict(&its_both));
println!("{}", Second::conflict(&its_both));
}
Внутренние типы в примере вполне могут быть разными. А если нужно узнать сам внутренний тип реализации, то так:
<Both as Second>::Output
Что интерестно, Rust вообще не скомпилирует код, если будет возможен конфликт:
И сразу предложит почитать в чем суть ошибки и как ее избежать: E0034
<anon>:29:29 error: multiple applicable items in scope [E0034]
<anon>:29 println!("{}", its_both.conflict());
^~~~~~~~~~И сразу предложит почитать в чем суть ошибки и как ее избежать: E0034
Кстати, если бы в вашем примере типы Output были разные, Rust бы без труда вывел, какую именно из имплементаций ему использовать (если предположить, что у второго типа не будет реализован трейт Display).
Sign up to leave a comment.
Rust попал в индекс TIOBE