Какой пакетный менеджер лучше взять?
Или "взрослое" решение пишется без пакетного менеджера?
Постепенно я дополняю её патчами.
major.new_minor.patch-unstable.1, major.new_minor.patch-unstable.2. Кстати, рекомендую выбрать какой-то более привычный prerelease-идентификатор вместо unstable, например alpha и beta.1.2.5 < 1.3.0-alpha.1 < 1.3.0-alpha.2 < 1.3.0-beta.1 < 1.3.03.5.7 нужно читать как "3-я версия API + 5-й набор фичей для этого API + 7-я версия патчей для этого набора фичей", то 4.0.0-beta.6 нужно читать как «вроде бы уже почти 4.0.0, но ещё непонятно сколько ещё косяков надо перепрыгнуть, чтобы добраться до 4.0.0. На глаз вроде бы уже немного осталось (beta), но это уже 6-я бета, а до неё ещё несколько альф было, поглядим сколько ещё багов нам заведут» 
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")
Первое что пришло в голову - таблица contactsнорм
1. 10.000 пользователей импортируют свои 100-200 контактов - в бд уже будет >1 млн записейэто мало
Если строк будет очень много, то будет ли тормозить обычный select? на userId и phoneNumber будут индексыс большой вероятностью не будет, но обычно если возникает вопрос, собирают тестовый стенд и проверяют самостоятельно.
Я знаю, что следует избегать всяких "продвинутых" штук из ряда связных списков, самореферентных структур и т.п.Односвязные списки никаких проблем не доставляют (ну кроме того, что они плохо ложатся на процессорный кэш). Для двусвязных списков и самореферентных структур придётся использовать сырые указатели и unsafe.
Ещё я обнаружил, что создание больших структур, с методами, с кучей полей, обычно приводит к проблемам с borrow checker.Borrow checker абсолютно плевать на размер структур. Это никак не связано.
А если в структуре будет ссылка или иное заимствование, то это гарантированные проблемы.Нет ни каких проблем.
Насколько я понимаю, самым рабочим выглядит чисто функциональный подход, а не структур с методами.Одно другому никак не противоречит.
И правильно ли я понимаю, что следует избегать структур хранящих ссылки и имеющими лайфтайм?Не правильно.
Так, наличие в умеренных размерах программе, которая по сути была одной функцией, лишь одной структуры хранящей ссылку, поставило крест на попытке структуризации программы в более человеческий вид.Что-то делаете не так. Без конкретных примеров кода сказать сложно.
И очень часто в Rust программах, мне приходится идти на более уродливую архитектуру, дабы избежать проблем с (почти ненужным в однопоточном коде) borrow checker.Что-то делаете не так. Скорее всего просто не понимаете borrow checker и пытаетесь писать на новом языке так, как привыкли в каком-то другом.
И в вопросе о borrow checker, разве не является тот факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке?О каком большинстве речь? Библиотеки используют мутабельные ссылки там где это нужно. Если метод действительно что-то меняет, то будет мутабельная ссылка ну и иногда будет использоваться interior mutability там где это необходимо. В языке нет проблем с мутабельными ссылками.
В общем, посоветуйте что-то что-бы помогало меньше бороться с borrow checker, потому что сейчас я очень много времени трачу именно на это.Для начала понять его. Понять какую проблему он решает. Почитайте, что такое undefined behavior. Почитайте, что такое алиасинг.
Или это просто такое количество кодовой базы на PHP накопилось, которую все дружно решили переписывать на Go
если да, то почему именно на Go?