Eugene Usachev

При превышении capacity адрес может измениться.
Довольно банальная оптимизация - если впереди необходимая память свободна, расширение происходит на месте, без переноса.

Проверить можно так

fn main() {
    let mut vec = Vec::with_capacity(2);
    let initial_ptr = vec.as_ptr();

    let (new_ptr, new_capacity) = std::iter::repeat(())
        .enumerate()
        .find_map(|(i, _)| {
            vec.push(i as i32 + 3);
            (vec.as_ptr() != initial_ptr).then(|| (vec.as_ptr(), vec.capacity()))
        })
        .unwrap();
    println!("Initial ptr: {:?}", initial_ptr);
    println!("New ptr: {:?}", new_ptr);
    println!("New capacity: {}", new_capacity);
}

При перемещении адрес на стеке изменится, а адрес памяти выделенной на куче - нет.
Тут очень тонкий момент, который нужно понимать, данные которые мы помещаем в Box или Vec будут размещены на куче, но сами Box и Vec - это такие же структуры, как и любые другие, просто на них есть некоторая логика для управления памятью на куче, в случае 64 битной архитектуры и T: Sized, Box<T> будет занимать 8 байт на стеке и размер T на куче, а Vec<T> - 24 байта на стеке (указатель на начало, длина и фактически выделенная память) и размер T умноженный на capacity на куче.

fn main() {
    let a = Box::new(42);
    println!("Stack address of a: {:p}", &a);
    println!("Heap address of a: {:p}", &*a);
    
    let b = a;
    println!("Stack address of b: {:p}", &b);
    println!("Heap address of b: {:p}", &*b);
}

Stack address of a: 0x7fff59586010
Heap address of a: 0x58cf76717b10
Stack address of b: 0x7fff59586018
Heap address of b: 0x58cf76717b10

Паузы во времени между пакетами для передачи пакетов из других потоков или те же самые ограничения на пропускную способность. А так же между отдельными сигналами кодирующими биты во время передачи. Поток состоит из времени передачи пакетов и пауз между пакетами. Соответственно пропускная способность - это объём данных переданных за определённое время. Пакет и байты в нём передаются всегда с максимальной скоростью, которую может выдать оборудование, поэтому и получается, что для отдельного пакета доступна вся скорость канала. А вот уже потоки делят канал друг с другом.

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

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

Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?

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

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.

У вас не создан файл go.mod в корне проекта. Выполните команду
go mod init github.com/yourname/yourproject
в корне проекта. Адрес может быть любой, принято указывать адрес вашего репозитория, но можете указать и несуществующий урл. Будет работать если указать не урл, а просто goproject, но так не принято и форматтеры кода будут путать ваш пакет со стандартной библиотекой.

У нас в файле shapes.go почему-то package goproject, хотя должен быть package utils

Потом замените ваш импорт на
import github.com/yourname/yourproject/utils""

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

Вдобавок многие популярные библиотеки пишут обучалки в формате Rust Book.

Какой пакетный менеджер лучше взять?

Conan или vcpkg, чё тут думать. Рекомендую Conan, но vcpkg тоже уже созревшее решение, сейчас они оба захватывают рынок.

Или "взрослое" решение пишется без пакетного менеджера?

А вы пилите библиотеку или законченное приложение? Опишите подробнее что у вас за программное средство. Требования сильно разные. Например:

• если это C++ библиотека - то я бы выбрал один из пакетных менеджеров и подготовил бы библиотеку для работы с ним. Например в случае Conan это значит написать conan-рецепт (который conanfile.py), который и будет "точкой входа" в вашу библиотеку: с помощью рецепта Conan узнаёт, как собирать библиотеку, какие у неё зависимости, как упаковывать в бинарный пакет, какие архитектуры и ОС поддерживаются и ещё кучу полезной информации, которую без ПМ обычно описывают ручками в README
  
• если это сетевой-сервис, например HTTP-бэкенд для чего-либо - ну тут стандартом индустрии является Docker/OCI-образ. Собираете образ под нужные комбинации архитектуры и ОС (см. multiplatform builds), заливаете в registry, и любой желающий запустит контейнер из вашего образа в своей инфраструктуре, или использует ваш образ как базовый для сборки своего
  
• если это десктопное приложение, неважно GUI или CLI - ну тогда обычно ожидается инсталляционный пакет под поддерживаемую ОС. Для Линуха это deb/rpm/flatpak/snap, для Венды - msix или exe, для Мака - dmg. Далее либо выкладываете для скачивания где-то на сайте, либо публикуетесь в магазинах типа Microsoft Store или Snapcraft
  

Опишите точнее ваш случай, я лучше посоветую что вам взять.

Самому заниматься установкой зависимостей есть смысл только для статически линкуемых библиотек. В этом случае самый простой вариант такие библиотеки оформить например как субмодуль git. Тогда при клонировании вашего репозитория скачаются исходники библиотеки. В cmake просто собираете ее как отдельный таргет и используете по назначению. Хорошо если библиотека уже поддерживает сборку через cmake - будет меньше возни. Если нет, то придется написать самому для нее CMakeLists.txt.

Для динамических библиотек стоит оставить удовлетворение зависимостей пользователю, потому что вариантов пакетных менеджеров много (вы хотите их все поддерживать?). В вашем CMakeLists.txt нужно только сделать тем или иным способом поиск установленного пакета и если его нет - выдачу ошибки и завершение сборки. Такие механизмы в cmake есть. Можно использовать выше приведенный find_package или например pkg_check_modules (который в свою очередь использует утилиту pkg-config).
Почти все более-менее серьезные приложения не пытаются установить самостоятельно свои зависимости при сборке. Можете проверить. Например: https://github.com/nginx/nginx?tab=readme-ov-file#...

Вы можете дополнительно к сборке приложения добавить и создание пакета для пакетного менеджера (или для нескольких пакетных менеджеров). Вот тут то вы и укажите необходимые приложению зависимости (в разных дистрибутивах линукс пакеты с зависимостями могут называться по разному). И тогда, когда пользователь будет устанавливать ваш пакет через пакетный менеджер все зависимости установятся автоматически.
В cmake есть механизм для создания пакетов для разных пакетных менеджеров: https://cmake.org/cmake/help/book/mastering-cmake/...

Постепенно я дополняю её патчами.

Непонятно какую схему вы планируете для разных unstable-версий. major.new_minor.patch-unstable.1, major.new_minor.patch-unstable.2. Кстати, рекомендую выбрать какой-то более привычный prerelease-идентификатор вместо unstable, например alpha и beta.

Также рекомендую подглядеть схему версионирования у какого-нибудь популярного крейта, например actix-web. Они используют предрелизные версии перед мажорными релизами.

Тут кстати встаёт вопрос, а так ли вам нужны предрелизы для ПАТЧ-версий библиотеки? Выглядит как чрезмерно детальное версионирование. Обычно когда публикуется патч-апдейт, и в нём обнаруживается баг, то просто выпускается новая версия с фиксом и со следующим patch-числом (т.е. была 2.5.2, потом вышла 2.5.3 с багом, для фикса которого выпустили 2.5.4).

Возможно я неправильно вас понял, и вы предполагали использовать предрелизы для новых минорных и мажорных версий - тогда это более разумное решение.

Собственно предрелизы на то и меньше релизов при операциях сравнения, что для этого и придуманы. Т.е. например:

1.2.5 < 1.3.0-alpha.1 < 1.3.0-alpha.2 < 1.3.0-beta.1 < 1.3.0

Чтобы пользоваться предрелизами правильно и потом не кусать локти из-за неудачно выбранной схемы, почитайте внимательно правила сравнения в спеке semver для предрелизов и подсмотрите в популярные пакеты как кто делает. Лично мы используем схему c alpha/beta плюс через точку номер предрелизного билда.

Схема именования предрелизов должна быть устроена так, чтобы решать задачу "приближения" к релизной версии. Если обычные 3.5.7 нужно читать как "3-я версия API + 5-й набор фичей для этого API + 7-я версия патчей для этого набора фичей", то 4.0.0-beta.6 нужно читать как «вроде бы уже почти 4.0.0, но ещё непонятно сколько ещё косяков надо перепрыгнуть, чтобы добраться до 4.0.0. На глаз вроде бы уже немного осталось (beta), но это уже 6-я бета, а до неё ещё несколько альф было, поглядим сколько ещё багов нам заведут»

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

Отмены задач используются, как ни странно, для отмены задач. А чтобы отменить задачу, это должно быть кому-нидуь нужно. Например, этим "кем-нибудь" часто бывает пользователь, которому результат задачи перестал быть нужным.

В качестве примера: пользователь послал на сервер через веб-страницу запрос и ждет результата. Представим, что запрос - сложный, результат так сразу не получить, запрос выполняется, а пользователь ждет, потому что всё это понимает. Потом пользователю внезапно надоедает ждать и он посылает команду Отменить. Или - закрывает страницу. Так вот, по-хорошему, в этом случае надо отменить задачу, которая выполняет запрос, чтобы она не тратила впустую ресурсы сервера.

А ещё отмена полезна для прерывания процессов потенциально бесконечных, типа смотреть, как горит огонь, как течет вода, как люди работают... :-)

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

import math

while True:
    a = int(input("ax^2+bx+c=0 / a: ")) 
    b = int(input("ax^2+bx+c=0 / b: "))
    c = int(input("ax^2+bx+c=0 / c: "))
    
    d = b ** 2 - 4 * a * c
    
    if d > 0:
        x1 = (-b + math.sqrt(d)) / (2 * a)
        x2 = (-b - math.sqrt(d)) / (2 * a)
        print(f'Корней: 2. \n x1 = {x1}')
        print(f'Корней: 2. \n x2 = {x2}')
        
    elif d == 0:
        x1 = -b / (2 * a)
        print(f'Корень: 1. \n x1 = {x1}')
        
    else:
        print("Корней: 0")