На самом деле, тут все инструменты могут прекрасно дополнять друг друга. Никто не запрещает в одном проекте использовать их все вместе. Но если брать конкретные задачи (как например у Вас, если я правильно понял, экспорт и импорт), то какие-то инструменты будут для одной задачи подходить лучше, какие-то хуже.
Понимаю о чём Вы. Постараюсь объяснить свою идею этого сравнения. В статье я старался не сравнивать абстрактный механизм конкурентности в языке со всем остальным, я старался сравнить скорее плюсы и минусы применения конкретных инструментов к поставленной задаче.
С размещением там не так всё просто. Массивы могут размещаться на стеке, а срезы только на стеке и живут (но в срезах нет значений, они просто ссылки на массивы). Но при этом массивы могут убегать в кучу, если в них слишком много элементов.
Где-то в спецификации Go найти про это я не смог. Поисследовать поведение можно командой go build -gcflags="-m", она выводит информацию о том, кто уходит в кучу со стека.
GC тут в целом не причём, в первую очередь думаю это связано с попытками сделать более эффективное использование/переиспользование памяти. Я тоже пытался найти что-то на тему мотивации. Но подозреваю, что такое решение было принято внутри команды.
Оба раза b[1] изменит значение в массиве a, из-за того что len не выходит за границы cap. Но тут на самом деле даже интересней, потому что append перезапишет последний элемент массива a. Это связано с тем, что срез b создаётся со значением cap умещающимся в выделенную память для массива a. То есть другим языком если например взять срез a[:2] его значением cap в данном примере будет 6, несмотря на то, что len будет 2. И все append будут перезаписывать элементы исходного массива, пока len не выйдет за границы cap. Спасибо большое за этот пример, если не возражаете добавлю его в статью с упоминанием вас.
Я не смогу сейчас написать какие-то плюсы и минусы списком, потому что всё относительно, для кого-то отсутствие наследования в языке - минус, а кто-то назовёт это плюсом. Кому-то в проекте нужна максимальная безопасность, кому-то максимальная скорость написания кода. Но я могу немного верхнеуровнево рассказать про то, как они отличаются.
Несмотря на то, что эти языки любят сравнивать, они концептуально очень различные. Go создавался как простой язык для микросервисов в корпорации добра (Google), на нём нормально работает подход "сел и написал". Благодаря некоторой утиной типизации и своим подходам к классам, нет необходимости заранее проектировать интерфейс, потом проектировать иерархию классов, как например в Java. В этом весь Go - быстрый, относительно не сложный, не тебующий большой подготовки. К тому же у Гоши, на мой взгляд, очень удобная нативная система сопрограм.
Rust же совсем иной язык, он создавался как максимально быстрый и безопасный язык, без накладных расходов времени выполнения. Вокруг этого выстроена вся концепция языка, он не очень дружелюбен к разработчику, он ломает очень многие привычные вещи в голове и требует тщательного подхода к проектированию. В Rust мощная система типов, намного более богатая чем на данный момент в Go, есть свои важные фишки, вроде строгого определения текущего владельца объекта. Последнее нужно потому что в Rust нет сборщика мусора, от этого очень непривычно работать с переменными.
В целом, не стоит верить всему что пишут в интернете) Go и Rust очень интересные языки, я советую попробовать их оба и уже после определять для себя плюсы и минусы в конкретной задаче.
Возможно, для того, чтобы не забивать голову дополнительными мыслями) Проще намного везде использовать слайсы
Интересная штука, спасибо
Да, вариант. Ну и машинерия, кстати, тоже может использовать SQS
На самом деле, тут все инструменты могут прекрасно дополнять друг друга. Никто не запрещает в одном проекте использовать их все вместе. Но если брать конкретные задачи (как например у Вас, если я правильно понял, экспорт и импорт), то какие-то инструменты будут для одной задачи подходить лучше, какие-то хуже.
Спасибо за ваше дополнение и пример)
Благодарю.
Понимаю о чём Вы. Постараюсь объяснить свою идею этого сравнения. В статье я старался не сравнивать абстрактный механизм конкурентности в языке со всем остальным, я старался сравнить скорее плюсы и минусы применения конкретных инструментов к поставленной задаче.
Действительно) Большое спасибо)
С размещением там не так всё просто. Массивы могут размещаться на стеке, а срезы только на стеке и живут (но в срезах нет значений, они просто ссылки на массивы). Но при этом массивы могут убегать в кучу, если в них слишком много элементов.
Где-то в спецификации Go найти про это я не смог. Поисследовать поведение можно командой
go build -gcflags="-m", она выводит информацию о том, кто уходит в кучу со стека.Немного подробнее это объясняется в этой статье на медиуме.
GC тут в целом не причём, в первую очередь думаю это связано с попытками сделать более эффективное использование/переиспользование памяти.
Я тоже пытался найти что-то на тему мотивации. Но подозреваю, что такое решение было принято внутри команды.
Оба раза
b[1]изменит значение в массивеa, из-за того чтоlenне выходит за границыcap. Но тут на самом деле даже интересней, потому чтоappendперезапишет последний элемент массиваa. Это связано с тем, что срезbсоздаётся со значениемcapумещающимся в выделенную память для массиваa. То есть другим языком если например взять срезa[:2]его значениемcapв данном примере будет6, несмотря на то, чтоlenбудет2. И всеappendбудут перезаписывать элементы исходного массива, покаlenне выйдет за границыcap. Спасибо большое за этот пример, если не возражаете добавлю его в статью с упоминанием вас.Спасибо за уточнение, всё действительно так.
Я не смогу сейчас написать какие-то плюсы и минусы списком, потому что всё относительно, для кого-то отсутствие наследования в языке - минус, а кто-то назовёт это плюсом. Кому-то в проекте нужна максимальная безопасность, кому-то максимальная скорость написания кода. Но я могу немного верхнеуровнево рассказать про то, как они отличаются.
Несмотря на то, что эти языки любят сравнивать, они концептуально очень различные. Go создавался как простой язык для микросервисов в корпорации добра (Google), на нём нормально работает подход "сел и написал". Благодаря некоторой утиной типизации и своим подходам к классам, нет необходимости заранее проектировать интерфейс, потом проектировать иерархию классов, как например в Java. В этом весь Go - быстрый, относительно не сложный, не тебующий большой подготовки. К тому же у Гоши, на мой взгляд, очень удобная нативная система сопрограм.
Rust же совсем иной язык, он создавался как максимально быстрый и безопасный язык, без накладных расходов времени выполнения. Вокруг этого выстроена вся концепция языка, он не очень дружелюбен к разработчику, он ломает очень многие привычные вещи в голове и требует тщательного подхода к проектированию. В Rust мощная система типов, намного более богатая чем на данный момент в Go, есть свои важные фишки, вроде строгого определения текущего владельца объекта. Последнее нужно потому что в Rust нет сборщика мусора, от этого очень непривычно работать с переменными.
В целом, не стоит верить всему что пишут в интернете) Go и Rust очень интересные языки, я советую попробовать их оба и уже после определять для себя плюсы и минусы в конкретной задаче.
Большое спасибо.