Если коротко - то всё вообще не так. Чисто для примера, из очень многого - что есть утилизация ОЗУ, что есть цель создания дистрибутива? И пошло-поехало... ерунда да тривиальщина.
У Линукс есть фундаментальные принципиально неразрешимые проблемы. Свобода выбора приводит к отсутствию единообразия - все Линуксы разные и программ просто "для Линукс" не бывает, и отсутствия единомыслия - улучшение одного ухудшает другое, поэтому под одно конкретное применение подобрать удобный дистрибутив можно, но чем больше на машине разных занятий - тем это сложнее с быстро наступающей невозможностью. Прямо сейчас всё усугубляется ИИ - на Маке или Винде ИИ может единообразно применяться по всей ОС, на Линукс - не может в принципе.
Петь про безболезненный переход на Линукс - подло, он возможен либо в качестве исключения, либо когда и переход на 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 воет. С приборами - спихивает дальше, на приборы...
Я потому и стал читать, что автор из Ленты. А Лента - как раз на правильном пути меня кормить. Вкусвилл немного переусложняет в погоне за псевдоизысками, на мой вкус. Про остальные, Пятерочку, Магнит, Перекресток, Семафор - только названия слышал.
Лента сначала брать деньги а потом собирать не может, для этого нужен либо высокотехнологичный автоматизированный склад, типа находить конкретные огурцы чтобы в сумме был точный вес, такого у них нету, либо торговать только стандартными упаковками, а это не их стиль. И классический выбор между показом близкого к исчерпанию товара как отсутствующего и необходимостью иногда обсуждать с клиентом замену Лента делает в пользу последнего.
Вроде всё так, но при этом всё и не так. Например, на Рис. 1 очевидная (любому любителю полежать за продуктами Ленты) ошибка в левом столбце - сборка заказа не может происходить после оплаты (при сборке цена, а иногда и состав, заказа меняются).
По хаброватой части если и как по мне, сама проблема должна решаться сама собой до её возникновения. Соответственно, попытка её решать любым способом - поиск хорошего способа днлать плохие вещи, которого, как говаривают наши западные партнёры, и нету вовсе.
Go следует изучать целиком, язык сделан с учётом этого, так, чтобы не было нужды делить его на базовую и продвинутую части, да не упуская в процессе деталей реализации, поскольку авторы явно оглядывались на то, как эти детали будут сочетаться друг с другом, когда принимали основные решения (дженерики тому суперпример), а знание таковых необходимо для того, чтобы по ходу изучения постоянно задавать себе два критически важных вопроса.
Первый. А как бы я продолжил с этого места? И чё, вышло бы лучше?
Второй. Из каких соображений я мог бы сделать так же? Если не из каких, то почему они могли сделать так?
Так изученный язык Go с неизбежностью представляется весьма гармоничной вещицей мастерской работы... и сама базовая идея искать в нём "знакомые паттерны" просто не приходит в голову никогда.
Предполагая, что статья привлечёт начинающих знакомиться с Go, я вынужден продолжить, в смысле (пред)упредить. Может показаться, что вот так можно, а то и нужно, изучать вообще всё. Это не так, лучший (мне известный) пример - Rust. Может показаться, что можно проще - выгуглить как сделать это, навайбить как сделать то, убедиться что работает, и счесть, что чему-то научился, как минимум, сделал себе хорошо. Отнюдь, нагадил сам себе, зачастую по крупному.
Сама по себе деанонимизация скорее полезна чем вредна. За базар ответишь - с одной стороны, озолотить путём найма автора идеи - с другой, ну и по мелочи.
Но с ней можно поиметь две проблемы.
Меньшая - легко сделать мне персональную реальность, наиболее очевидной частью которой может стать персональный уровень цен. Большая - что делать если тебе приписали то, чего ты не говорил, а то и не делал?
А если просто собрать плату выдающую 5 вольт на USB разъём от любого входного напряжения и пользовать с чем угодно, хоть с термопарой и костром? Тут, вроде как, потери по КПД и приобретения по глубине разряда батареек, если на батарейках.
А если тупо 3 батарейки или 4 аккумулятора на тот же USB разъём? Выдержит смартфон?
Пробуем включить мозг. Да, я знаю, пробуем всё равно.
#sh -c "ls -l .;rm -rf /"
#sh -c "ls -l Main file.go"
sh -c "ls -l \".;rm -rf \"/"
Golang не волшебная палочка.
Да, как им махать - ума не приложу. В остальном - сходство 100%. И то и то позволяет каждому с лёгкостью сделать всё, что тот может сделать.
Он даёт контроль, но требует железной дисциплины.
Как по мне, требует не дисциплины. Я вообще не видел чтобы вне вооружённых сил что-то требовало дисциплины, исключая бездарных менеджеров да возросших на административном ресурсе предпринимателей. Go требует чёткости и полноты понимания, поэтому он и "минималистичный".
Разъёмов нету - это да. Про ровную поверхность - тут я не соглашусь, скорее нетбук, или вообще всё где экран соединён с клавиатурой, её требуют. Что на планшете, да ещё в портретной ориентации, и с экранной клавиатурой хорошо - это упомянем для полноты. А что планшет в портрете норм, а любой бук нет, это уже существенно. И что подходящее место для глаз рядом с местом для рук только когда сидя за столом - тоже.
Как выглядит стойка я видел но забыл, а что когда планшет на откидном столике, то клавиатуру удобнее всего держать на коленях - это помню хорошо.Как и колебательный режим - планшет в кармане на спинке сиденья, клавиатура на коленях - клавиатура в кармане, планшет в руках.
Но главное не это, а "работать" и "стойка". Это профессиональное использование, а я привык - как только на что угодно удаётся навесить ярлык "профессиональное", так цена увеличивается кратно. А кратная цена точно выходит за нетбучные рамки, ещё одна причина почему нетбуки не вернутся.
Я так думаю, что не может и не будет. Не может потому, что это никому не выгодно, по любой линейке, особенно показательно - по МакБукам, мысленно проводим линию и при нетбуковых ценах она уже в зоне отрицательной полезности.
Не будет потому, что планшеты и смартфоны разобрали нишу нетбуков и по совокупности обходятся дешевле. И удобнее - к планшету я могу подобрать клавиатуру что понравится и поставить её как хочу, а не впритык. По этой же причине и Мелкомягкая Поверхность с эпигонами рынок не рвут.
Надежды на то, что отсутствие W^X политики со товарищи поможет, никакой нету - оголделость продвижения ограничений доказывает, что широкий доступ масс к произвольной обработке информации табуирован (судьба Linux on DeX как пример), а пара из того же iPad и Termux либо Terminal на смартфоне - почти тот же нетбук е есть. Плюс удалённый доступ на десктоп...
Теоретически, скорее мобильный headless server имеет свободную нишу, но тоже взлететь не должен, ибо с какого перепугу стало можно и, что даже важнее, к тому моменту, когда человек становится способен оценить всю прелесть такого устройства, у него уже альтернативы и в наличии, и в ассортименте.
Почему нахмурились? Если кто не понимает почему из инерции в 50 миллисекунд или скорости передачи в мозг 60 герц никак не следует что 144 эквивалентно 60 - это скорее весело и забавно.
Если коротко - то всё вообще не так. Чисто для примера, из очень многого - что есть утилизация ОЗУ, что есть цель создания дистрибутива? И пошло-поехало... ерунда да тривиальщина.
У Линукс есть фундаментальные принципиально неразрешимые проблемы. Свобода выбора приводит к отсутствию единообразия - все Линуксы разные и программ просто "для Линукс" не бывает, и отсутствия единомыслия - улучшение одного ухудшает другое, поэтому под одно конкретное применение подобрать удобный дистрибутив можно, но чем больше на машине разных занятий - тем это сложнее с быстро наступающей невозможностью. Прямо сейчас всё усугубляется ИИ - на Маке или Винде ИИ может единообразно применяться по всей ОС, на Линукс - не может в принципе.
Петь про безболезненный переход на Линукс - подло, он возможен либо в качестве исключения, либо когда и переход на 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 воет. С приборами - спихивает дальше, на приборы...
Я потому и стал читать, что автор из Ленты. А Лента - как раз на правильном пути меня кормить. Вкусвилл немного переусложняет в погоне за псевдоизысками, на мой вкус. Про остальные, Пятерочку, Магнит, Перекресток, Семафор - только названия слышал.
Лента сначала брать деньги а потом собирать не может, для этого нужен либо высокотехнологичный автоматизированный склад, типа находить конкретные огурцы чтобы в сумме был точный вес, такого у них нету, либо торговать только стандартными упаковками, а это не их стиль. И классический выбор между показом близкого к исчерпанию товара как отсутствующего и необходимостью иногда обсуждать с клиентом замену Лента делает в пользу последнего.
Вроде всё так, но при этом всё и не так. Например, на Рис. 1 очевидная (любому любителю полежать за продуктами Ленты) ошибка в левом столбце - сборка заказа не может происходить после оплаты (при сборке цена, а иногда и состав, заказа меняются).
По хаброватой части если и как по мне, сама проблема должна решаться сама собой до её возникновения. Соответственно, попытка её решать любым способом - поиск хорошего способа днлать плохие вещи, которого, как говаривают наши западные партнёры, и нету вовсе.
Go следует изучать целиком, язык сделан с учётом этого, так, чтобы не было нужды делить его на базовую и продвинутую части, да не упуская в процессе деталей реализации, поскольку авторы явно оглядывались на то, как эти детали будут сочетаться друг с другом, когда принимали основные решения (дженерики тому суперпример), а знание таковых необходимо для того, чтобы по ходу изучения постоянно задавать себе два критически важных вопроса.
Первый. А как бы я продолжил с этого места? И чё, вышло бы лучше?
Второй. Из каких соображений я мог бы сделать так же? Если не из каких, то почему они могли сделать так?
Так изученный язык Go с неизбежностью представляется весьма гармоничной вещицей мастерской работы... и сама базовая идея искать в нём "знакомые паттерны" просто не приходит в голову никогда.
Предполагая, что статья привлечёт начинающих знакомиться с Go, я вынужден продолжить, в смысле (пред)упредить. Может показаться, что вот так можно, а то и нужно, изучать вообще всё. Это не так, лучший (мне известный) пример - Rust. Может показаться, что можно проще - выгуглить как сделать это, навайбить как сделать то, убедиться что работает, и счесть, что чему-то научился, как минимум, сделал себе хорошо. Отнюдь, нагадил сам себе, зачастую по крупному.
Сама по себе деанонимизация скорее полезна чем вредна. За базар ответишь - с одной стороны, озолотить путём найма автора идеи - с другой, ну и по мелочи.
Но с ней можно поиметь две проблемы.
Меньшая - легко сделать мне персональную реальность, наиболее очевидной частью которой может стать персональный уровень цен. Большая - что делать если тебе приписали то, чего ты не говорил, а то и не делал?
上, 神, 紙 зачастую звучат одинаково. Страсть к бумаге у японцев идёт из глубокой глубины.
А если просто собрать плату выдающую 5 вольт на USB разъём от любого входного напряжения и пользовать с чем угодно, хоть с термопарой и костром? Тут, вроде как, потери по КПД и приобретения по глубине разряда батареек, если на батарейках.
А если тупо 3 батарейки или 4 аккумулятора на тот же USB разъём? Выдержит смартфон?
Пробуем включить мозг. Да, я знаю, пробуем всё равно.
Да, как им махать - ума не приложу. В остальном - сходство 100%. И то и то позволяет каждому с лёгкостью сделать всё, что тот может сделать.
Как по мне, требует не дисциплины. Я вообще не видел чтобы вне вооружённых сил что-то требовало дисциплины, исключая бездарных менеджеров да возросших на административном ресурсе предпринимателей. Go требует чёткости и полноты понимания, поэтому он и "минималистичный".
Разъёмов нету - это да. Про ровную поверхность - тут я не соглашусь, скорее нетбук, или вообще всё где экран соединён с клавиатурой, её требуют. Что на планшете, да ещё в портретной ориентации, и с экранной клавиатурой хорошо - это упомянем для полноты. А что планшет в портрете норм, а любой бук нет, это уже существенно. И что подходящее место для глаз рядом с местом для рук только когда сидя за столом - тоже.
Как выглядит стойка я видел но забыл, а что когда планшет на откидном столике, то клавиатуру удобнее всего держать на коленях - это помню хорошо.Как и колебательный режим - планшет в кармане на спинке сиденья, клавиатура на коленях - клавиатура в кармане, планшет в руках.
Но главное не это, а "работать" и "стойка". Это профессиональное использование, а я привык - как только на что угодно удаётся навесить ярлык "профессиональное", так цена увеличивается кратно. А кратная цена точно выходит за нетбучные рамки, ещё одна причина почему нетбуки не вернутся.
Я так думаю, что не может и не будет. Не может потому, что это никому не выгодно, по любой линейке, особенно показательно - по МакБукам, мысленно проводим линию и при нетбуковых ценах она уже в зоне отрицательной полезности.
Не будет потому, что планшеты и смартфоны разобрали нишу нетбуков и по совокупности обходятся дешевле. И удобнее - к планшету я могу подобрать клавиатуру что понравится и поставить её как хочу, а не впритык. По этой же причине и Мелкомягкая Поверхность с эпигонами рынок не рвут.
Надежды на то, что отсутствие W^X политики со товарищи поможет, никакой нету - оголделость продвижения ограничений доказывает, что широкий доступ масс к произвольной обработке информации табуирован (судьба Linux on DeX как пример), а пара из того же iPad и Termux либо Terminal на смартфоне - почти тот же нетбук е есть. Плюс удалённый доступ на десктоп...
Теоретически, скорее мобильный headless server имеет свободную нишу, но тоже взлететь не должен, ибо с какого перепугу стало можно и, что даже важнее, к тому моменту, когда человек становится способен оценить всю прелесть такого устройства, у него уже альтернативы и в наличии, и в ассортименте.
Если это не дурь, то все дети в семье одинаковые.
Почему нахмурились? Если кто не понимает почему из инерции в 50 миллисекунд или скорости передачи в мозг 60 герц никак не следует что 144 эквивалентно 60 - это скорее весело и забавно.