Comments 41
Это самый лучший паскаль из всех что я видел
Я б не советовал его использовать его в качестве академической замены.
Самый лучший паскаль это python
Не корректно сравнивать повсеместно применяемую штуку и игрушки для фриков. Поэтому раст - это новый лучший паскаль. А паскаль - он как индеец. А хороший индеец...
И вообще, сейчас модно непредвзятые вопросики спрашивать у всяких AI. А они, почему-то не очень спешат рекомендовать такие востребованные, сверхмощные и высокопрофессиональные штуки как раст и паскаль)
-Как звали Паскаля?
-Турбо?
Остаться в одном языке, мало того, что неинтересно, так надо ещё и постараться сделать это. Сейчас это почти невозможно.
Пока что можно с одним java оставаиться... много компаний, где еще kotlin примешивают, но он то же на jvm... Так что не в счет.
а как же xml driven development? или yaml конфиги для всего пайплайна сборки/тестирования? Ну и геймдев всякий.
Yaml, xml, json, sql... Но в статье имеется ввиду именно языки программирования.
языки программирования
где? написано "в одном языке" буквально с цитаты выше. Ну и у большинства названных языков из списка сама собой возникает тьюринг полнота, потому что надо. Или что вы за ЯП берёте?
На ABAP-е не то что интересно оставаться, так ещё и нужно постараться, чтобы перейти на другой язык
Kotlin может не только в jvm
Чтобы понять, как он работает и не бороться с компилятором, требуется определённая подготовка. Для новичков это может быть сложно, но в будущих версиях Rust планируются изменения, которые сильно упростят работу.
О каких изменениях вы тут пишете?
Добрый день! Речь идет про проект Polonius, ссылка на проект: https://github.com/rust-lang/polonius
Почему-то не упоминается про возможность написания на нем микросервисов в общем случае и в частном просто веб приложений.
Это именно то, где я использую Rust и очень доволен.
До этого писал на Java. Быстро, но когда сервисов за сотню, то затраты на железо становятся конскими. С Rust этой проблемы нет.
Первым пояснением на вопрос "Какой язык программирования выбрать?" должно быть "для чего?"
Высокий порог входа, особенно для тех, кто вообще не имеет опыта в программировании. Дело в том, что в Rust используется сущность «время жизни» ...
Думается мне, для тех кто вообще не имеет опыта программирования любой язык создаёт высокий порог входа. Будут там механизмы заимствования, сырые указатели или приколы с value и reference объектами — для новичка всё это одна головная боль.
Компилятор Rust мало того что сразу говорит о проблеме, так в некоторых случаях буквально подсказывает какой код нужно написать чтобы заработало. Я думаю это гораздо проще для новичков, чем ловить непонятные проблемы в рантайме.
А вот для опытных разработчиков Rust действительно сложен. Борьба с компилятором постепенно сменяется осознанием отвественности за владение тем или иным объектом, начинаешь учиться программированию заново, вспоминаешь зачем нужно проектирование, архитектура приложения и т.д.
Конечно это не так. Удовлетворение всех хотелок компилятора раст это отдельный навык, которому нужно долго обучаться.
Для сравнения попробуйте написать линейный односвязный список и стек на его базе на Раст и Python например. Второе окажется на порядок проще и быстрее.
Рас хорош как второй или даже третий язык, если есть опыт работы со статической типизацией, обобщениями и интерфейсами.
Упоминание двусвязных списков в Rust уже не смешно, Вы случаем не преподаватель информатики из ВУЗа? Нафиг они не нужны в 99% задач, а когда нужны, можно взять библиотеку или написать на сырых указателях.
А чего особенного в связных списках? Почему для того же питона или java они проблем не представляют, а в rust это обязательно unsafe?
Имхо это как раз говорит о недостатках языка.
В общем виде задача формулируется так: есть набор объектов, которыми владеет некий parent-объект (контейнер), а между этими объектами есть беспорядочные ссылки, которые обновлять имеет право только parent-объект в соответствии с какой-то своей логикой (чтобы не допускать мёртвых ссылок и т.д.)
Компилятор 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
Не сказал бы, что это сильно длиннее.
Решения не эквивалентны, как указано в комментарии выше.
Например для питона нет итератора, который так и напрашивается для печати, которую зачем-то всунули в список.Код питона грязный, прям очень. Никакой нормальный линтер этот код не пропустит, не говоря уже про живых ревьюеров.
Серьёзно, код написан явно не питонистом. Причём автор даже себе неверен -- в одном случае пишет "HeadVal is not None", в другом: "HeadVal == None".
Ещё скобки эти, нэйминг, отступы,... брр.У меня сильные сомнения, что код, не то чтобы быстрее, а хотя бы на одном порядке с растовым.
“Ключевой особенностью Rust является автоматическое управление памятью без использования сборщика мусора.“ - Во первых, с каких это пор принадлежность к одной из двух половин - особенность? Во вторых, хорошо так память автоматически управляется - даже отдельный раздел книги, Reference Cycles Can Leak Memory, по этому поводу есть.
Rust - сознательное решение обжегшись на молоке с максимальным энтузиазмом дуть на воду. Концепция времени жизни которую нужно прописать явно, уродливо, бессмысленно - пример «сообразить не удалось, но язык я всё равно сделаю».
Из встреченных в Сети мнений, здравыми считаю два. На данный момент Rust переоценён. Сила Rust - в Cargo.
Другими словами, разработчику не нужно думать, в какой момент освободить ранее выделенную памятьЯ думал, всё наоборот: в Расте разработчику нужно прежде всего думать, в какой момент объект должен умереть, чтобы принять правильные решения, кто им владеет, а кому можно дать попользоваться.
А можно пример для встройки где есть что посложнее мигания светодидом? Что нибудь многопоточное или ip стеком
Полнособранный проект не найду, но rtos на расте есть, и ip стек (и минимум ещё один) тоже.
https://github.com/rust-embedded/awesome-embedded-rust
Высокий порог входа, особенно для тех, кто вообще не имеет опыта в программировании.
Какая-то демонизация лайфтаймов (имею ввиду не только данную конкретную статью), хотя в них нет особой сложности, а высокий порог входа обусловлен строгой статической типизацией и отсутствием сборщика мусора.
Какой язык программирования выбрать? Часть 1. Rust