Comments 26
Когда в этом языке появятся Result / Option и map-reduce-filter?
Они уже появились специальной сборке языка, которая называется Rust)
У go же другая идея - минималистичный синтаксис, чтобы на него мог легко переключится разработчик с любого языка. Дополнительные языковые конструкции идут в противоречие с этой задачей.
Это есть не только в расте, но и в TypeScript и даже в С++, да и, наверное, в других современных языках.
Дополнительные языковые конструкции идут в противоречие с этой задачей.
Только в итоге код на го превращается в лапшу, где логика и проверка ошибок перемешаны, да и в целом выглядит как Си курильщика.
Коллеги пишут тулзу на го, так более 50% их кода — это ручная проверка ошибок и ручная реализация map-reduce для разных типов. На это больно смотреть в 2021.
Го
passed := true
for test := range tests {
result, err := RunTest(test, outputDir)
if err != nil {
return fmt.Errorf("Failed to parse %s result: %s", test, err)
}
passed = passed && result.IsPassed()
}Раст:
let passed = tests.
.map(|t| run_test(t))
.all(|r| r.is_some() && r.unwrap().is_passed);И такого кода реально 50%. То посчитать сумму полей структур, лежащих в массиве, то отфильтровать. И все руками, каждый раз изобретая колесо.
Про result/option даже говорить не хочется, даже Си в чем-то лучше тем эта дичь:
if entities, err = parseEntities(cfg.Entities); err != nil {
return nil, fmt.Errorf("Failed to parse entities: %s", err)
}Абсолютно нечитаемо.
Могу обратный пример привести.
func ApiCall() (string, error) {vs
fn api_call() -> Result<String, Box<dyn Error>> {Что за хрень тут происходит для человек не знающего rust понять довольно сложно, а в go просто возвращается два значения, что должно быть понятно любого.
Можно сравнить еще работу со строками, в go есть просто один тип string, и с ними легко работать, в rust же есть два &str и String и можно голову сломать. В го чтобы сделать конкатенацию строк, просто пишешь s1 + s2, в расте же надо использовать макросы и там тоже есть определенные непонятные места.
В целом на rust действительно код получается лаконичнее, но это не значит, что его легче читать, особенно для начинающих.
Я начинал изучать го и раст одновременно и могу сказать, что понять как писать код на го намного проще. Когда пишешь код на раст возникает больше вопросов, чем ответов, в работу со строками и обработку ошибок не так просто вникнуть. В го же такого вопроса не возникает, если человек знает конструкцию if, значит он ужа знает как обрабатывать ошибки.
В целом, ваш ответ скатывается в "мне тяжело изучать что-то новое, что хоть чуть сложнее того, что я уже знаю". Это не проблема языка или технологии. Это ваша проблема.
Вы привели всего одну строчку — декларацию, где гошный код немного "понятнее" для джуна, но манипулятивно не привели остальную обвязку, которая в го будет замусорена кучей строк с ручной проверкой ошибок, от которых никак не избавишься. В расте этот мусор целиком заменяются на один символ — ?
К тому же вы, манипулятивно, специально "усложнили" пример, потому что в 99% случаев строка будет выглядеть так:
fn api_call() -> Result<String, Error> {Опять же, вы делаете вид, что https://docs.rs/anyhow/ не существует.
Не нравится раст, так даже в тайпскрите можно не возвращать убогий кортеж с кучей мусорной обвязки:
function api_call(): string | Errorв rust же есть два &str и String и можно голову сломать.
А еще при работе с &str часто приходится использовать лайфтаймы, ужасно просто, ну неужели нельзя было сделать так, чтобы вчерашний питонист, прошедший курсы, за один день въехал в раст.
Неужели без дешевых манипуляций нельзя показать сильные стороны го?
Это не проблема языка или технологии. Это ваша проблема.
Неужели без дешевых манипуляций нельзя показать сильные стороны го?
Может не стоит в таком грубой форме общаться?
Хамство — это использовать манипуляции как аргументы, представляя что собеседник тупой.
Очевидно, что это превращает конструктивный диалог в обмен грубостью.
Ну если вы так сильно считаете что вам хамят, то может либо не стоит отвечать, либо ;t не стоит опускаться до уровня собеседника?
Вы простите, но даже если у вас есть какие-то конструктивные доводы, то их очень трудно воспринимать в такой грубой форме. Я понимаю что не всегда это легко но все же.
Давайте жить дружно *)
В целом, ваш ответ скатывается в "мне тяжело изучать что-то новое, что хоть чуть сложнее того, что я уже знаю". Это не проблема языка или технологии. Это ваша проблема.
Это уже какие-то переходы на личности начались.
Это не моя проблема, это особенность языка Rust в нем очевидно порог вхождения больше чем в Go. Это не делает язык плохим, но отрицать это бессмысленно.
ну неужели нельзя было сделать так, чтобы вчерашний питонист, прошедший курсы, за один день въехал в раст.
Это кому вопрос? Разработчикам раста?
Неужели без дешевых манипуляций нельзя показать сильные стороны го?
Читаемость и порог вхождения. Ваши примеры тоже можно обвинить в манипулятивности. Давайте попробуем вести диалог без глупых наездов.
К тому же вы, манипулятивно, специально "усложнили" пример, потому что в 99% случаев строка будет выглядеть так:
warning: trait objects without an explicit `dyn` are deprecated
--> src/main.rs:4:33
|
4 | fn api_call() -> Result<String, Error> {
| ^^^^^ help: use `dyn`: `dyn Error`Удивительно, у меня работает почему-то и варнинга нет: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=99ec7409616dc291d6d118e1bdc7bc8f
И снова вы упорно отрицаете существование https://docs.rs/anyhow/
Повторюсь:
Неужели без дешевых манипуляций нельзя показать сильные стороны го?
Удивительно, у меня работает почему-то и варнинга нет:
Потому что вы определили свой тип Error, а я использовал трейт std::error::Error.
Определять свой набор ошибок для каждой функции выглядит не слишком лаконично и довольно утомительно. В go этого не требуется.
Про anyhow не знал. С этой библиотекой действительно выгладит лаконичнее.
use anyhow::Result;
fn api_call() -> Result<String> {
Ok("aaa".to_string())
}
fn main() {
api_call().ok();
}
Этот код что на расте в примере мне непонятен, а особенно будет весло его менять при необходимости и городить что угодно лишь бы вот эти map оставить, ведь модно-молодёжно)))
Лично для меня "map-reduce-filter" ухудшают читабельность кода и даже если пользуюсь языком в котором они есть никогда не использую а предпочитаю писать код по старинке с for и тд.
В начале 2022 года появятся дженерики, а вместе с ними и тонны библиотек для монад, функциональной обработки список и прочего.
Про map/filter/reduce был issue. Его ожидаемо отклонили, но написали, что потом запилят в рамках какого-то strams api.
https://github.com/golang/go/issues/45955#issuecomment-884406307
Единственное, что мне нравится в go, это "green-треды". Само собой, я уже привык и всюду писать if err !=nil, и к договорённости о коротких именах переменных и к невозможности запустить код, если ты что-то закомментировал и хочешь проверить.
Но привыкнуть можно к чему угодно, особенно, если за это платят, а как введут дженерики, то не придётся так часто копипастить.
Go хороший инструмент для примитивных сервисов где требуется хорошая паррарельность задач. Он не конкурент языкам из категории main-stream , но может успешно применяться для отдельных микросервисов …
Статьи про этот язык, часто вызывают срач в комментариях , потому-что люди думают, что этот инструмент некая волшебная пуля от всех бед и начинают использовать его там где это не нужно. Ну серьезно, вы же не забиваете гвозди с помощью отвертки ?
Go хорош не только для примитивных сервисов, но и в целом для бекенда, девопса, системных утилит и сервисов независимо от размера проекта. Но из-за примитивности синтаксиса он плохо подходит для геймдева, датасаенс и всего такого. В общем, на серебренную пулю он разумеется не тянет, но и совсем уж узким инструментом его не назовешь, мне кажется.
А вот срачей в комментах на счёт го как-то маловато, даже специально прошёлся по go-шному хабу. В этом плане, rust больше срачей триггерит, хотя это ничего не говорит про сам язык. :)
Ну , тут с вами можно поспорить основываясь на данных с hh .
-Бэкенд плотно заняли : Java, Python и C# , уже написано куча кода и библиотек …Переписывать это без крайней необходимости не будут
-DevOps : Python тут вообще король, такое количество библиотек и инструментов
-Системное программирование: C/C++ наше всё)
Go силен своей многопоточной моделью, корутины плохо подходят для выполнения сложных вычислений, но отлично для I/O задач.
Например, сервис уведомления пользователей, который должен рассылать кучу уведомлений в минуту.
Для больших проектов он плохо подходит из-за фактически отсутствующего ООП и странной обработки ошибок, но определенно своя ниша у него есть.
А срач часто возникает из-за «Java мерва, потому что Go есть» ну и подобных заголовков)
Go исполнилось 12 лет