Как стать автором
Обновить

Комментарии 41

Я б не советовал его использовать его в качестве академической замены.

Самый лучший паскаль это python

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

И вообще, сейчас модно непредвзятые вопросики спрашивать у всяких AI. А они, почему-то не очень спешат рекомендовать такие востребованные, сверхмощные и высокопрофессиональные штуки как раст и паскаль)

-Как звали Паскаля?

-Турбо?

Остаться в одном языке, мало того, что неинтересно, так надо ещё и постараться сделать это. Сейчас это почти невозможно.

Пока что можно с одним java оставаиться... много компаний, где еще kotlin примешивают, но он то же на jvm... Так что не в счет.

а как же xml driven development? или yaml конфиги для всего пайплайна сборки/тестирования? Ну и геймдев всякий.

Yaml, xml, json, sql... Но в статье имеется ввиду именно языки программирования.

языки программирования

где? написано "в одном языке" буквально с цитаты выше. Ну и у большинства названных языков из списка сама собой возникает тьюринг полнота, потому что надо. Или что вы за ЯП берёте?

Зачем путать язык разметки и язык программирования?

Ещё раз

Остаться в одном языке

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

Намекаете на то, что автор имел ввиду невозможность остаться в одном языке разметки, или вообще речь шла о языках (иностранных в том числе)?

А может стоит из контекста понять, что речь о языках программирования?

На ABAP-е не то что интересно оставаться, так ещё и нужно постараться, чтобы перейти на другой язык

Kotlin может не только в jvm

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

О каких изменениях вы тут пишете?

Почему-то не упоминается про возможность написания на нем микросервисов в общем случае и в частном просто веб приложений.

Это именно то, где я использую Rust и очень доволен.

До этого писал на Java. Быстро, но когда сервисов за сотню, то затраты на железо становятся конскими. С Rust этой проблемы нет.

звучи так, как-будто микросервисы нельзя на любом языке написать

Писать микросервисы так, чтобы они не жрали много ресурсов — не на каждом.

Первым пояснением на вопрос "Какой язык программирования выбрать?" должно быть "для чего?"

Но мы же понимаем для чего такие статьи пишутся

Высокий порог входа, особенно для тех, кто вообще не имеет опыта в программировании. Дело в том, что в Rust используется сущность «время жизни» ...

Думается мне, для тех кто вообще не имеет опыта программирования любой язык создаёт высокий порог входа. Будут там механизмы заимствования, сырые указатели или приколы с value и reference объектами — для новичка всё это одна головная боль.

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

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

Конечно это не так. Удовлетворение всех хотелок компилятора раст это отдельный навык, которому нужно долго обучаться.

Для сравнения попробуйте написать линейный односвязный список и стек на его базе на Раст и Python например. Второе окажется на порядок проще и быстрее.

Рас хорош как второй или даже третий язык, если есть опыт работы со статической типизацией, обобщениями и интерфейсами.

Упоминание двусвязных списков в Rust уже не смешно, Вы случаем не преподаватель информатики из ВУЗа? Нафиг они не нужны в 99% задач, а когда нужны, можно взять библиотеку или написать на сырых указателях.

А чего особенного в связных списках? Почему для того же питона или java они проблем не представляют, а в rust это обязательно unsafe?

Имхо это как раз говорит о недостатках языка.

Двусвязный список — частный случай.

В общем виде задача формулируется так: есть набор объектов, которыми владеет некий parent-объект (контейнер), а между этими объектами есть беспорядочные ссылки, которые обновлять имеет право только parent-объект в соответствии с какой-то своей логикой (чтобы не допускать мёртвых ссылок и т.д.)

Компилятор rust в общем случае не знает логики контейнера, поэтому не может безопасно разрулить эту ситуацию.

Вы сейчас описали любую нетривиальную программу.

Но давайте пример проще: линейный односвязный список. Казалось бы никаких циклических ссылок. Но все равно на расте куча приседаний с борроучекером, а на python\java\C# проблем нет.

Я не защищаю rust. Наверное, комментарий надо было сделать уровнем выше.
Имхо это как раз говорит о недостатках языка.

unsafe — это часть языка. Так-то и в С++ есть подмножество безопасных операций, просто они явно не выделены. Сборка мусора действительно многое упрощает, но для системного языка такие "сложности" — это вполне нормально, как мне кажется.

Мне бы хотелось увидеть односвязный список на питоне, который будет проще и быстрее растового. Ещё, очень надеюсь, он будет утилизировать все ядра процессора.

Покажите?

Вот пример на питоне (в конце статьи) https://www.tutorialspoint.com/python_data_structure/python_linked_lists.htm

На расте https://rust-unofficial.github.io/too-many-lists/second-final.html

Даже если отбросить Iter, то в расте сильно больше операторов

Так на питоне только сам лист + push + RemoveNode (которого нет в rust имплементации).
Если взять лист + push, которые есть в обоих, то разница будет только в ссылочной прозрачности (drop на самом деле не необходим на расте, см https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=e8dfac514684d1a17ddd307b90e2f281 разница с питоном минимальная.

Единственное, о чём нужно задумываться в рамках аналога RemoveNonde - это о прередаче владения при удалении ноды (и внимательно следить где ссылки, а где объекты).
Можно сделать, например, вот так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=2d2c3f5e8b1a5d8495a3f7220bec4285
Не сказал бы, что это сильно длиннее.

  1. Решения не эквивалентны, как указано в комментарии выше.
    Например для питона нет итератора, который так и напрашивается для печати, которую зачем-то всунули в список.

  2. Код питона грязный, прям очень. Никакой нормальный линтер этот код не пропустит, не говоря уже про живых ревьюеров.
    Серьёзно, код написан явно не питонистом. Причём автор даже себе неверен -- в одном случае пишет "HeadVal is not None", в другом: "HeadVal == None".
    Ещё скобки эти, нэйминг, отступы,... брр.

  3. У меня сильные сомнения, что код, не то чтобы быстрее, а хотя бы на одном порядке с растовым.

“Ключевой особенностью Rust является автоматическое управление памятью без использования сборщика мусора.“ - Во первых, с каких это пор принадлежность к одной из двух половин - особенность? Во вторых, хорошо так память автоматически управляется - даже отдельный раздел книги, Reference Cycles Can Leak Memory, по этому поводу есть.

Rust - сознательное решение обжегшись на молоке с максимальным энтузиазмом дуть на воду. Концепция времени жизни которую нужно прописать явно, уродливо, бессмысленно - пример «сообразить не удалось, но язык я всё равно сделаю».

Из встреченных в Сети мнений, здравыми считаю два. На данный момент Rust переоценён. Сила Rust - в Cargo.

А ещё сила Rust в том что

  1. Перенос по умолчанию

  2. Структура данных на компиляторе

  3. Работа со строками

  4. Отсутствие огромного наследия совместимости.

  5. Да и много того что в ругих языках не сделали по причине слабых компиляторов, а потом менять не стали.

НЛО прилетело и опубликовало эту надпись здесь
Другими словами, разработчику не нужно думать, в какой момент освободить ранее выделенную память
Я думал, всё наоборот: в Расте разработчику нужно прежде всего думать, в какой момент объект должен умереть, чтобы принять правильные решения, кто им владеет, а кому можно дать попользоваться.
НЛО прилетело и опубликовало эту надпись здесь

А можно пример для встройки где есть что посложнее мигания светодидом? Что нибудь многопоточное или ip стеком

Высокий порог входа, особенно для тех, кто вообще не имеет опыта в программировании.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий