В российское IT пробралась повесточка

Величие его в том, что он значительно упрощает кооперацию между множеством людей на разных концах света и это значительный прогресс в сравнении с тем, что происходит в C/C++ и им подобных. Проблема только в том, кто этими репозиториями управляет, но это не значит, что нужно превращаться в неолуддита.

SourceForge, GitLab, CodeBerg, GitFlik и иже с ними кооперацию не упрощают? Или стадное чувство сильнее?

Это не стадное чувство, а сетевые эффекты. Да и вообще, монополизация – это естественный социально-экономический процесс, ибо зачастую централизованная структура тупо эффективнее.

Гитхаб заметно снижает порог входа для контрибьюторов в проект. Заслуживает ли проект контрибьюторов, которые пролезли через сниженный порог — вопрос который должны задать сами себе авторы проекта. И ответ не всегда «да».

А зачем ты ему даешь портить старое? Они в принципе не созданы на сроки жизни в неделю. Это автоматизация с довольно небольшим пока контекстом. Причем чаще всего одноразовая - зацикливаются на первых запросах.

Вот же чёрным по белому написано, что повесточные компании за это деньги предлагают.

Когда трендинговый инит перепишут на трендинговом системном ЯП ?

Величие его в том, что он значительно упрощает кооперацию между множеством людей на разных концах света и это значительный прогресс в сравнении с тем, что происходит в C/C++ и им подобных.

Сильнее, чем Git ?

Да и вообще, монополизация – это естественный социально-экономический процесс, ибо зачастую централизованная структура тупо эффективнее.

А тебя не смущает, что монополизация почти всегда приводит к снижению конкурентноспособности, загниванию и увеличению тарифов и других неприятностей?

git-то тут каким боком? VCS и до него, и после существовали, и намного лучшие.

git-то тут каким боком? VCS и до него, и после существовали, и намного лучшие.

Их и/или репозиториев артефактов недостаточно для кооперации разработчиков?

Чем bare git + ssh хуже git хостингов, если привык работать из консоли ?

Чем bare git + ssh хуже git хостингов

Отсутствием поиска. Если тебе нужна библиотека для чего-нибудь, нужен как минимум способ её поиска, желательно структурированный в виде некоего каталога. А расшаривать исходники среди группы разработчиков можно даже в CVS.

Типичный рабочий процесс почти везде, где я работал:

1. На любое изменение создаётся отдельная ветка aka feature branch.

2. Когда код готов он добавляется к основной ветке через запрос на слияние.

3. На каждое изменение запускаются тесты. Пока тесты не позволят, слияния не будет.

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

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

5. Опционально после слияния создаётся артефакт и отправляется в централизованное хранилище артефактов.

Расскажите, как вы это обеспечите на «bare git + ssh».

P.S. Задача со звёздочкой — интеграция с системами отслеживания ошибок.

Ну или так: git — хорошее средство для хранения кода. Но он вообще не покрывает (и не должен) вопросы организации общения и взаимодействия сообщества программистов и пользователей. Поэтому к нему нужно добавить что-то для оценки кода перед слиянием, отслеживания ошибок, непрерывной интеграции и доставки. Это как-минимум. Вопрос только в том, будет ли оно идти единым пакетом или придётся что-то сбоку прикручивать синей изолентой.

Расскажите

Вот это ты зря.

Не, ну а чо? Я свой CICD на git hooks писал, было дело, вот, хочу послушать как молодёжь перенимает эстафету.

Очнись, говорю, ничего ты не написал.

На основании чего такие выводы?

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

Так он ведь прав, что эти гно ЯП очень популярны?

Нюансов в них конечно много, и весьма неприятных.

Про пайтон вообще говорят, что на нём простые только hello-world от силы на пару сотен строк, а как доходит до больших проектов, начинается ад и вот это самое, т.е. непригоден для enterprise, ещё и датацентры пятон постоянно греет своей тормознутостью (разгоняет продажу мощных серваков и рост ДЦ).

А почему не хочет то? Почему туча библиотек для питона и js (к слову, для js их в десять раз больше, чем для питона - под два ляма уже)?

Либы CPython можно легко заюзать из нормальных ЯП на JVM (JRuby, Groovy, etc.) и .NET (C#, VB.NET, etc.)

Ржавые маняфантазии. C++ используется для написания нового софта, а раст только для бесполезного переписывания уже работающего. Языки не конкуренты друг другу.

Тогда бы уже сделали авто транспайлер из плюсиков в раст, встроенный прямо в конпилятор крестоносцев, и запретили бы ручной кодинг на расте, сразу бы уменьшилось количество холиваров ? :)

Но не для нее наплодили два ляма модулей. Не для нее дешевле и удобнее. Почему то дешевле стало запилить электрон.

Ну как можно сравнивать низкоуровневую сишку с динамическими ЯП ?

Давай уже, перепишем ядро Linux на JS, если он такой прекрасный ?

А какой код не говнокод? Есть идеальный код в вакууме?

Микроядро seL4?

$200/LoC - 10 лет назад, заметь, а сейчас с учётом инфляции уже вероятно под косарь (за 1 строчку кода!).

И ИИшки не напишут тебе проект. Они автоматизируют шаблонные блоки кода, которые ты уже задолбался писать вручную, да это и смысла не имеет, кроме чесания своего ЧСВ.

IMHO бредогенератор ИИ похож на поисковик по докам и примерам кода.

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

А как ты можешь сравнивать, коли кроме сишки ничего не знаешь?

А он хотя бы сишку знает? Можно линк на его гитхаб?

Стыдно признаться, но мне иногда хочется потрогать раст…

Походит на петтинг? Осторожнее!

Ну не однострочники, но целые блоки, функции, методы сделать может, если ты сам понимаешь как это все работает и объяснишь что надо.

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

Зато если ты понимаешь всю эту базу на одном языке, легко объяснишь ему что нужно сделать на другом. И он сделает. Конечно нюансы языка придется поизучать, но это мелочи.

Ну не однострочники, но целые блоки, функции, методы сделать может,

Качество кода ужасное получается, на от*бись.

если ты сам понимаешь как это все работает и объяснишь что надо.

Если не понимаешь, то в ИИ лучше вообще не лезти, потому что из генерёнки нужно уметь черипикать.

В любом случае нужно понимать все самому. Потому что у них инфа устаревшая

Сейчас IMHO уже в меньшей степени устаревшая, они отстают от актуальной инфы не так сильно, а ещё и «гуглить» научились.

, кривая,

Сильно зависит от промпта, который чтобы нормально составить, нужно быть уже хорошо в теме.

зато в базовых алгоритмах они шарят. Знают как правильно что организовать в общем смысле. Могут убрать лишнее дублирование и подобное.

Ни в чём ИИ не шарит, он только «догадывается» используя вероятностную математику по тем темам, которые живые человеки когда раньше написали в тырнете.

ИИ не создаёт оригинальные алгоритмы сам по себе, он умеет лишь быстро искать и подбирать похожие подходящие (временами лишь очень отдалённо) алгоритмы, написанные другими людьми в паблик.

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

Я надеюсь у противников rust’а, дома лежит такой же самый транспарант прошлых лет, где они были против systemd. Ведь методы внедрения и аргументация у них одинаковы =)

IMHO не совсем одинаковы, потому что systemd благополучно отпилили в нескольких популярных дистрах, а Rust отпилить маловероятно, поэтому на его пиар не нанимают всяких гопников типа zabbal.

Я потрогал. Жив. Психика в границах допустимого. Желудок вроде тоже в норме.

Так ведь движение в русле софтовой «повесточки» навряд ли приводит к психотронному подавлению ?

Ржавый ion-shell мне кстати тоже очень хорошо зашёл, IMHO bash, каким он должен был бы быть в идеале.

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

Вот мой ооочень старый и кривой код из самого начала изучения:

function testMarsh(tabella,diam)
	trovMarsh(tabella,diam)
		local rez = 0
		for k, v in pairs(mapTables[tabella]) do
			if type(k)=="string" then
				tKont = k
			end
			for k, v in pairs(mapTables[tabella][k]) do
				if type(k)=="string" then
					tLok = k
				end
			end
		end
		if testQ["schet1"] ~= nil then
			for i = testQ["schet1"]-10, testQ["schet1"]+10 do
				if testQ["schet"][i] ~= nil then
					marshrut(i,tablelength(mapTables[tabella][tKont][tLok]))
					rez = rez + testQ["schet"][i]
					if rez > 0 then
						break
					end
				end
			end
		end
	return rez
end

Сейчас попросил оптимизировать его:

function testMarsh(tabella, diam)
    trovMarsh(tabella, diam)

    local mapTable = mapTables[tabella]
    if not mapTable then
        return 0
    end

    -- Найти последний строковый ключ на первом уровне
    local tKont
    for k in pairs(mapTable) do
        if type(k) == "string" then
            tKont = k
        end
    end

    if not tKont or not mapTable[tKont] then
        return 0
    end

    -- Найти последний строковый ключ на втором уровне
    local tLok
    for k in pairs(mapTable[tKont]) do
        if type(k) == "string" then
            tLok = k
        end
    end

    if not tLok then
        return 0
    end

    local targetTable = mapTable[tKont][tLok]
    local length = tablelength(targetTable)

    if not testQ or not testQ["schet1"] or not testQ["schet"] then
        return 0
    end

    local schet1 = testQ["schet1"]
    local schet = testQ["schet"]
    local rez = 0

    for i = schet1 - 10, schet1 + 10 do
        local val = schet[i]
        if val ~= nil then
            marshrut(i, length)
            rez = rez + val
            if rez > 0 then
                break
            end
        end
    end

    return rez
end

Вот сравни. Мне они много базовых принципов оформления кода подсказали, до которых я сам бы доходил еще пару лет.

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

А вот в США бы такого не было?

Пиши в РКН жалобу на пропаганду нетрадиционных ценностей, там быстренько разберутся.

Единая точка отказа - центральный репозиторий?

Пакетный менеджер: Раст - карго, питон - пип, си - нет.

vcpkg, conan ?

Я не спорю, что есть сторонние инструменты. Но в том и проблема, что хер знает кто там что создал, в отличие от официальных. Ты их сначала найди, потом разберись в их нюансах реализации. А когда то не так уж и давно, не было и их.

А тут сразу тебе вот официальное. Единая система.

О том, что некие идиоты пытаются функцию операционной системы (пакетный менеджмент и репозиторий библиотек) подменить каким-то самодельным скачивателем мусора итд.

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

Языку не нужны никакие инфраструктуры, ему нужен компилятор и ничего более.

Можно согласиться, что ЯП не должен требовать внешнию центральную инфру принудительно.

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

Но ведь свои пакетные менеджеры есть почти у всех популярных ныне ЯП ? Разве это плохо? Ассортимент больше, версий либ НАМНОГО больше!

Ага, туда пихают то, что захотелось другим людям. Никакой разницы.

Так ведь пихают в т.ч. и то, что есть в дистрах, и то, чего там нет, т.е. в дистрах лишь жалкое подмножество того, что есть в языковых репозиториях.

Ты ограничен только своим потребительским отношением. Ты можешь использовать абсолютно любой компонент, но используешь только то, что есть в карго приговаривая мантры по актуальное и лучшее.

А что мешает одновременно использовать и языковый пакетный менеджер и самостоятельно вручную добавлять нужные сорцы из git и т.п. VCS?

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

Вот оно мне надо менять ось, версии либ, ломать все для остального софта просто для тестов моей новой софтины? А если она одним куском, как единый проект - там я уже в ее песочнице и ковыряю все как мне надо.

Еще и учти, 100500 этих уникальных самобытных дистрибутивов, где в каждом все по-своему.

Как по мне, релизные дистрибутивы в принципе потеряли смысл и должны вымереть. Это же глупость какая то - софт устаревает уже на момент выхода дистрибутива.

Что значит, софт устаревает? Для чего устаревает? Для поднятия гипервизора - оркестратора на физическом хосте или в облачной виртуалке? Так ведь если для этого брать более новые софт, чем в релизных дистрах, то будут проблемы со SLA?

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

Вот оно мне надо менять ось, версии либ, ломать все для остального софта просто для тестов моей новой софтины? А если она одним куском, как единый проект - там я уже в ее песочнице и ковыряю все как мне надо.

Контейнеризация и виртуализация же решает?

Я хочу высказаться о твоих умственных способностях, но правилами это запрещено.

Лучше аргументируй по технической части, иначе сам выглядишь как альтернативно одарённый.

А не хочешь рассказать о своих умственных способностях? У тебя это больная тема?

Это приём троллей, в т.ч. психотронщиков, когда они сливаются в споре, начинают обзываться всякими неприличными словами, в т.ч. прилагательными.

Тут спорно. Если в том же раст у меня «песочница» одной командой cargo, то с контейнеризацией уже все посложнее.

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

Так гитхаб не нужен. Очевидно, вокруг него собрались любители отдавать всё в какой-то центр,

В каком смысле отдавать?

несмотря даже на то то гит сам по себе децентрализованный - испортили это его единственное преимущество.

Чем испортили? Git перестал быть децентрализованный при параллельном использовании GitHub? Нельзя одновременно реплицироваться в свой локальный репозиторий и ещё несколько других self-hosted?

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

GitHub ведь не единственный managed git хостинг? Чем плохо их наличие? Чем это хуже облачного хостинга и вообще веб хостинга сайтеков хотя бы концептуально? Один из способов обмена информацией + удобные надстройки на git, хоть и проприетарные.

Очевидно, надо пользоваться нормальными ОС с нормальными пакетными менеджерами. Какая ОС и какой менеджер нормальный - забота юзера, не надо ему навязывать своё видение.

Он писал конкретно про гитхаб и я ответил про него же. Сами по себе «managed git хостинги», тем более самохостящиеся - другая тема, не вижу причин начинать тут её обсуждение.

То есть качество и сложность разработки должны зависеть от оси?

Вот поэтому сишка и вымирает. Потому что в нормальных языках этой зависимости нет. Я могу в любой оси сделать проект на раст и это будет один и тот же проект с одинаковым результатом.

Я написал код под линукс, добавил настройку сборки под винду, собрал - работает под виндой. Мне нахер не сдалось для этого устанавливать винду. Мне нахер не сдалось ставить твой несомненно самый правильный дистрибутив.

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

Если в том же раст у меня «песочница» одной командой cargo, то с контейнеризацией уже все посложнее.

Что там сложного на локалхосте в докере?

Для начала: docker run -ti --rm --name container2 debian bash

Или от простого к сложному:

• chroot - только своя файловая система, но на общем ядре, обычно для одного процесса

• docker - своя файловая система и сетка, но на общем ядре, обычно для одного процесса

• incus - почти вся ось - все процессы, включая init, но на общем ядре

• k8s - образно упрощённо многонодовый docker с кучей плагинов и надстроек

Очевидно, надо пользоваться нормальными ОС с нормальными пакетными менеджерами.

Можно пример?

Какая ОС и какой менеджер нормальный - забота юзера, не надо ему навязывать своё видение.

А кто навязывает? Использование языкового пакетного менеджера - это опция, внезапно даже для Rust ?

То есть качество и сложность разработки должны зависеть от оси?

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

Мне нахер не сдалось ставить твой несомненно самый правильный дистрибутив.

Не мой, а твой. Тот, который лично тебе удобнее всего. А не тот, который тебе пытаются навязать авторы разных языков, подменяя в сборочных системах функции ОС и меняя идеологию её поведения. Кстати, прибивание языка к сборочной системе - тоже плохая практика.

Ок ок, а модули либы откуда брать? У меня генту, я понимаю что такое контейнеризация, чрут.

Вот в cargo у меня поиск по модулям, гибкое управление их версиями, установка, удаление. Добавление, удаление.

diver ~/Games/wc/CircleL/Interface/AddOns/NSQC3 % cargo search tokio                                                   4:28:00
tokio = "1.48.0"                    # An event-driven, non-blocking I/O platform for writing asynchronous I/O backed applications…
tokio-netem = "0.1.1"               # tokio-netem — pragmatic AsyncRead, AsyncWrite I/O adapters for chaos & network emulation 
parsql-tokio-postgres = "0.5.0"     # Parsql için postgresql entegrasyonunu, tokio runtime ile birlikte sağlayan küfedir.
tokio-process-tools = "0.7.1"       # Interact with processes spawned by tokio. 
oxide-tokio-rt = "0.1.2"            # Shared Tokio runtime configuration for production Oxide software
tokio-channels-console = "0.1.0"    # Like tokio-console, but for channels.
console-subscriber = "0.5.0"        # A `tracing-subscriber::Layer` for collecting Tokio console telemetry. 
tokio-console = "0.1.14"            # The Tokio console: a debugger for async Rust. 
tokio-metrics = "0.4.5"             # Runtime and task level metrics for Tokio applications. 
hds_console-subscriber = "0.2.3"    # This is a test crate, do not use. 
... and 11093 crates more (use --limit N to see more)
note: to learn more about a package, run `cargo info <name>`
diver ~/Games/wc/CircleL/Interface/AddOns/NSQC3 %        

И вот, средствами оси:

calculate home # eix tokio
Совпадений не найдено.
calculate home #