Физически проблемы нет - электричество подведено, сотрудники едят. Оформить "уплату долга" можно 1001 бухгалтерским способом.
Даже при нулевой креативности - проблемы нет. Не привлекая заведомо отсутствующие представления об Африке, можно судить по себе - Россия как раз где-то в начале второй половины мира по благосостоянию, оценим масштаб. По $400 с человека - по $4, 400 руб, в месяц на десять лет, это копейки. На порядок с хвостиком снимается больше, причем не особо заметными для широких народных масс способами. Вот за то, чтобы этот поток немного перенаправить в другие карманы, и борется ИИ.
Кстати, если человек, скажем, с зарплаты пересаживается на пособие, а производство как шло - так и идет, то это эквивалентно выплате тысяч долларов в год. Немного проредить средний класс, а он будет прорежен что с ИИ что без такового...
Где-то я чииал про похожую систему с использованием в качестве радиатора стандартной домашней батареи отопления. И подумал, что делал бы чуть иначе: корпус заполняет жидкость с низкой температурой кипения, в нём расположен конус направляющий поднисмающиеся пузырьки к шлангу, шланг входит в батарею снизу, другой шланг выходит из батареи сверху и идёт в корпус мимо конуса. Тогда не нужно никаких насосов, жидкость увлекается пузырьками.
Корень проблемы в том, что за исходящий трафик платит владелец сервера. Достаточно минимальных изменений и проблема уйдёт - либо Вам будет плевать кто и сколько скачивает страницы, а то и чем больше - тем лучше будет, либо боты сами будут следить за тем, чтобы не активничать.
Можно придумать много схем реализации, каждая со своими интересантами, но они внедряются, ибо
интересанты уже толкаются локтями, хотя пока это и не бросается в глаза
можно спровоцировать переход на прямой обмен сообщениями без централизации, типа как в старину наука развивалась потому, что учёные писали друг-другу письма
Сама по себе борьба с ботами ничем обоснована быть не может, ибо боты действуют на благо Франции от имени и по поручению людей.
Ради чего Вы писали и/или хотите писать на Хабре? Я не буду угадывать ответ, но уже могу точно сказать - мотив наверняка создает карму, причем не ту, что на Хабре. Зачем Вам это (ещё и)? Нравится - пишите, не нравится - не пишите. Как в одном моём любимом мультике - а ещё есть такая городская легенда, что все мы живём в выдуманом мире ради чьего-то развлечения. И с Хабром так же.
Хабр - социальная сеть. Как у нас сейчас с социальными сетями? Вот Хабр и бесится, войдите в положение. Хотя некоторые вещи за гранью идиотизма, например, запрет на публикации или запрет на любые комментарии, или запрет на частоту любых комментариев. Последнее особенно интересно - на первый взгляд, это логичный шаг, а если присмотреться, то все как обычно с непроходимой глупостью - дьявол в детали, невозможность ответить человеку бъет по этому человеку сильнее, чем по тому, кто "наказывается" кармой. И что, страдать и жаловаться? Скорее оценить глубину положения в которое можно войти как до конца не изведанную...
Хабр уникален - здесь вроде успешные люди, в айтишечку вкатились, до недавнего времени зарабатывали хорошо, вроде при заслуженной элитарности, но чувствовали, по крайней мере наиболее чувствительные, что придётся в скорости про сломанный найм и прочая писать. Да и вечно зелёные темы типа как выучить английский и нужно ли образование в принципе на элитарности лежат напряженно.
Если интересно в эту кучу потыкать (иногда) остренькой палочкой (a.k.a. стимулом) и посмотреть за реакцией - можно слегка упасть в карме, но как иначе измерить уровень аудитории - я не придумал. Как в том же мультике - ну нету у них другого способа способности измерять.
Общий вывод - ради аудитории Хабра шевилить пальцем незачем, а ради собственного удовольствия либо прихоти - самое то. Написать что думаешь - прекрасный способ разобраться что же думаешь, и так далее.
Да, забыл - Вы пишете про дизлайк. Представьте себе того, кто его поставил и ему стало легче. Чтобы стало легче, должно быть плохо. Так что возвращаемся на square one - войдите в положение...
изучение языков происходит в агрессивно враждебной коммерциализированной среде, а то и реальности
изучение языка не может быть симулякром, а изучение иных "сложных" профессий - может, поэтому (массово) наблюдаются survivor bias мешающие учить язык нормально
частью изучения языка является перестройка структуры мозга, имеющая несколько характерных временных масштабов - потенциация или депрессия за минуты, спиногенез за часы, прунинг за сутки, начальный бренчинг за часы, структурный бренчинг дни и недели, ретракция за первые десятки минут, дегенерация за дни, глобальный прунинг за месяцы и годы, что однозначно задаёт темпоритм эффективного обучения для каждого конкретного мозга
особо трагично нарушение навязываемого предыдущим пунктом темпоритма в самом начале обучения, ибо прерывает таковое, так что я бы предложил, как минимальную страховку, следующий принцип: не можешь услышав фразу задать вопрос о непонятном - продолжай просто слушать, не можешь с хода привести пяток примеров на новое грамматическое правило - продолжай просто набирать лексику
мозг активно сопротивляется и перестройке и просто трате энергии, поэтому сам факт необходимости принятия решения по изучению языка - признак того, что впереди колоссальные трудности, что посоветывать пытающимся изучать язык ради чего-то, скажем работы, а не просто из любопытства или любования его красотой - я не знаю, разве что сменить работу
как когда-то говаривали (о покупателях) американские продавцы, "правда не то, что ты говоришь, а то, что они говорят", что применительно к языку означает - чужой язык учится много хуже своего, значит, делаем язык своим - постоянно, особенно при изучении грамматики, пытаемся понять - какая задача решалась, а как я бы сделал...
Это факты, а из домыслов от себя, пожалуй, добавлю: выучить язык как можно лучше, как можно легче, как можно быстрее - разные задачи, а принцип "чтобы бегать надо бегать" - удивительно универсален...
Неделя - это очень долго... Начинать писать после изучения синтаксиса - отрицать существование семантики...
Хорошая новость: в Go 1.22 это починили.
Не "починили", а "изменили". Видимо решив, что профессионалам проще, случай то редкий, поменять старый код при переходе на новый Go, чем слушать вой с болот.
Как только новичок осваивает горутины, он немедленно натыкается на это.
Либо новичок сомнительный, либо рядом не вполне новичок со склонностью к садизму. Новичок на вольном выпасе пишет горутины взаимодействующие через каналы и как раз у новичка именно такой проблемы нет совсем.
Ключевое слово тут — из функции, а не из цикла.
Как по мне, это точно ложится на границу между синтаксисом и семантикой. Как оно льёт воду на мою мельницу - ниже.
Go заставляет обрабатывать ошибки явно — это его фишка и его же главное раздражение для новичков.
Слово "явно" тут лишнее. А так - золотые слова.
Мы не можем отличить «не задал» от «задал ноль», потому что оба выглядят как 0.
Задачка со звёздочкой - придумать ещё три непонятки которые невозможно отличить глядя на голимый ноль. Это фича Go - нетривиальные и тривиальные случаи естественно, или задумано так, обрабатывать одинаково. С ошибками, кстати, то же самое...
Каналы — визитная карточка Go, и на них же приходится отдельный класс утечек.
Если так пишут - значит так и есть. Я бы ожидал другого - канал заставляет задуматься и можно предположить, что поэтому с ним проблем быть не должно совсем. Оказывается отнюдь. Полагаю что копипаста, да при поддержке ИИ...
Если присмотреться, почти все восемь ошибок растут из двух особенностей Go.
Как по мне - из всего одной. Язык сделан профессионалами для профессионалов так, чтобы и условным джунам было по возможности хорошо. Это личное впечатление такое.
Склонен предположить, что задача новичка в этом вашем "индустриальном программировании" - написать код так, чтобы удовлетворить им компилятор, и отдать его (вместе с ответственностью) может сеньору, а может и тестеру. Для этого точно нужно знать синтаксис, а семантику уже не обязательно. А знание семантики, по жизни, эквивалентно знанию деталей реализации, причём всех. Поэтому язык и сделан компактным. Вот тут то эту компактность и заприметили любители простоты...
некоторые вещи устроены не так, как в других языках,
Это можно сказать о любом языке.
компилятор строгий к синтаксису, но не к смыслу
Компилятор строгий к смыслу смысла не имеет, исключая маркетинговый. Если кто считает, что Rust, к примеру, строгий к смыслу - ну и считайте в радость, а остальные (незаметно) продолжат радоваться, что Go иной.
Расскажите, на чём спотыкались вы, когда переходили на Go.
Когда в некоторых моих наивных тестах Go обошёл C, у меня ожидания превзошли реальность. А потом я столкнулся с производительностью Go в WebAssembly.
Выше написали, что языки устаревают. Я такого не наблюдаю - редкие языки отмирают за крайней кривостью реализации, типа Снобол, даже не вспомню родную орфографию. Немного чаще хорошие языки искусно гнобят, как Delphi. Остальные, они же большинство, не устаревают, а продолжают развиваться - лежащие в их основании идеи никуда не деваются, может сходят с хайпа когда выясняется, что практической пользы меньше чем ожидалось. С, который за 20 лет изменился до неузнаваемости, он что, устарел? Или Fortran? Или Ada, которая не на слуху потому, что использующие её люди ну вот совсем не на слуху?
Поэтому ничего устаревшим не выглядит, разве что кажется. Мне вот кажется, что ";" в языке - это устаревшее, или препроцессор, но если подумать, то им находится применение. Устаревшими, точнее заьрошенными, могут быть библтотеки в какой-либо области.
Это у меня кармы на два комментария не хватает, сумимасен сталбыть.
Поэтомуя и удивляюсь, что в основе вопроса не чисто опыт использования да возможность полностью удержать на флешке. Глянул Zig и Go, правда на Линукс, к которым у меня по опыту использования вопросов нет вообще - на флешке локализуются полностью если установить переменные окружения. Наверно и с остальными обычно так.
К той куче, с которой начал, хочу добавить Racket, приемлема по скорости и открывает уникальную дорогу развития через построение DSL, и тоже вполне приятна в общении.
Задачи, особенно простые, решаются многими способами - тот же график функции можно в окошке видеть, окно закрыл - вот и нет его, а можно в svg записать, да ещё в html с комментариями обернуть, и хранить вечно, в смысле пока не надоест. Поэтому и удивляюсь, когда говорят что разные языки для разных задач, может и понял бы такое, если бы требования к качеству решений были заоблачные, а когда вокруг один отстой - не понимаю. И почему вместо этого не говорят что разные языки для разных людей - тоже не понимаю.
К С Вы не вполне справедливы, он компактен если не обращать внимания на историческое наследие которое в новых проектах можно игнорировать. Про Python не понял - пол гига всего не заметны на любой флешке которую сейчас можно купить, и гарантировано никогда не нужны все сразу. Ну и venv с эпигонами - в помощь.
Я пишу не потому, что ничего другого под спящей кошкой не остается, а "найти так найти" зацепило. С одной стороны, мой опыт однозначен - много сил потрачено чтобы было не найти, с другой стороны - Nim очаровывает..,
Наверно, просто каждый язык предназначен для решения своего круга задач.
С какого перепуга? Все языки полны по Тюрингу, все так или инаяе имеют FFI, сложившаяся чудовищная ситуация с одновременной раздробленностью и одновременно многократной дублированностью библиотек - чисто рукотворна руками архиподлых интересантов, что никак не есть языковый феномен. Язык для задач - та самая ложь, которая должна быть грандиозной...
Я тоже чуть не написал комментарий под той статьёй, в смысле что есть единственная причина по которой одного языка долго не будет - степень понимания того как решать задачу, на момент начала решения. На одном конце Rust, на другом конце Ruby...
Я не очень понимаю в чем проблема с флешкой - любой язык помещается на любую. В смартфон через Termux помещается немеряно языков, а к 10 гигам он у меня никогда даже не приближался. Медленно читается флешка и всё тормозит? Но ось должна кешировать... Язык полагается на наличие файлов в определённых местах? В истинно бытовой оси есть chroot... Почему не любой можно сделать бытовым? А про то, что большинство языков в бытовые не годятся потому что бесят - про это не спрашивают... хотя нет, спрашивают словами про простой язык и лёгкий транслятор... А раз так...
Может С? Язык простой, транслятор быстрый, особенно на фоне С++ или ужасов Rust, библиотек много, но систему сборки не всяк вытерпит.
Может Zig? Тот же С, только лучше, в проклятой сборке - много лучше. Библиотеки, не крайняк, берем из С. Помедленнее чуть, но не бесит точно.
Может Nim? Реально элегантно, компилируется или в С или в JavaScript, при нехватке библиотек обратно идем в С. Делают Nim несколько человек всего, но упёртых сверх всякой меры.
Может Lua? Это тоже целая вселенная, как Python, только маленькая. Есть Neovim как среда выполнения, есть Algernon для Web, есть Luau для песочницы, есть LuaJit для скорости, есть Roblox для детей...
Может Julia? Если процессор Интел и магазины приложений без надобности - очень хорошо.
Ну, а мой вариант исходит из того, что это всё они виноваты, это они языки плодят, выводят в топ худшие, давят W^X политикой и прочей "безопасностью", фрагментируют библиотеки, ломают найм, впаривают Wayland, проповедуют ИИ, вздувают цены... Поэтому быт надо налаживать там, где они не достанут!
То есть, лучший бытовой язык - JavaScript, любое выступление против для них запретительно дорого. Язык и простой, и достаточно быстрый, и для него хватает хотя бы одного не вполне убогого устройства - есть iPad, так пусть он и считает, а сервер может вообще на ладан дышать, а если есть, наоборот, относительно живой комп - тогда это он считает, а любая рухлядь только показывать будет...
Так что как по мне - акуна матата, нас не догонят, жаль только что Go, хуже всех способный меня доставать да выбешивать, как-то к слову не пришелся...
Давайте поговорим о слоне в комнате. В хорошем смысле и о хорошем слоне, разумеется.
Фронтенд с бэкендом определяется тем, при каком распределении работы между клиентом и саервером получается оптимальное решение. Оптимальность, разумеется, требует критериев оптимальности. В том, что я не вижу ни понимания этого факта, ни желания понимания, я вижу базовую причину того, что мы имеем то, что имеем.
Потому что пока люди пользуются интерфейсами, кто-то должен их создавать.
Воистину, но возможен вариант когда интерфейс каждый будет делать себе сам, почему - неважно. Может ИИ поможет, может прозрение снизойдёт... А может не будет ни делать ни пользовать, ИИ сам к себе интерфейс...
Как шальная мысль: Гейтс хотел поставить ПК на каждый стол, вот он и на каждом столе, и где нужнен, и где нет. Дивно индустриальное программирование, со всякими там джуниорами, сеньорами и санитарами тестерами - следствие этого обстоятельства. А ежели так, то не найм сломан и не фронтенд умирает, а возврат к естественной норме место алчет поиметь.
Если коротко - то всё вообще не так. Чисто для примера, из очень многого - что есть утилизация ОЗУ, что есть цель создания дистрибутива? И пошло-поехало... ерунда да тривиальщина.
У Линукс есть фундаментальные принципиально неразрешимые проблемы. Свобода выбора приводит к отсутствию единообразия - все Линуксы разные и программ просто "для Линукс" не бывает, и отсутствия единомыслия - улучшение одного ухудшает другое, поэтому под одно конкретное применение подобрать удобный дистрибутив можно, но чем больше на машине разных занятий - тем это сложнее с быстро наступающей невозможностью. Прямо сейчас всё усугубляется ИИ - на Маке или Винде ИИ может единообразно применяться по всей ОС, на Линукс - не может в принципе.
Петь про безболезненный переход на Линукс - подло, он возможен либо в качестве исключения, либо когда и переход на iPad ничем не хуже. А когда iPad, для нетребовательных - планшета на Андроид, недостаточно - вопрос скорее не в переходе как таковом, а в том наборе функций, которого не хватает. И тут возможны самые разные варианты, а не как в статье - типа выбор дистрибутива, а почему не пяти в меню загрузки, выбор DE, а почему не грузиться в консоль и из неё в один из пяти DE по планам на текущую половину дня, причём на монитор или headless - тоже выбор...
Линукс потерял лет двадцать на гуйных утилитах конфигурации, чудом не убился о контейнеризацию, чудом не убился о Wayland и сейчас, пока не пришла пора убиться об ИИ, вроде как улучшается - роль посредника между автором программы и пользователем сокращается.
Чтобы поставить .NET, официально, нужно сначала поставить один из поддерживаемых дистрибутивов, скачать скрипт и это будет аналог установщика для Винды. Один из - уже лучше чем ничего. Чтобы поставить Rust - нужно просто запустить скрипт, и это будет даже лучше чем установщик на Винде - само станет обновляться впредь, ad infinitum. Чтобы поставить Go, нужно распаковать архив - тоже неплохо ибо от дистрибутива не зависит. Что ситуация улучшается лично я заметил когда Julia стала устанавливаться скриптом... А когда средства разработки установлены, появляются их личные менеджеры пакетов, зело ортогональные дистрибутивам, и это тоже хорошо.
А плохо то, что весь Линукс вырубается под корень уничтожением весьма незначительного количества серверов. Или уничтожением дрступа к таковым...
Корпорации в японской поп-культуре - тема не столько не раскрыта, сколько не затронута. А там идёт потоками - и явное изображение наличиствующей корпоративной среды, и отрицательные последствия пребывания в ней, и не совсем отрицательные, а в другом мире если - даже положительные, и влияние на другие виды деятельности, зачастую - строительство процветающих государств (не сарказм), и отдельно по отраслям - в музыке так, в анимации, уж кому знать лучше как ни аниматорам, тоже так...
И вообще, с какой стороны поп-культура ни зайдёт, что 半沢直樹, что 株式会社マジルミエ, что 世話やきキツネの仙狐さん, что SHIROBAKO - корпорации выглядят одинаково и примерно так, как в статье и написано - значит всё правда.
Но не вся, конечно. По доносящимся из Японии теням, типа откуда дизайн мехов в 輪廻のラグランジェ или почему дверь такси открывается сама, или что было главным возражением против Walkman - легко заполозрить, что у темы большааая подводная часть.
А ещё я разрабатываю его потому что мне интересны комплияторы и потому что мне нечего делать.
Если интересны компиляторы сами по себе, то невозможна ситуация, когда
Но в последнее время очень тяжело что-либо делать.
Значит, не сами компиляторы. Тогда разработка компилятора - не лучший выбор, а упорствование в нём - форменное безумие. Если нечего делать при наличии минимум десятка превосходных компиляторов, то от добавления ещё одного чего делать не появится.
То, что я им делюсь с вами, значит, что я просто хочу небольшого признания и критики (объективной и конструктивной).
Вы не в том положении, чтобы претендовать на право выделять объективное и отличать конструктивное.
мне 16
Ваш мозг ещё не закончил развитие, через 5 лет Вы можете оказаться совсем другим человеком. Если Вас всё ещё будет интересовать программирование - значит просто повезло. Иначе, вспоминаем якобы турецкую поговорку
Не важно как далеко ты ушёл по неверной дороге - возвращайся назад.
Найти область которая увлечёт и затянет - это естественное стремление, в случае успеха жизнь станет лучше а думать впредь можно будет меньше. В случае неудачи, главное - не упорствовать.
Есть мнение, что когда человек делает то, что ему нужно, то ему помогает вся Вселенная (или Бог или боги или...), а когда то, что не нужно - тогда, соответственно, всё то же самое мешает. Есть другое мнение - трудности даются человеку для того, чтобы он их преодалевал. Каким мнением руководствоваться в каждом конкретном случае - становится понятно само собой годам к 60-ти.
Отложите ваш компилятор на месяц, если нужно - запретите себе о нём думать. Через месяц многое прояснится, я Вам это гарантирую.
Но тут полезно вспомнить, что лидер по компиляции и тулчейну для WASM - это Rust, а там корректность памяти обеспечена на этапе компиляции.
Ну, кто там лидер, Rust или C, особенно когда в браузер в лом лишние байты гнать - это можно долго обсуждать. А про обеспеченность чего-либо в Rust на этапе компиляции я очень сомневаюсь - без unsafe Rust работоспособен исключительно в corner cases. Да, я знаю, сочетание Rust с организационными мерами почти начинает что-то гарантировать, можете не кидаться этот ваш Rust защищать.
По поводу моделей, мои сугубо неверные любительские тесты скорости выполнения показали - у LuaJit и V8 она практически одинакова. Просто Lua, естественно, это беда, а Python - большая беда.
У WebAssembly, помимо отмеченного в статье, ещё способности обфусцировать код и обходить W^X политику. Последнее, например, позволяет (абы как) писать на С на iPad. Вот я и думаю, что именно эти две способности и определят будущее WebAssembly, а как именно политологи скажут лучше.
В этом месте я внезапно понял где же имнно мы фундаментально расходимся. Для Вас обсуждения - не пустой звук, как для меня, как альтернатива - бред, я привык к этому слову, хотя сейчас можно сказать красивее - галлюцинации. Для Вас документация в виде текста - Истина, для меня - третья, в лучшем случае - вторая, в исключительных случаях типа Rust - первая, но тень Истины. А Истина - это то, что выводится в терминал. Вам нужны источники - мне они интересны, иногда полезны, но никогда не нужны.
Go run делает исполняемый файл из одного файла? Делает. На этом, вообще-то, дискуссия может и закончиться. А может и нет, если недоумевающий заметит - но ведь в этом файле явно написано package main, это же пакет. Так вот, этот main, сколько ни пиши перед ним package, это не пакет, это команда. Об этом даже написано, если правильно помню, в go help, подкоманду не помню. Был бы пакет - его бы импортировали в другие пакеты...
В документации, например, написано, что файлы для go run должны быть в одной папке. А по жизни вовсе и нет, ибо go run следует символическим ссылкам. На практике, помнится, go run со ссылками идеально подходит для обучения, осбенно пока часты "сначала попробую так, а потом эдак и ещё через задницу непременно", а документация тупо портит experience путаясь под ногами.
Этим я хочу сказать, что "истинного" подхода к изучению нет, особенно в формате таких статей. Это как давний спор, с какого языка программирования "правильнее" начинать.
А вот это фундаментально. Да, люди отличаются целями и способностями, единого истинного (почему в кавычках, чего тут стесняться?) подхода нет. Но стоит отсечь по способностям на достаточно высоком уровне и хотя бы примерно определиться с целями, как истинный подход немедленно появляется, просто потому, что разумных подходов мало.
Абсолютно аналогично, тут Вы правы, и с языком с которого правильнее начинать. В отличии от подходов к обучению, языков много, что позволяет заметить, что отсутствие самого правильного, в том числе в силу размытия критериев, не исключает наличия отношений "всегда лучше" и "заведомо хуже", пусть и не между любой парой языков.
В самом начале статьи я четко обозначил формат: это мой интерактивный личный учебник, а не академическое пособие.
На 100% личного в публичном поле не бывает и никакая "личностность" право творить что угодно не даёт. Ещё в далёком прошлом врачи это сформулировали как принцип "не навреди".
Сам изучал да писал или несвежий текст скопипастил?
├── main.go <-- Go файл корневого пакета ├── fmt/ <-- Пакет fmt │ └── printer.go <-- Go файл пакета fmt
Стандартную библиотеку переписывать кто подучил? Какой такой гипотетический бред? Сами хотите запутаться - отлично, но держите такое не на виду.
Оставим данный вариант импорта просто для некого "знания", что такой способ когда-то использовался, сейчас, вероятно, из-за того, что большинство проектов пишутся в модульном варианте такой способ не используется.
ЧТО ЗНАЧИТ ВЕРОЯТНО?! Какой такой вариант импорта? Импорт в Go всегда один и тот же, а вот режимов поиска два - режим модуля и режим GOPATH. И оба, как это ни сложно себе представить после долгтх лет копипасты на Python и JavaScript, используются оба.
Поэтому я решил устроить эксперимент и разбирать Go прямо в публичном поле, шаг за шагом документируя весь процесс.
Идея прекрасная, а процесс дурацкий.
Я возьму за основу официальный трек обучения от создателей языка и постараюсь подробно разобрать как Go устроен.
Наверно дело как раз в этом. То, что Вы приняли за трек обучения, это никакой не трек, никакого обучения от него не будет, это tour, то есть экскурсионная развлекательная поездка. Её задача - дать тому, кому Go не зайдёт, возможность почувствовать это как можно раньше. А тому, кому зайдёт, возможность в этом убедиться тоже как можно раньше, что-то в процессе написав, глупо или нет - пока не важно.
Переписывать такое своими словами - цензурных слов у меня нет. Но напомню, я писал - идея прекрасная. Потому, что на сайте Go недавно произошла катастрфа, последовательная документация уровня одновременно доступного и достаточного для изучения - исчезла, вместо неё трудно читаемая reference и другие, в смысле кроме tour, весёлые истории.
Я могу понять это двумя способами. Первый, от разглядывания страницы https://go.dev/learn/ - это чтобы лучше продовались курсы и книжки, нет причин выкладывать бесплатно то, что есть надежда продать. Второй, от желания оправдать дьявола - это потому, что набор рассказов по поводу достаточен для освоения чтения reference, которому всякому не мечтающему о статусе вечного джуна, особенно внезапно не вечного в силу ИИ, всё равно придётся придаться.
Разбираться с Go нужно с ввода
go help
go help environment
go help run
go help packages
go help modules
go help modules-auth
go help build
После чего можно или продолжить изучение, или написать о том, о чём в статье и написано, только совсем иначе. Без такого вот
Значит, можно сказать, что пакет - это атомарная, неделимая единица компиляции. Именно то, что компилируются вместе в единый неделимый блок,
ибо так сказать можно только с целью опозориться, ибо неделимая единица компиляции в Go, кто бы мог подумать, есть файл.
А лучше - начинать не с того, какая там "структура проекта", а как выполнить код на Go. Когда он в одном файле. Или в трёх. А случай когда в тысяче, вместе со структурой проекта, отложить на потом. Ну, разве что упомянуть почему зависимости структуре проекта ортогональны.
Постоянно случаются вещи, которых я не понимаю. Вот опять.
Какая радость от того, что принципиально медленный язык начнёт хоть что-то делать раньше? Всех всегда интересует когда то да сё будет готово...
Такая загрузка модулей может помочь тогда, когда существенная часть загружаемого заведомо так и не понадобится. Какая именно часть - зависит от данных, каждый раз она разная. То есть, так лучше чем никак.
А вот загрузка модулей параллельно в другом thread помогала бы и больше, и всегда.
Плачьте громче, на это смотреть весело. Ну, может не всем весело, но кто видел настоящих бизнесменов - тем точно. HR и найм - производные от бизнес климата, а бизнес климат... ну, сами знаете. Поэтому и "HR‑проблемы удивительно универсальны".
Рискну обобщить - как в этой стране хотели молока без коровы, так и хотят. Как ставили телегу впереди лошади, так и ставят. Удачи!
Сама идея искать идеального кандидата - это для ну очень рядовых предпринимателей. Мастер предприниматель видит человека, хватает его раньше других ибо не один он такой, и смотрит как теперь изменить бизнес процессы так, чтобы изменившаяся команда была максимально эффективна. Сейчас, через год, через 10 лет...
Сама идея подбирать людей под бизнес - тоже для середнячков в лучшем случае. Как и идея придумать и осуществить бизнес стратегию по схеме придумал - подобрал - они сделали. У мастера процесс не линейный: придумал, подобрал, дал поработать, оценил возможности которые иногда ошибочно именуют компетенциями, и назад на square one.
Иными словами, не от задачи к поиску ресурсов, а от ресурсов к формулировке задачи. Работает во всех случаях кроме того, когда ресурс - административный.
Одна мысль в подарок. Учитесь бизнесу? А с какой статми кто-то расскажет вам что именно даёт ему реальное конкурентное преимущество? Учитесь на опыте тех, кто, да хоть сколь угодно раз и за рубежом, идёт (той же дорогой) в никуда? Удачи! Впрочем, я повторяюсь...
"В добыче отсутствие сменного мастера может стоить компании миллионы в сутки" - Да неужели? Разве не классика - если при исчезновении начальника проблемы появляются раньше, чем через месяц, то работа была организована неверно...
"Хорошая новость в том, что приборы можно построить" - Это точно хорошая новость? Предприниматель спихивает признание своей некомпетености на HR, без приборов HR воет. С приборами - спихивает дальше, на приборы...
Я потому и стал читать, что автор из Ленты. А Лента - как раз на правильном пути меня кормить. Вкусвилл немного переусложняет в погоне за псевдоизысками, на мой вкус. Про остальные, Пятерочку, Магнит, Перекресток, Семафор - только названия слышал.
Лента сначала брать деньги а потом собирать не может, для этого нужен либо высокотехнологичный автоматизированный склад, типа находить конкретные огурцы чтобы в сумме был точный вес, такого у них нету, либо торговать только стандартными упаковками, а это не их стиль. И классический выбор между показом близкого к исчерпанию товара как отсутствующего и необходимостью иногда обсуждать с клиентом замену Лента делает в пользу последнего.
Физически проблемы нет - электричество подведено, сотрудники едят. Оформить "уплату долга" можно 1001 бухгалтерским способом.
Даже при нулевой креативности - проблемы нет. Не привлекая заведомо отсутствующие представления об Африке, можно судить по себе - Россия как раз где-то в начале второй половины мира по благосостоянию, оценим масштаб. По $400 с человека - по $4, 400 руб, в месяц на десять лет, это копейки. На порядок с хвостиком снимается больше, причем не особо заметными для широких народных масс способами. Вот за то, чтобы этот поток немного перенаправить в другие карманы, и борется ИИ.
Кстати, если человек, скажем, с зарплаты пересаживается на пособие, а производство как шло - так и идет, то это эквивалентно выплате тысяч долларов в год. Немного проредить средний класс, а он будет прорежен что с ИИ что без такового...
Где-то я чииал про похожую систему с использованием в качестве радиатора стандартной домашней батареи отопления. И подумал, что делал бы чуть иначе: корпус заполняет жидкость с низкой температурой кипения, в нём расположен конус направляющий поднисмающиеся пузырьки к шлангу, шланг входит в батарею снизу, другой шланг выходит из батареи сверху и идёт в корпус мимо конуса. Тогда не нужно никаких насосов, жидкость увлекается пузырьками.
Корень проблемы в том, что за исходящий трафик платит владелец сервера. Достаточно минимальных изменений и проблема уйдёт - либо Вам будет плевать кто и сколько скачивает страницы, а то и чем больше - тем лучше будет, либо боты сами будут следить за тем, чтобы не активничать.
Можно придумать много схем реализации, каждая со своими интересантами, но они внедряются, ибо
интересанты уже толкаются локтями, хотя пока это и не бросается в глаза
можно спровоцировать переход на прямой обмен сообщениями без централизации, типа как в старину наука развивалась потому, что учёные писали друг-другу письма
Сама по себе борьба с ботами ничем обоснована быть не может, ибо боты действуют
на благо Францииот имени и по поручению людей.Ради чего Вы писали и/или хотите писать на Хабре? Я не буду угадывать ответ, но уже могу точно сказать - мотив наверняка создает карму, причем не ту, что на Хабре. Зачем Вам это (ещё и)? Нравится - пишите, не нравится - не пишите. Как в одном моём любимом мультике - а ещё есть такая городская легенда, что все мы живём в выдуманом мире ради чьего-то развлечения. И с Хабром так же.
Хабр - социальная сеть. Как у нас сейчас с социальными сетями? Вот Хабр и бесится, войдите в положение. Хотя некоторые вещи за гранью идиотизма, например, запрет на публикации или запрет на любые комментарии, или запрет на частоту любых комментариев. Последнее особенно интересно - на первый взгляд, это логичный шаг, а если присмотреться, то все как обычно с непроходимой глупостью - дьявол в детали, невозможность ответить человеку бъет по этому человеку сильнее, чем по тому, кто "наказывается" кармой. И что, страдать и жаловаться? Скорее оценить глубину положения в которое можно войти как до конца не изведанную...
Хабр уникален - здесь вроде успешные люди, в айтишечку вкатились, до недавнего времени зарабатывали хорошо, вроде при заслуженной элитарности, но чувствовали, по крайней мере наиболее чувствительные, что придётся в скорости про сломанный найм и прочая писать. Да и вечно зелёные темы типа как выучить английский и нужно ли образование в принципе на элитарности лежат напряженно.
Если интересно в эту кучу потыкать (иногда) остренькой палочкой (a.k.a. стимулом) и посмотреть за реакцией - можно слегка упасть в карме, но как иначе измерить уровень аудитории - я не придумал. Как в том же мультике - ну нету у них другого способа способности измерять.
Общий вывод - ради аудитории Хабра шевилить пальцем незачем, а ради собственного удовольствия либо прихоти - самое то. Написать что думаешь - прекрасный способ разобраться что же думаешь, и так далее.
Да, забыл - Вы пишете про дизлайк. Представьте себе того, кто его поставил и ему стало легче. Чтобы стало легче, должно быть плохо. Так что возвращаемся на square one - войдите в положение...
Всё же очевидно, даже без ИИ.
изучение языков происходит в агрессивно враждебной коммерциализированной среде, а то и реальности
изучение языка не может быть симулякром, а изучение иных "сложных" профессий - может, поэтому (массово) наблюдаются survivor bias мешающие учить язык нормально
частью изучения языка является перестройка структуры мозга, имеющая несколько характерных временных масштабов - потенциация или депрессия за минуты, спиногенез за часы, прунинг за сутки, начальный бренчинг за часы, структурный бренчинг дни и недели, ретракция за первые десятки минут, дегенерация за дни, глобальный прунинг за месяцы и годы, что однозначно задаёт темпоритм эффективного обучения для каждого конкретного мозга
особо трагично нарушение навязываемого предыдущим пунктом темпоритма в самом начале обучения, ибо прерывает таковое, так что я бы предложил, как минимальную страховку, следующий принцип: не можешь услышав фразу задать вопрос о непонятном - продолжай просто слушать, не можешь с хода привести пяток примеров на новое грамматическое правило - продолжай просто набирать лексику
мозг активно сопротивляется и перестройке и просто трате энергии, поэтому сам факт необходимости принятия решения по изучению языка - признак того, что впереди колоссальные трудности, что посоветывать пытающимся изучать язык ради чего-то, скажем работы, а не просто из любопытства или любования его красотой - я не знаю, разве что сменить работу
как когда-то говаривали (о покупателях) американские продавцы, "правда не то, что ты говоришь, а то, что они говорят", что применительно к языку означает - чужой язык учится много хуже своего, значит, делаем язык своим - постоянно, особенно при изучении грамматики, пытаемся понять - какая задача решалась, а как я бы сделал...
Это факты, а из домыслов от себя, пожалуй, добавлю: выучить язык как можно лучше, как можно легче, как можно быстрее - разные задачи, а принцип "чтобы бегать надо бегать" - удивительно универсален...
Неделя - это очень долго... Начинать писать после изучения синтаксиса - отрицать существование семантики...
Не "починили", а "изменили". Видимо решив, что профессионалам проще, случай то редкий, поменять старый код при переходе на новый Go, чем слушать вой с болот.
Либо новичок сомнительный, либо рядом не вполне новичок со склонностью к садизму. Новичок на вольном выпасе пишет горутины взаимодействующие через каналы и как раз у новичка именно такой проблемы нет совсем.
Как по мне, это точно ложится на границу между синтаксисом и семантикой. Как оно льёт воду на мою мельницу - ниже.
Слово "явно" тут лишнее. А так - золотые слова.
Задачка со звёздочкой - придумать ещё три непонятки которые невозможно отличить глядя на голимый ноль. Это фича Go - нетривиальные и тривиальные случаи естественно, или задумано так, обрабатывать одинаково. С ошибками, кстати, то же самое...
Если так пишут - значит так и есть. Я бы ожидал другого - канал заставляет задуматься и можно предположить, что поэтому с ним проблем быть не должно совсем. Оказывается отнюдь. Полагаю что копипаста, да при поддержке ИИ...
Как по мне - из всего одной. Язык сделан профессионалами для профессионалов так, чтобы и условным джунам было по возможности хорошо. Это личное впечатление такое.
Склонен предположить, что задача новичка в этом вашем "индустриальном программировании" - написать код так, чтобы удовлетворить им компилятор, и отдать его (вместе с ответственностью) может сеньору, а может и тестеру. Для этого точно нужно знать синтаксис, а семантику уже не обязательно. А знание семантики, по жизни, эквивалентно знанию деталей реализации, причём всех. Поэтому язык и сделан компактным. Вот тут то эту компактность и заприметили любители простоты...
Это можно сказать о любом языке.
Компилятор строгий к смыслу смысла не имеет, исключая маркетинговый. Если кто считает, что Rust, к примеру, строгий к смыслу - ну и считайте в радость, а остальные (незаметно) продолжат радоваться, что Go иной.
Когда в некоторых моих наивных тестах Go обошёл C, у меня ожидания превзошли реальность. А потом я столкнулся с производительностью Go в WebAssembly.
Выше написали, что языки устаревают. Я такого не наблюдаю - редкие языки отмирают за крайней кривостью реализации, типа Снобол, даже не вспомню родную орфографию. Немного чаще хорошие языки искусно гнобят, как Delphi. Остальные, они же большинство, не устаревают, а продолжают развиваться - лежащие в их основании идеи никуда не деваются, может сходят с хайпа когда выясняется, что практической пользы меньше чем ожидалось. С, который за 20 лет изменился до неузнаваемости, он что, устарел? Или Fortran? Или Ada, которая не на слуху потому, что использующие её люди ну вот совсем не на слуху?
Поэтому ничего устаревшим не выглядит, разве что кажется. Мне вот кажется, что ";" в языке - это устаревшее, или препроцессор, но если подумать, то им находится применение. Устаревшими, точнее заьрошенными, могут быть библтотеки в какой-либо области.
Это у меня кармы на два комментария не хватает, сумимасен сталбыть.
Поэтомуя и удивляюсь, что в основе вопроса не чисто опыт использования да возможность полностью удержать на флешке. Глянул Zig и Go, правда на Линукс, к которым у меня по опыту использования вопросов нет вообще - на флешке локализуются полностью если установить переменные окружения. Наверно и с остальными обычно так.
К той куче, с которой начал, хочу добавить Racket, приемлема по скорости и открывает уникальную дорогу развития через построение DSL, и тоже вполне приятна в общении.
Задачи, особенно простые, решаются многими способами - тот же график функции можно в окошке видеть, окно закрыл - вот и нет его, а можно в svg записать, да ещё в html с комментариями обернуть, и хранить вечно, в смысле пока не надоест. Поэтому и удивляюсь, когда говорят что разные языки для разных задач, может и понял бы такое, если бы требования к качеству решений были заоблачные, а когда вокруг один отстой - не понимаю. И почему вместо этого не говорят что разные языки для разных людей - тоже не понимаю.
К С Вы не вполне справедливы, он компактен если не обращать внимания на историческое наследие которое в новых проектах можно игнорировать. Про Python не понял - пол гига всего не заметны на любой флешке которую сейчас можно купить, и гарантировано никогда не нужны все сразу. Ну и venv с эпигонами - в помощь.
Я пишу не потому, что ничего другого под спящей кошкой не остается, а "найти так найти" зацепило. С одной стороны, мой опыт однозначен - много сил потрачено чтобы было не найти, с другой стороны - Nim очаровывает..,
С какого перепуга? Все языки полны по Тюрингу, все так или инаяе имеют FFI, сложившаяся чудовищная ситуация с одновременной раздробленностью и одновременно многократной дублированностью библиотек - чисто рукотворна руками архиподлых интересантов, что никак не есть языковый феномен. Язык для задач - та самая ложь, которая должна быть грандиозной...
Я тоже чуть не написал комментарий под той статьёй, в смысле что есть единственная причина по которой одного языка долго не будет - степень понимания того как решать задачу, на момент начала решения. На одном конце Rust, на другом конце Ruby...
Я не очень понимаю в чем проблема с флешкой - любой язык помещается на любую. В смартфон через Termux помещается немеряно языков, а к 10 гигам он у меня никогда даже не приближался. Медленно читается флешка и всё тормозит? Но ось должна кешировать... Язык полагается на наличие файлов в определённых местах? В истинно бытовой оси есть chroot... Почему не любой можно сделать бытовым? А про то, что большинство языков в бытовые не годятся потому что бесят - про это не спрашивают... хотя нет, спрашивают словами про простой язык и лёгкий транслятор... А раз так...
Может С? Язык простой, транслятор быстрый, особенно на фоне С++ или ужасов Rust, библиотек много, но систему сборки не всяк вытерпит.
Может Zig? Тот же С, только лучше, в проклятой сборке - много лучше. Библиотеки, не крайняк, берем из С. Помедленнее чуть, но не бесит точно.
Может Nim? Реально элегантно, компилируется или в С или в JavaScript, при нехватке библиотек обратно идем в С. Делают Nim несколько человек всего, но упёртых сверх всякой меры.
Может Lua? Это тоже целая вселенная, как Python, только маленькая. Есть Neovim как среда выполнения, есть Algernon для Web, есть Luau для песочницы, есть LuaJit для скорости, есть Roblox для детей...
Может Julia? Если процессор Интел и магазины приложений без надобности - очень хорошо.
Ну, а мой вариант исходит из того, что это всё они виноваты, это они языки плодят, выводят в топ худшие, давят W^X политикой и прочей "безопасностью", фрагментируют библиотеки, ломают найм, впаривают Wayland, проповедуют ИИ, вздувают цены... Поэтому быт надо налаживать там, где они не достанут!
То есть, лучший бытовой язык - JavaScript, любое выступление против для них запретительно дорого. Язык и простой, и достаточно быстрый, и для него хватает хотя бы одного не вполне убогого устройства - есть iPad, так пусть он и считает, а сервер может вообще на ладан дышать, а если есть, наоборот, относительно живой комп - тогда это он считает, а любая рухлядь только показывать будет...
Так что как по мне - акуна матата, нас не догонят, жаль только что Go, хуже всех способный меня доставать да выбешивать, как-то к слову не пришелся...
Давайте поговорим о слоне в комнате. В хорошем смысле и о хорошем слоне, разумеется.
Фронтенд с бэкендом определяется тем, при каком распределении работы между клиентом и саервером получается оптимальное решение. Оптимальность, разумеется, требует критериев оптимальности. В том, что я не вижу ни понимания этого факта, ни желания понимания, я вижу базовую причину того, что мы имеем то, что имеем.
Воистину, но возможен вариант когда интерфейс каждый будет делать себе сам, почему - неважно. Может ИИ поможет, может прозрение снизойдёт... А может не будет ни делать ни пользовать, ИИ сам к себе интерфейс...
Как шальная мысль: Гейтс хотел поставить ПК на каждый стол, вот он и на каждом столе, и где нужнен, и где нет. Дивно индустриальное программирование, со всякими там джуниорами, сеньорами и
санитарамитестерами - следствие этого обстоятельства. А ежели так, то не найм сломан и не фронтенд умирает, а возврат к естественной норме место алчет поиметь.Just saying.
Если коротко - то всё вообще не так. Чисто для примера, из очень многого - что есть утилизация ОЗУ, что есть цель создания дистрибутива? И пошло-поехало... ерунда да тривиальщина.
У Линукс есть фундаментальные принципиально неразрешимые проблемы. Свобода выбора приводит к отсутствию единообразия - все Линуксы разные и программ просто "для Линукс" не бывает, и отсутствия единомыслия - улучшение одного ухудшает другое, поэтому под одно конкретное применение подобрать удобный дистрибутив можно, но чем больше на машине разных занятий - тем это сложнее с быстро наступающей невозможностью. Прямо сейчас всё усугубляется ИИ - на Маке или Винде ИИ может единообразно применяться по всей ОС, на Линукс - не может в принципе.
Петь про безболезненный переход на Линукс - подло, он возможен либо в качестве исключения, либо когда и переход на iPad ничем не хуже. А когда iPad, для нетребовательных - планшета на Андроид, недостаточно - вопрос скорее не в переходе как таковом, а в том наборе функций, которого не хватает. И тут возможны самые разные варианты, а не как в статье - типа выбор дистрибутива, а почему не пяти в меню загрузки, выбор DE, а почему не грузиться в консоль и из неё в один из пяти DE по планам на текущую половину дня, причём на монитор или headless - тоже выбор...
Линукс потерял лет двадцать на гуйных утилитах конфигурации, чудом не убился о контейнеризацию, чудом не убился о Wayland и сейчас, пока не пришла пора убиться об ИИ, вроде как улучшается - роль посредника между автором программы и пользователем сокращается.
Чтобы поставить .NET, официально, нужно сначала поставить один из поддерживаемых дистрибутивов, скачать скрипт и это будет аналог установщика для Винды. Один из - уже лучше чем ничего. Чтобы поставить Rust - нужно просто запустить скрипт, и это будет даже лучше чем установщик на Винде - само станет обновляться впредь, ad infinitum. Чтобы поставить Go, нужно распаковать архив - тоже неплохо ибо от дистрибутива не зависит. Что ситуация улучшается лично я заметил когда Julia стала устанавливаться скриптом... А когда средства разработки установлены, появляются их личные менеджеры пакетов, зело ортогональные дистрибутивам, и это тоже хорошо.
А плохо то, что весь Линукс вырубается под корень уничтожением весьма незначительного количества серверов. Или уничтожением дрступа к таковым...
Корпорации в японской поп-культуре - тема не столько не раскрыта, сколько не затронута. А там идёт потоками - и явное изображение наличиствующей корпоративной среды, и отрицательные последствия пребывания в ней, и не совсем отрицательные, а в другом мире если - даже положительные, и влияние на другие виды деятельности, зачастую - строительство процветающих государств (не сарказм), и отдельно по отраслям - в музыке так, в анимации, уж кому знать лучше как ни аниматорам, тоже так...
И вообще, с какой стороны поп-культура ни зайдёт, что 半沢直樹, что 株式会社マジルミエ, что 世話やきキツネの仙狐さん, что SHIROBAKO - корпорации выглядят одинаково и примерно так, как в статье и написано - значит всё правда.
Но не вся, конечно. По доносящимся из Японии теням, типа откуда дизайн мехов в 輪廻のラグランジェ или почему дверь такси открывается сама, или что было главным возражением против Walkman - легко заполозрить, что у темы большааая подводная часть.
Если интересны компиляторы сами по себе, то невозможна ситуация, когда
Значит, не сами компиляторы. Тогда разработка компилятора - не лучший выбор, а упорствование в нём - форменное безумие. Если нечего делать при наличии минимум десятка превосходных компиляторов, то от добавления ещё одного чего делать не появится.
Вы не в том положении, чтобы претендовать на право выделять объективное и отличать конструктивное.
Ваш мозг ещё не закончил развитие, через 5 лет Вы можете оказаться совсем другим человеком. Если Вас всё ещё будет интересовать программирование - значит просто повезло. Иначе, вспоминаем якобы турецкую поговорку
Найти область которая увлечёт и затянет - это естественное стремление, в случае успеха жизнь станет лучше а думать впредь можно будет меньше. В случае неудачи, главное - не упорствовать.
Есть мнение, что когда человек делает то, что ему нужно, то ему помогает вся Вселенная (или Бог или боги или...), а когда то, что не нужно - тогда, соответственно, всё то же самое мешает. Есть другое мнение - трудности даются человеку для того, чтобы он их преодалевал. Каким мнением руководствоваться в каждом конкретном случае - становится понятно само собой годам к 60-ти.
Отложите ваш компилятор на месяц, если нужно - запретите себе о нём думать. Через месяц многое прояснится, я Вам это гарантирую.
Тем, что она в браузере.
Ну, кто там лидер, Rust или C, особенно когда в браузер в лом лишние байты гнать - это можно долго обсуждать. А про обеспеченность чего-либо в Rust на этапе компиляции я очень сомневаюсь - без unsafe Rust работоспособен исключительно в corner cases. Да, я знаю, сочетание Rust с организационными мерами почти начинает что-то гарантировать, можете не кидаться этот ваш Rust защищать.
По поводу моделей, мои сугубо неверные любительские тесты скорости выполнения показали - у LuaJit и V8 она практически одинакова. Просто Lua, естественно, это беда, а Python - большая беда.
У WebAssembly, помимо отмеченного в статье, ещё способности обфусцировать код и обходить W^X политику. Последнее, например, позволяет (абы как) писать на С на iPad. Вот я и думаю, что именно эти две способности и определят будущее WebAssembly, а как именно политологи скажут лучше.
Когда дети много пользуются гаджетами, это плохо. Значит, одно из трёх
не должно быть детей
не должно быть гаджетов
должен быть жёсткий контроль
В этом месте я внезапно понял где же имнно мы фундаментально расходимся. Для Вас обсуждения - не пустой звук, как для меня, как альтернатива - бред, я привык к этому слову, хотя сейчас можно сказать красивее - галлюцинации. Для Вас документация в виде текста - Истина, для меня - третья, в лучшем случае - вторая, в исключительных случаях типа Rust - первая, но тень Истины. А Истина - это то, что выводится в терминал. Вам нужны источники - мне они интересны, иногда полезны, но никогда не нужны.
Go run делает исполняемый файл из одного файла? Делает. На этом, вообще-то, дискуссия может и закончиться. А может и нет, если недоумевающий заметит - но ведь в этом файле явно написано package main, это же пакет. Так вот, этот main, сколько ни пиши перед ним package, это не пакет, это команда. Об этом даже написано, если правильно помню, в go help, подкоманду не помню. Был бы пакет - его бы импортировали в другие пакеты...
В документации, например, написано, что файлы для go run должны быть в одной папке. А по жизни вовсе и нет, ибо go run следует символическим ссылкам. На практике, помнится, go run со ссылками идеально подходит для обучения, осбенно пока часты "сначала попробую так, а потом эдак и ещё через задницу непременно", а документация тупо портит experience путаясь под ногами.
А вот это фундаментально. Да, люди отличаются целями и способностями, единого истинного (почему в кавычках, чего тут стесняться?) подхода нет. Но стоит отсечь по способностям на достаточно высоком уровне и хотя бы примерно определиться с целями, как истинный подход немедленно появляется, просто потому, что разумных подходов мало.
Абсолютно аналогично, тут Вы правы, и с языком с которого правильнее начинать. В отличии от подходов к обучению, языков много, что позволяет заметить, что отсутствие самого правильного, в том числе в силу размытия критериев, не исключает наличия отношений "всегда лучше" и "заведомо хуже", пусть и не между любой парой языков.
На 100% личного в публичном поле не бывает и никакая "личностность" право творить что угодно не даёт. Ещё в далёком прошлом врачи это сформулировали как принцип "не навреди".
Сам изучал да писал или несвежий текст скопипастил?
├── main.go <-- Go файл корневого пакета├── fmt/ <-- Пакет fmt│ └── printer.go <-- Go файл пакета fmtСтандартную библиотеку переписывать кто подучил? Какой такой гипотетический бред? Сами хотите запутаться - отлично, но держите такое не на виду.
ЧТО ЗНАЧИТ ВЕРОЯТНО?! Какой такой вариант импорта? Импорт в Go всегда один и тот же, а вот режимов поиска два - режим модуля и режим GOPATH. И оба, как это ни сложно себе представить после долгтх лет копипасты на Python и JavaScript, используются оба.
Идея прекрасная, а процесс дурацкий.
Наверно дело как раз в этом. То, что Вы приняли за трек обучения, это никакой не трек, никакого обучения от него не будет, это tour, то есть экскурсионная развлекательная поездка. Её задача - дать тому, кому Go не зайдёт, возможность почувствовать это как можно раньше. А тому, кому зайдёт, возможность в этом убедиться тоже как можно раньше, что-то в процессе написав, глупо или нет - пока не важно.
Переписывать такое своими словами - цензурных слов у меня нет. Но напомню, я писал - идея прекрасная. Потому, что на сайте Go недавно произошла катастрфа, последовательная документация уровня одновременно доступного и достаточного для изучения - исчезла, вместо неё трудно читаемая reference и другие, в смысле кроме tour, весёлые истории.
Я могу понять это двумя способами. Первый, от разглядывания страницы https://go.dev/learn/ - это чтобы лучше продовались курсы и книжки, нет причин выкладывать бесплатно то, что есть надежда продать. Второй, от желания оправдать дьявола - это потому, что набор рассказов по поводу достаточен для освоения чтения reference, которому всякому не мечтающему о статусе вечного джуна, особенно внезапно не вечного в силу ИИ, всё равно придётся придаться.
Разбираться с Go нужно с ввода
После чего можно или продолжить изучение, или написать о том, о чём в статье и написано, только совсем иначе. Без такого вот
ибо так сказать можно только с целью опозориться, ибо неделимая единица компиляции в Go, кто бы мог подумать, есть файл.
А лучше - начинать не с того, какая там "структура проекта", а как выполнить код на Go. Когда он в одном файле. Или в трёх. А случай когда в тысяче, вместе со структурой проекта, отложить на потом. Ну, разве что упомянуть почему зависимости структуре проекта ортогональны.
Постоянно случаются вещи, которых я не понимаю. Вот опять.
Какая радость от того, что принципиально медленный язык начнёт хоть что-то делать раньше? Всех всегда интересует когда то да сё будет готово...
Такая загрузка модулей может помочь тогда, когда существенная часть загружаемого заведомо так и не понадобится. Какая именно часть - зависит от данных, каждый раз она разная. То есть, так лучше чем никак.
А вот загрузка модулей параллельно в другом thread помогала бы и больше, и всегда.
Плачьте громче, на это смотреть весело. Ну, может не всем весело, но кто видел настоящих бизнесменов - тем точно. HR и найм - производные от бизнес климата, а бизнес климат... ну, сами знаете. Поэтому и "HR‑проблемы удивительно универсальны".
Рискну обобщить - как в этой стране хотели молока без коровы, так и хотят. Как ставили телегу впереди лошади, так и ставят. Удачи!
Сама идея искать идеального кандидата - это для ну очень рядовых предпринимателей. Мастер предприниматель видит человека, хватает его раньше других ибо не один он такой, и смотрит как теперь изменить бизнес процессы так, чтобы изменившаяся команда была максимально эффективна. Сейчас, через год, через 10 лет...
Сама идея подбирать людей под бизнес - тоже для середнячков в лучшем случае. Как и идея придумать и осуществить бизнес стратегию по схеме придумал - подобрал - они сделали. У мастера процесс не линейный: придумал, подобрал, дал поработать, оценил возможности которые иногда ошибочно именуют компетенциями, и назад на square one.
Иными словами, не от задачи к поиску ресурсов, а от ресурсов к формулировке задачи. Работает во всех случаях кроме того, когда ресурс - административный.
Одна мысль в подарок. Учитесь бизнесу? А с какой статми кто-то расскажет вам что именно даёт ему реальное конкурентное преимущество? Учитесь на опыте тех, кто, да хоть сколь угодно раз и за рубежом, идёт (той же дорогой) в никуда? Удачи! Впрочем, я повторяюсь...
"В добыче отсутствие сменного мастера может стоить компании миллионы в сутки" - Да неужели? Разве не классика - если при исчезновении начальника проблемы появляются раньше, чем через месяц, то работа была организована неверно...
"Хорошая новость в том, что приборы можно построить" - Это точно хорошая новость? Предприниматель спихивает признание своей некомпетености на HR, без приборов HR воет. С приборами - спихивает дальше, на приборы...
Я потому и стал читать, что автор из Ленты. А Лента - как раз на правильном пути меня кормить. Вкусвилл немного переусложняет в погоне за псевдоизысками, на мой вкус. Про остальные, Пятерочку, Магнит, Перекресток, Семафор - только названия слышал.
Лента сначала брать деньги а потом собирать не может, для этого нужен либо высокотехнологичный автоматизированный склад, типа находить конкретные огурцы чтобы в сумме был точный вес, такого у них нету, либо торговать только стандартными упаковками, а это не их стиль. И классический выбор между показом близкого к исчерпанию товара как отсутствующего и необходимостью иногда обсуждать с клиентом замену Лента делает в пользу последнего.