оратор заявил, что d популярней rust и go. это ложь.

https://www.tiobe.com/tiobe-index/

inb4 ваши рейтинги не рейтинги

Судя по графику, что-то очень страшное произошло в мире конце 2017, из-за чего питон и VB.Net стремительно пошли вверх

Ну да, ну да, конечно, всех топить, только избранные будут программировать. Сейчас программирование применяется везде, где нипопадя. И людям нужны простые рабочие инструменты типа Питона или го. Чтобы грамотный человек, в принципе понимающий, что такое программа, мог сесть и за неделю-две освоиться и начать писать полезные вещи.

Ну, ты же понимаешь, что это сказочные мечты. Инструменты часто сложны, потому что сложны задачи, которые решают с помощью таких инструментов. Вопрос в том, можно ли сделать проще, не переусложнены ли избыточно инструменты, но так редко бывает. А так, приятно помечтать о кисельных берегах и молочных реках - кто же спорит!

Махин лёрнинг случился?

Ну, ты же понимаешь, что это сказочные мечты. Инструменты часто сложны, потому что сложны задачи, которые решают с помощью таких инструментов. Вопрос в том, можно ли сделать проще, не переусложнены ли избыточно инструменты, но так редко бывает. А так, приятно помечтать о кисельных берегах и молочных реках - кто же спорит!

Для студентов физиков и инженеров Питон вполне годится. скорость освоения в 2 раза больше, чем Паскаля и в 3-4 раза, чем Си. И графики можно строить. Они реально начинают делать на нём лабы, вместо экселя и калькулятора. Но вот тут товарищи предлагают вообще запретить Питон и программирование на нём, пусть страдает народ.

Опять же R использует туева куча непрограммистов, и ничего. им тоже всем запретить?

И выглядит это так:

template<Pointer T>
[[gsl::lifetime(*a,{*b})]] [[gsl::lifetime(*b,{*a})]] swap(T& a, T& b)
{ ... }

Цитата аксиомы Эскобара.

Спорить о вкусе фломастеров я не собираюсь. Я привёл пример как выглядят лайфтайм аннотации в С++ на текущий момент. Для справки, так сказать.

Или массовое отупение айтишников. Может лучи какие-нибудь космические

Зачем запрещать? У меня и в мыслях не было такого)

И я бы не стал физиков мучать изучением C++. Зачем так издеваться над людьми?

Однако, если этим физикам нужно будет потом что-то смоделировать или рассчитать сложное на сложных компьютерных комплексах, то либо придется прибегнуть к помощи сторонних программистов, либо стать самим программистами. Окажется, что дешевле вложиться в программирование, чем потом оплачивать счета за электричество и оплачивать износ оборудования. Чудес не бывает.

Спорить о вкусе фломастеров я не собираюсь

Котейка уже в пятый раз копипастит один и тот же кусок кода. Что самое интересное, функция с таким объявлением действительно есть, но ее тело выдрано из другого места. Параметры функции никак не используются, а из ниоткуда появляются ty и ops.

Причем, ему уже объясняли, что если копипастишь, то копипасть реальный код, а не вырезай по одной строчке и делай из этого функцию. Он же сделал Франкенштейна (монстра из нарезанных кусков) и пугает им всех. Забавный чел.

PS: Остальной код тоже подерган по 1-5 строчек. Полагаю, найти последовательность из 10 неудачных строк кода на расте у Котейки не получается, поэтому он выкручивается как может. Похвально. Старается.

Вы не уходите от вопроса.

Чудес не бывает.

Авторы Julia верят, что бывают. И что ЯП может быть прост в изучении, но в то же время фичаст, с быстрым компилируемым кодом, но опциональной аннотацией типов, чтобы были библиотеки на все случаи жизни. И чтобы можно было один единственный ЯП использовать и для быстрых экспериментов «наговнокодил, посчитал, записал, выбросил» и для более систематизированного софта.

О, оправдания пошли, ахах.

Что самое интересное, функция с таким объявлением действительно есть, но ее тело выдрано из другого места.

Ее тело не выдрано, я просто обрезал начало функции. Обрезал, не добавил. Понимаешь?

Он же сделал Франкенштейна (монстра из нарезанных кусков) и пугает им всех.

Это все из одного файла насколько я помню.

Полагаю, найти последовательность из 10 неудачных строк кода на расте у Котейки не получается

Так я же вроде писал, весь код на расте такой, открываю карго, и что я вижу? Если файл не состоит из 5 строчек (а таких файлов в расто-проектах большая часть), то там обязательно что нибудь такое:

pub fn closest<'a, T>(
    choice: &str,
    iter: impl Iterator<Item = T>,
    key: impl Fn(&T) -> &'a str,
) -> Option<T> {
    iter.map(|e| (lev_distance(choice, key(&e)), e))
        .filter(|&(d, _)| d < 4)
        .min_by_key(|t| t.0)
        .map(|t| t.1)
}

писал в этом году

Ну раз ты писал, значит rust&go далеко позади

Не буду убеждать в красоте кода. Но сразу видно, что код - кривоватый: лайфтайм 'a используется только в одном месте. Тот, кто писал, не совсем понимал, что делает.

Ну и можно написать немного понятнее. А так это - обычный функциональный pipeline.

pub fn closest_but_not_really<T>(
    choice: &str,
    iter: impl Iterator<Item = T>,
    key: impl Fn(&T) -> &str,
) -> Option<T> {
    iter.map(|item| {
        let distance = lev_distance(choice, key(&item));
        (distance, item)
    })
    .min_by_key(|&(distance, _)| distance)
    .and_then(|(distance, item)| {
        if distance < 4 {
            Some(item)
        } else {
            None
        }
    })
}

Или можно написать в императивном стиле. Но тут больше возможностей сделать ошибку.

pub fn closest_less<T>(
    choice: &str,
    mut iter: impl Iterator<Item = T>,
    key: impl Fn(&T) -> &str,
) -> Option<T> {
    let mut min_item = iter.next()?;
    let mut min_dist = lev_distance(choice, key(&min_item));
    for item in iter {
        let dist = lev_distance(choice, key(&item));
        if dist < min_dist {
            min_dist = dist;
            min_item = item;
        }
    }
    if min_dist < 4 {
        Some(min_item)
    } else {
        None
    }
}

А что это за рейтинг?

Чудес не бывает.

Авторы Julia верят, что бывают.

Ну, я понял, откуда ветер дует :)

ну да, только эти аннотации нужно писать далеко не всегда, а лишь когда не устраивает дефолтные предположения лайфтаймов, а в расте всегда.

То есть происходит это так, ты просто пишешь обычный С++ код и всё работает и все лайфтаймы проверяются, когда вдруг компилятор пишет тебе варнинг/ошибку связанные с лайфтаймами, то либо у тебя есть ошибка, либо нужно добавить аннотаций с лайфтаймами.

Очень много неуместных сокращений mut fn vec iter в совокупности с заглавными буквами в стандартной либе - жесть

а лишь когда не устраивает дефолтные предположения лайфтаймов, а в расте всегда.

Неправда. См https://doc.rust-lang.org/nomicon/lifetime-elision.html

ты просто пишешь обычный С++ код и всё работает и все лайфтаймы проверяются

Не жизнь, а сказка. А какая сказка без тридевятого царства

а в расте всегда

Ну вы бы хоть постеснялись.

Однако, если этим физикам нужно будет потом что-то смоделировать или рассчитать сложное на сложных компьютерных комплексах, то

у них есть Фортран и в нём огромная экосистема с библиотеками численных методов, параллельного программирования и ещё много чего. И всё гораздо более безопасно, чем в Си++.

Кстати, сто лет уже не смотрел на фортран. Там появились генерики или шаблоны? Не из ехидства спрашиваю, а из интереса.

у них есть Фортран и в нём огромная экосистема с библиотеками численных методов, параллельного программирования и ещё много чего. И всё гораздо более безопасно, чем в Си++.

На сколько я понимаю, вся эта экосистема должна кем-то поддерживаться, чтобы задействовать новые аппаратные архитектуры. Т.e. старый код из 80-х нельзя просто взять и без изменений пересобрать для выполнения на GPU. Если так, то преимущество фортрана перед С++ не столь очевидно, даже с учетом всех фич новых стандартов фортрана.

Как будто C++ код можно просто так взять и запустить на GPU.

Как будто C++ код можно просто так взять и запустить на GPU.

А я что, написал, что можно?

А это что:

то преимущество фортрана перед С++ не столь очевидно

Это, мягко говоря, не то же самое, что «C++ код можно просто так взять и запустить на GPU.» Смысл о «неочевидности» был в том, что как С++, так и фортрановский код таки надо поддерживать. Т.e. по-хорошему надо сравнивать стоимость портирования кода например с обычного SMP+SIMD на SMP+CUDA в случае с фортрановским и С++ кодом. Если работы по портированию много (если это далеко не просто тупая замена for на parfor), то наличие готовых библиотек уже не такой гигантский плюс, каковым он был бы в противном случае (если портирование тривиально). T.e. может быть портирование тривиально, и тогда это никак не противоречит слову «неочевидно».

Вы на Окамле писали?

Баловался немного, ничего, впрочем, серьёзного. Приятный строго и статически типизированный язык с неленивой моделью исполнения.

В питоне всё просто: засунул что попало в кортеж или словарь,

Вы не можете засунуть что-попало, если планируете потом это как-то использовать. Сложность программы никуда не девается, вопрос лишь в том, где будете тратить больше усилий — при разработке (статические) или сопровождении (динамические) кода.

В Питоне можно писать чисто императивно

А в ОКамле — чисто (конкретно) функционально!

Ну, ты же понимаешь, что это сказочные мечты. Инструменты часто сложны, потому что сложны задачи, которые решают с помощью таких инструментов.

А ещё потому, что сделать сложный инструмент проще, чем сделать простой.

В Окамле только кажется, что так можно делать, да и то только на верхнем уровне.

Похоже просто конвенция. Ничего не мешает написать чистую функцию внутри которой тройной императивный цикл меняющий какое-то значения ref

где тратить больше усилий — при разработке или сопровождении

Та же история, что и с ценой мусорщика. Если поиск багов можно отложить на время после вывода программы из эксплуатации (:или увольнения автора:), второй вариант может оказаться сильно дешевлее.

Простой инструмент сделать проще: возьми тот же ассемблер, старые пхп или яваскрипт. Простой синтаксис, простые базовые элементы и убийственная сложность создания больших проектов.

И людям нужны простые рабочие инструменты типа Питона или го

ни питон, ни го _нельзя_ освоить за две недели на уровне большем, чем «знаю примерно синтаксис, могу что-то наваять с помощью so»

не надо себя обманывать

В питоне вообще документация раздутая. Описание каждого модуля размером с небольшую повесть. Причем половина текста описывает входные и выходные типы методов. Эдакая художественная типизация. А вторая половина из-за наростов легаси. За неделю хорошо если пару таких повестей прочтешь

restrict(amp) к функции добавить и готова.

ни питон, ни го _нельзя_ освоить за две недели на уровне большем, чем «знаю примерно синтаксис, могу что-то наваять с помощью so»

Ну это и требуется сначала. Есть простая прикладная задача, именно на ней и осваивается новый язык. А теоретизировать можно сколько угодно. Если язык становится полезен, когда нужно писать браузер или ядро ОС, то это, конечно, круто, но не будет востребовано. Подавляющее большинство народа закончат на Хэлловордах.

ни питон, ни го нельзя освоить за две недели

Зависит от навыков. Перейти с перла на питон или с явы на го можно даже быстрее. Тут больше проблем будет от старых привычек избавиться, чем новый язык выучить.

Зависит от навыков

ну да, если ты уже знаешь питон - то перейти на него можно быстро )

Любой начинаюший сишник понимает в этом больше чем растер, который прежде всего учится писать заглушки и бороться с компилятором.

Ага, щазз.

Ничего начинающий сишник не понимает и никогда понимать не начнет. C - это кроссплатформенный ассемблер, заявлять, будто бы сишник от этого что-то понял, ну это все равно что говорить, будто ребенок, составляющий слова из кубиков дофига понимает во всякой филологии. Программы начинающих сишников /крестовиков - это то, где память не освобождается, где вообще всё подряд выделяется в хипе, потому что раньше делал лабы на джаве, либо где из функции возвращают указатели на локальные переменные. И все эти программы при этом работают как надо, что убеждает начинающего сишника в его правоте. Вот после того, как сишник освоит язык и начнет писать что-то разумно большое его начнут бить по башке донимая всякой бюрократической ерундой типа заставляя освобождать память да ещё и тем методом, которым она была выделена, заставляя зачем-то писать комменты на предмет времени жизни и прочего, а сишник будет метерить старперов.

А вот как раз начинающий растовщик вынужден сначала сам понять, как ресурсы в его программе управляются и только после этого сможет объяснить компилятору.

А вот как раз начинающий растовщик вынужден сначала сам понять, как ресурсы в его программе управляются и только после этого сможет объяснить компилятору.

Тут есть одна нестыковка. Понять по rust’у можно требования rust’а. Они сильно не совпадают с требованиями железа и ОС. Все ограничения Си - ограничения железа и ОС.

Они сильно не совпадают с требованиями железа и ОС. Все ограничения Си - ограничения железа и ОС.

Главное ограничение Си - плохая эргономика когда ты хочешь заплатить небольшую цену за большую безопасность. Чтобы железо, которое у тебя что-то требует, в виде компилятора добавило нужные проверки в код, где возможно, то просто что-то доказывало в рантайме

ну да, если ты уже знаешь питон - то перейти на него можно быстро )

Это лукавство. Естественно, легко перейти на то, что практически совпадает с языком, на котором ты писал. Но действительность такова, что Питон очень естественен. Часто самое простое, естественное действие — правильное. В большинстве языков не так.

Это все разговоры на лавочке. C примитивен. В Rust нужно еще вызубрить lifetime, generics, traits, macros. Особенно когда все вместе сразу применяется. И это будет не через год(особенно если с подобным не сталкивался раньеш).

Это все кукареки понтовитых программистов в стиле «да я такое за 2 часа сделаю»(и делает месяц, ага).

У вас теория, у меня - практика. Как писал geek выше, синтаксис можно с чашечкой чая на выодных изучить.

Ограничения железа, которого больше не существует? Хотелось бы каких-то реальных примеров.

Ну так вроде бы решили Rust с ЦПП сравнивать, а ЦПП — это, как известно, 4,5 разных языка программирования.

Понять по rust’у можно требования rust’а.

И, внезапно, они совпадают с некими «бест практикс», которые позволят программе не начать падать после небольшого усложнения в совершенно другом месте.