Под сладостью я подразумеваю синтаксический сахар и его количество). Понятное дело что в раст он имеет место быть, но в достаточной ли степени? Ниже привожу примеры +- похожего кода который мне было не лень искать:
Rust
Golang
Vlang
И возникает резонный вопрос, так ли нужны нам двоеточия перед типом, точка с запятой в конце строки, let и mut - которые можно сократить до одного символа? Что вы думаете по этому поводу дорогие форумчанины?
В таких обсуждениях все время всплывают термины вроде “явности”, которые люди часто понимают по разному. Я несколько лет назад переводил пост Безлодочника на схожую тему:
Возможно оно будет интересно участникам этой темы, что бы быть больше на одной волне.
Я бы не сказал, что в этих примерах разница из-за сахарности самих языков, тут больше вопрос про дизайн API конкретных библиотек. Ржавые либы в целом тяготеют к вываливанию на пользователя деталей (мол, на системном ж языке пишем, значит наверняа хотим контролировать всякие нюансы), но никто не запрещает делать высокоуровневое API. Особенно если атрибутными процмакросами обмазаться. Вон helloworld у того же rocket.rs:
#[macro_use] extern crate rocket;
#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
format!("Hello, {} year old named {}!", age, name)
}
#[launch]
fn rocket() -> _ {
rocket::build().mount("/", routes![hello])
}
… весьма короткий и без торчащих наружу деталей.
Штуки вроде :; значительно упрощают грамматику языка, повышают качество сообщений об ошибках и дают возможность делать понятными более сложные языковые конструкции (в том числе и будущие).
Двоеточие перед типом все-таки обязательно только в определениях структур и сигнатур функций, а для обычных переменных в абсолютном большинстве ситуаций явное указание типа опционально. Да и если это дело попробовать убрать, то я даже боюсь представить насколько сложно будет парсить сопоставление с образцом в аргументах функций.
Точка с запятой в конце стейтментов - это в первую очередь про простоту и надежность грамматики, но потраченные на ; символы часто окупаются возможностью возврата значения из блока без return.
let mut - это вообще специально придуманная синтаксическая соль, задача которой подталкивать разработчика держать все по умоланию константным. Да и введение в язык какого-нибудь var сокращения было бы жутким костылем, потому что let mut ... это не единая конструкция, а создаваемый let’ом тотальный контекст сопоставления с образцом, внутри которого у нас уже есть паттерн mut имя_новой_привязки.
Ну и надо понимать, что конкретно вышепредложенные штуки это прям столпы языка, которые кто-то согласится менять только при неимоверно сильных аргументах. Предложения от новичков что-то такое поменять регулярно всплывают на IRLO, но неизбежно кончаются закрытием.
Я познакомился с растом в довольно давно, на этапе когда он стремительно сбрасывал все что можно к 1.0 стабилизации, имел минимум сахара и в целом был довольно минималистичным. И мне всегда была по душе явность и соленость языка - в моей картине мира это весьма полезно для поддержвания качества больших и долгоживущих проектов. Так что лично меня наоборот напрягает с какой скоростью последние годы в язык втаскивают всякий сахар, например:
Т.е. я понимаю что оно все до какой-то степени полезно, но есть ощущение, что размен иногда получается так себе: часто вводятся всякие сложные штуки в язык ради экономии пары символов тут-там или даже одной строчки на тысячу. А надо еще помнить, что у Rust так и нет полноценного референса, т.е. риски неучтенных корнеркейсов всей этой мешанины не так что бы хорошо отслеживаются.
Так что я каждый раз напрягаюсь, когда вижу новый принятый сахарный RFC.
Спасибо за исчерпывающий ответ! Хотел бы ещё узнать, а что вы думаете над альтернативным вариантом внедрения сахара, через транспиляцию полностью совместимого и более сладкого языка в rust?
Я не видел что бы кто-то в эту сторону серьезно копал и лично мне сложно представить что бы ржавая экосистема захотела такое начинание всерьез подхватить и интегрировать. Ради мелких улучшений возиться с транспилером это слишком много гемора (да и эти улучшения не просто так были отвергнуты дизайнерами раста), а если серьезно менять язык, то в эпоху победившего LLVM проще пойти путем полностью альтернативной реализации компилятора.
Я, кстати, не уверен, что мой ответ прям уж такой исчерпывающий.
что до сахара то он в любом случае должен быть, вопрос когда остановиться. Асинк-авейт это сахар, цикл for это сахар, …
Иногда в сахар встраивают вещи которые иначе не сделать. Т.е. тот же асинк авейт которй позиционировался как сахар для лапши из коллбеков дает возможность борровить между авейтами. Не уверен что это можно написать руками чтобы оно оставалось sound
Хорошо или плохо что компиляторовладельцы могут что-то чего не могут обычные смертные - кмк скорее плохо, но что поделать