Так ли токсичен синтаксис Rust?

let myFunc: (x: i32) -> bool;

Ну в статье же приведен пример, когда это вызывает проблемы:

let myFunc: (i32, i32);

Что это, функция или кортеж?

Так ли токсичен синтаксис Rust?

Опять же не надо забывать, что в современности мало кто программирует в notepad/nano, а отступ в vscode будет виден очень хорошо

Как насчет code review через веб-интерфейс? Или публикации кусков кода в мессенджерах? Или копи-пасты со stackoverflow? Отступ-то вы увидите, но у вас не будет дополнительного контроля, что вы не сдвинули что-то где-то. На Rust также распространена практика, когда тебе нужно что-то быстро проверить на работоспособность в онлайн-плейграунде и копируешь туда код зачастую с "поехавшими" отступами, но благодаря скобкам об этом не нужно беспокоиться.

Хотя то, что отступы видны хуже, следует также из того факта, что люди с плохим зрением их не видят, в отличии от скобок.

в других языках это выглядит менее вербозно и без борров-чекера, что-то типа: withLock(mutex): ...

А если нужно лочить не одно значение, а сразу два или три? Городить вложенные блоки? И ведь речь не только о локах мьютекса, а вообще о всем, для чего удобно использовать RAII.

Опять же нет никаких проблем

fn foo() { .. }

fn bar() -> bool { .. }

let val = if x < 42 {
    foo(x)
} else {
    bar(x)
}

Какого типа должно быть значение val?

Опять же let mut избыточен, достаточно mut

Нет никакого let mut, есть let PATTERN. let — это не оператор объявления переменных, это оператор сопоставления (в паттерне переменных может и не быть).

Так ли токсичен синтаксис Rust?

A[B] это еще доступ по индексу.

Операционная система Redox 0.6, написанная на Rust: что нового в выпуске?

Да, круто, серьезно. Ребята запилили свою ОС. Практическая польза? Около нуля.

Да вроде нет сарказма. "Работа серьезная, но бестолковая" — я такой смысл прочитал.

Так ли токсичен синтаксис Rust?

Вы саму статью читали? Хотя бы вводную ее часть?

Так ли токсичен синтаксис Rust?

А красный флаг тогда тут при чем? Мы разве гонки обсуждаем, или мореплавание, или революционную борьбу?

Так ли токсичен синтаксис Rust?

По вашему синтаксис языка программирования не достоин обсуждения?

Так ли токсичен синтаксис Rust?

Почему молодые? Думаю, хейтеры синтаксиса Rust на Opennet вполне себе бородаты.

Rust глазами Python-разработчика #2

Вообще по отношению к опенсорсу и величине вклада в него вполне можно судить об адекватности и прогрессивности ИТ-компании сегодня, я думаю.

Rust глазами Python-разработчика #2

Вы с темы не съезжайте. Речь шла именно про язык С. Если вам нужно написать приложение для браузера, вы все еще возьмете JavaScript (ну или в недалеком будущем Rust, но сейчас не об этом) и вам все равно, на каком языке написан его интерпретатор. Я не умоляю значения языка С, но я сильно сомневаюсь в вашем утверждении, что любой компилируемый язык (для примера С) подходит лучше для разработки сложных систем любого другого интерпретируемого языка (Python, PHP, JavaScript).

Rust глазами Python-разработчика #2

Быстрее разрабатывать именно крупные системы, заметьте. Делать a + b вообще говоря все равно, на каком языке. А вот когда вы можете на высоком уровне оперировать множеством компонентов и легко связывать их в нечто более крупное… Но потом это крупное нужно поддерживать. Но потом это крупное требует особого тюнинга и нужно спускаться на уровень ниже. И та легкость и незамутненность типами, которая помогала на первом этапе, вдруг становится серьезным тормозом дальнейшего развития системы.

Rust глазами Python-разработчика #2

Тем не менее, большая часть сайтов в Интернете написана на PHP. А в браузере у вас выполняется в основном JavaScript. А вот на чем написан типичный браузер: https://4e6.github.io/firefox-lang-stats/ Доля именно C там не подавляющая. Мобильные приложения — это Java и Kotlin (или Swift).

Rust глазами Python-разработчика #2

Как вы думаете, какую систему будет проще дорабатывать и поддерживать, написанную на Python или на C?

Rust глазами Python-разработчика #2

Дело вовсе не в производительности готовых программ, дело в производительности разработки. Вы не уловили главный вывод этого доклада: на Python получается быстрее разрабатывать с нуля, но дорабатывать и поддерживать систему, тем более крупную, быстрее и легче на Rust, так как он кучу важных проверок выносит на этап компиляции. В этой плоскости языки можно и нужно сравнивать, чтобы стало понятно, что лучше взять для быстрой разработки прототипа, который собрал и выкинул, а что лучше взять для разработка MVP, который предполагается дальше развивать продолжительное время.

Rust глазами Python-разработчика #2

Проблему с двойной ссылкой нельзя обойти из-за того, что массивы в Rust пока нельзя преобразовать в итератор по-значению, а не по-ссылке. Но вскоре это будет исправлено. Тогда можно будет писать так:

let output: i32 = ["42", "43", "sorokchetire"]
    .into_iter()
    .map(str::parse::<i32>)
    .filter_map(Result::ok)
    .map(|integer| integer * 2)
    .sum();

Rust глазами Python-разработчика #2

Ссылка на parse во втором map не нужна. Ну и первый map делает ненужную аллокацию:

let output: i32 = ["42", "43", "sorokchetire"]
    .iter()
    .map(|value| value.parse::<i32>())
    .filter_map(Result::ok)
    .map(|integer| integer * 2)
    .sum();

Rust глазами Python-разработчика

Зачем документировать то, что можно указать типами? Документация — это информация для человека и она может не соответствовать реальным данным в коде, потому что происходит дублирование. Типы же понятны не только человеку, но и машине. И машина может проверить автоматически их соответствие. Там, где вводятся типы, специально документировать их наличие не нужно вовсе.

Rust глазами Python-разработчика

Дело в том, что тип Result в Rust, во-первых, является тип-суммой, работать с которым нельзя без того, чтобы явно не рассмотреть оба возможных варианта. А во-вторых, он помечен атрибутом #[must_use], что не позволяет просто забыть его обработать. И проверки этих случаев обеспечивает компилятор статически. Python не сможет такого by design.

Rust глазами Python-разработчика

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

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

Насчет же статических типов и/или статических подсказок типов, то вроде как эта фишка должна помогать бороться с ошибками в сложных программах.

Ага. Поэтому давайте большие и сложные программы писать на Python не будем, раз мы не хотим, чтобы он становился комфортным выбором для них. Может тогда вообще лучше отказаться от Питона и осваивать язык, который подойдет и для больших, и для малых проектов? Пусть и с не столь быстрым стартом в обучении.

Я просто хочу сказать, что ваша позиция на самом деле противоречит вектору развития языка (любого языка, претендующего на звание языка общего назначения). Конкуренция в среде ЯП пока только усиливается и у того, кто сознательно станет сдавать позиции, ограничивать возможности своего языка, шансов победить в борьбе будет сильно меньше. Но отчасти быть может вы правы, и Питону стоит подвинуться, вернуться в сферу одностаничных скриптов и пропустить более подходящие языки общего назначения на занятые им места.

Rust глазами Python-разработчика

Например в Java. Там любая переменная типа какого-нибудь класса — на самом деле ссылка, с типом как будто тип-суммой из значения указателя на объект данного класса и значения null типа null:

Object obj = null;