После шести месяцев разработки представлен релиз языка программирования Go 1.24, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62710
не хватает нормального препроцессора условной конпеляции. то что есть на тэгах и уровне модулей очень убогое
Это должно решаться кодогенерацией. Потому что явное лучше неявного.
скажи это авторам Spring Boot, правда это Java, но суть понятна
Авторы Spring Boot, явное лучше неявного!
Спасибо, учтём!
То-то же!
sdf.sdlfjsd.sdfsdfsdf.asdfsadfsdf.asdfasdfsdgsfasdf
<...>
sdf.sdlfjsd.sdfsdfsdf.asdfsadfsdf.asdfasdfsdgsfasdf@somecrypticshit
class main void public() {
get set get set ... get set
print('Hello World!');
}
;-) <- сейлсмен JetBrains
> явное лучше неявногонет конечно. это популярный тезис, тем не менее он попросту не работает. если сделать "явным" все, то код получится громоздким. так говорят обычно потому, что сравнить не с чем и кажется что сделал явным и разницы все равно нет. но ничего хорошего так не сделаешь, только лапшу которую потом все труднее и труднее поддерживать.
Если использовать кодогенкрацию вместо неявного, то эта лапша останется за кадром и ее не нужно поддерживать
хорошо бы если так, но к сожалению нет. кодогенерация остается за кадром, но это - шаг всторону - растрел. то есть вроде все работает, но как только понадобится код как-то масштабировать, так сразу надо туда лезть и все переделывать. а это сложно потому что там куча лапши и по ней надо долго залить, чтобы вообще понять что там происходит, плюс она хрупкая. при этом масштабирование - самое важное свойство кода для бизнеса.
Хз, откуда ты такие проблемы взял. В дотнете используем кодогенераторы, они генерируют простой очевидный удобный код
Трепло! 🙂
А по факту все ужасы которые ты описал к Си препропу относятся 🙂 … но даже с ними живут как то.PS: Я даже против generics был, а вот уж _текстового_ препрокссора в Go - точно не нада!
Разве условную компиляцию нельзя сделать без препроцессора? Пример - D.
а зачем?
А зачем потом бороться с невнятными сообщениями об ошибках?
А зачем препроцессором? Левой утилитой про семантику кода ничего не знающей. Когда код меняется инструментами языка, кроме ожидаемого семантически корректного поведения и нормальных сообщений об ошибках, это позволяет, например, ограничивать область действия условной компиляции естественным блоком языка, а это позволяет заменить условную компиляцию на runtime проверку одной строкой, а не переделкой #if/#endif на if {} со сдвигом всех строк.
Если у деда, пока спит, спереть M4 то вполне могут в гошке и define, прямо как в сишке )
Да можно и в гамаке, не снимая лыж, стоя на голове …
Но зойчеееем?!?!?!
Я наверное не знаю толка вЪ(с) 😉
делал замеры, существенно медленнее крестов, и всего в 2 раза быстрее интерпретируемого php. совершенно непонятна ниша этого чуда от Гугла
Быстрее в чем? Надо ещё потребление и скорость разработки смотреть и ещё кучу метрик.
> и скорость разработкиМоя любимая песня. Как в советском анекдоте про плохую и хорошую новости.
Ну неужто Пых по скорости разработки проиграет?
PHP уже переусложнен в несколько раз от необходимого. Этакие потоги обогнать C++ по нечитаемости и неочевидности. И да, развесистое ООП только помогает все запутать.Питон кстати туда же катится со своим морем фич.
>PHP уже переусложнен в несколько раз от необходимогоНв php внезапно стали писать не только домашние странички, но и высоконагруженный код для продакшена с кучей фич. Вот и потребовалось столько всего добавить
Из контекста ясно, что имеется в виду скорость/производительность программ. А смотреть "кучу метрик" и т.д. нужно, когда выполняется соответствующее сравнение. В интернете есть немало тестов сравнения производительности на С/С++ и Go. Если их грубо обобщить, то производительность программы на Go в среднем в 2-4 раза медленнее по сравнению с С/С++ при сопоставимом потреблении памяти
Программа на пыхе ест один гиг на го сто мегов. Дальше продолжать или сам догадаешься?
Во-первых речь шла о сравнении НЕ с пыхой, во-вторых можно считать память для с/с++ и go одинаковой. Еще раз перечитай пост, на который ты отвечал
С ПХП сравнивать не чесно потому что это очень оптимизированый язык. Надо сравнивать с питоном.
А лучше с bash
Когда говорите, что что-то сравнивали, нужно описывать, на каких задачах и какие способы решения.В PHP вся стандартная библиотека написана на С. Если ваше решение выполняло мало PHP кода и в основном дергало библиотечные функции, оно будет довольно быстрым.
В Go медленная рефлексия. Если ваше решение использовало стандартный encoding/json, да ещё, не дай бог, с any/interface, оно будет медленным.
Но на Go расширения пишутся на Go. Возьмите быстрые пакеты с генерацией кода, и решение той же задача станет в несколько раз быстрее.
И по мере усложнения задачи и её решения скорость не будет сильно падать, т.к. вы будете писать на том же Go. А вот с PHP скорость будет падать быстро.
Конечно, современные версии PHP сильно ускорились, и JIT хорошо прогрессирует. Я тоже думаю, что современный PHP недооценен. Но всё же Go обгонит его «в любое время дня и ночи».
Проблема PHP в том, что архитектурно это до сих пор CGI. Отработал - умер. И на каждый обработчик создается рантайм. Все работает синхронно. Много предопределенного поведения и архаики. ООП язык тоже архаика. Опыт с голангом показывает, что в корпоративной разработке и без ООП хорошо, никто не умер.
>Проблема PHP в том, что архитектурно это до сих пор CGI. Отработал - умер.Зато нет утечек памяти и ресурсов.
пффф... смешно
Простите, но моё личное мнение: ООП в Golang есть. Ибо в "привычном ООП" главное - это полиморфизм и инкапсуляция. А и то, и другое в Go нативно: методы + интерфейсы.(Почему "привычное ООП" в кавычках? Потому что автор термина считал, что объекты должны "обмениваться сообщениями", а не "вызывать методы". И в этом смысле, истинным воплощением ООП являются процессы в Erlang/Elixir.)
>Простите, но моё личное мнение: ООП в Golang есть.Давайте не придумывать каждый свою терминологию
>А и то, и другое в Go нативно: методы + интерфейсыИ как интерфейсы реализуют инкапсуляцию? Интерфейсы и в C# есть, и почти для той же цели, но инкапсуляция там реализуется инчае
>Ибо в "привычном ООП" главное - это полиморфизм и инкапсуляцияЭм, тогда и в ФП есть ООП, что звучит как абсурд
Так никто и не придумывает, их два: изначальное (от автора Smalltalk) и "плюсовое" (хотя оно родом из Simula).В ФП с полноценными замыканиями есть ООП, да. Я в проекте, где в Typescript по религиозным причинам не использовали классы, писал полноценный SOLID код - вообще без проблем, просто немного многословнее.
>Так никто и не придумывает, их два: изначальное (от автора Smalltalk)А об этом кроме автора Smalltalk кто-то знает?
Ну байка популярная, да и термин ООП - придумал он, имеет право настаивать на своей трактовке ...
Только толку то? Если бы труп страуса к этому прислушался бы ... но имеем С++ за грехи наши :)
>Простите, но моё личное мнение: ООП в Golang есть.Да фиг ли там мелочиться - такой ООП и в Си есть!
Кто не верит - смотрите Gnome-ячий GObject ... "закат солнца вручную" (С)Только вот нравится такое ООП "не только лишь всем"(С) :)
Иногда возникает мысль - вот это _надо_ писать на С++ или даже Java, а не на ... 8-)
Вообще-то gobject -- довольно годная объектная система, просто Си - не лучший язык для её использования. Есть vala, который для неё и создавался. К тому же, она легко встраивается в объектные системы других языков.
Ну и как - много наValaли софта то? ;-)
А чего так? Годная же?!Неееее робяты! Где то нас кидают!(С) :)
Тем не менее, его можно встретить на некоторых linux десктопах. Тот же pamac в manjaro, или софт из ElementaryOS.
0.1% от 1% процента даёт нам ... считайте сами :)
А по поводу "PHP - это CGI", так умельцы давно освоили Event Loop и "в ус не дуют". И действительно у многих получается очень шустро делать какие-то не слишком сложные асинхронные вещи.Если посмотреть на результаты TechEmpower, то PHP действительно очень близко к Go.
Вот только TechEmpower - это всё-таки синтетика с простыми кейсами, в которых кода не очень много. Тормоза начнутся, когда бизнес-логика разрастётся.
Да ничего он не сравнивал, просто тролль
Многим ЯваСцэнаристам нравится. Типа быстрый, типа простой, комплириуемый, модный стильный, не замшелый C++ или Pascal поэтому можно делать сайты и пацаны не засмеют.
> существенно медленнее крестов, и всего в 2 раза быстрее интерпретируемого phpphp давно jit
Зато выучить его проще в 100 раз чем с++
Go делался для IO-bound задач (типа сервачков), где важна, в первую очередь, способность рантайма языка дёшево обслуживать большой RPS. Go это решает через green threads (горутины) и не блокирующее сетевое взаимодействие (еpoll и т.п.)
Странно писать на языках, имеющих сборку мусора, алгоритм-числодробилку (CPU-bound задачу), а потом рассуждать от том, что такая числодробилка на крестах будет быстрее.
В Go нормальная строгая статическая типизация. Нормальное явное объявление переменных, а не просто по факту использования имени. Это уже огромные преимущества.
go не типобезопасен, и толку от строгой статической типизации мало. То же понижающие приведение приводит к ошибкам во время выполнения. Кроме того, для php активно развиваются статические анализаторы, что частично компенсируюет динамическую природу
Вот go как-раз и рекомендуют применять как безопасный, также как и rust.
Кто рекомендует? В go нет арифметики указателей, но это не делает язык типобезопасным. Прочитайте определение терминов, прежде чем придумывать
Единственная метрика, которая имеет смысл при сравнении языков — потребление энергии результирующим артефактом. Потому что это именно та метрика, которая напрямую конвертируется в деньги. Всё остальное косвенно и зависит от требований момента, предметной области и тому подобных вещей. И такое сравнение Гугл конечно же провёл, ищущий да обрящет. Результаты, там, кстати ожидаемые и без сюрпризов.
Хорошая замена питону, а так же шлаку типа перла и руби. Только, кажись, не особо то оно взлетело, судя по количеству репозиториев на гит хабе.
Го оказался слишком идиотматический.
Для Вас? Или Вы за всех решили сразу?
Да, не благодарите.
> судя по количеству репозиториевСудить не умеете! Нужно судить по количеству звёздочек.
Судить нужно по вопросам нубов на стаковерфлоу.
На перле 20 лет назад работал хайлоад и сейчас работает. Perlbal до nginx и имел сравнимую производительность. Посмотрите MogileFS и другие мощные проекты.
На питоне и руби веб если и работал, то с нагрузками типа 1 запрос в секунду. Даже не надо сравнивать. Питон и руби - это для программ, запускаемых у человека на компе, где не имеет значения, скрипт работает 1 минуту или 10, лишь бы отработал. Это совершенно разные миры. Не говоря о том, что питон и руби буквально срисованы с перла, но создатели видели разные фатальные недостатки.Голанг сейчас основной язык веб бэкэнда в коммерческой разработке. Оценить степень его внедрения можно по развитию ключевых компонентов, используемых в разработке. В том числе самого языка. У полумертвых языков развитие идет в сторону отвлеченных вещей, а с голангом все наоборот.
> Голанг сейчас основной язык веб бэкэнда в коммерческой разработкеJava.
Legacy. Будет дорабатывать в банках вместе коболом. А новые большие проекты на этом уже не пишут.
Это го так нехило вставляет что появляются такие смешные галлюцинации?
Не надо завидывать что Го-шники вставляют! ;)Все модно-молодёжные новые проекты лежат на 'microservice architecture', а там Java как то толком не смогла... почему - не знаю. Хороших причин к этому нет. Но - вотЪ :-\
А вот к примеру пистоны, Го, JS+Node - только так ...PS: Может они пока JVM Code Cache разогревают, а потом всех нагн^W обгонят ? ;)
> Все модно-молодёжные новые проекты лежат на 'microservice architecture', а там Java как то толком не смоглаНе смогла у кого? У опеннетных кекспертов? Охотно верю. Количество новых проектов под любые архитектуры на Яве огромно. В первую очередь потому, что в Яве-экосистеме есть библиотеки высокого качества для любых задач, от хайлоада до обскурных финансовых протоколов. Угадай, на чём работает антиспам у крупных операторов почты. Подскажу, что это не C, не C++, и даже не сабж. Обработка больших объёмов данных (от сотен терабайт на датасет и выше) до сих пор без Явы и Хадупа немыслима.
Ваш пост про скорость Явы и немыслимость обработки без нее больших объемов данных сделал мой день гораздо веселее :D :D :D
Java мертва, да здравствует Kotlin
в остальном на бэке сисярп, бидон и голагне
пыхп практически вымрет как только закончится история с WP в результате очередного их жабогадюкинга
>Java мертваВозможно и так. Но вот Kotlin точно _не_ жив :)
Скорее уж "да здравствует" JS+Node... хотя глядя на _это_ уже думаю что жаба ещё ничего была - то :)))
>Java мертваСогласен. Разработка на всяких Спринг Бутах как сеанс групповой некрофилии (ведической).
> На питоне и руби веб если и работал, то с нагрузками типа 1 запрос в секундПитоний Django смотрит на тебя с недоумением.
> Не говоря о том, что питон и руби буквально срисованы с перла
Питон буквально срисован с Перла? Лол, да ты Питон даже в глаза не видел, но умничаешь о том, как он там где работает.
На, почтай и ее не позорься болше своей экспертизой:
> JS сейчас основной язык веб бэкэнда в коммерческой разработке.Чуток подправил. Благодарить не стоит.
Ты фронтенд от бэкэнда не отличаешь?
Он всё правильно пишет.NodeJS сейчас основной язык веб бэкэнда в коммерческой разработке.
был ведь питон
Если под "коммерческой разработкой" понимать стартап, написанный пабыринькому с целью спихнуть инвестору прототип, похожий на работающий, то да, жабаскрипт для этого как годится.
Да если бы так :( Оно уже везде.
Жс давно вышел за пределы фронта. Лет эдак 15 назад. Так что можно поздравить Вас с разморозкой)))
а почему не 150? Ох уж эти сказочники (с) падал прошлогодний снег
> а почему не 150?Потому что прошло только 15.
> Голанг сейчас основной язык веб бэкэнда в коммерческой разработке.c# смотрит на тебя с непониманием
ООП в 99% случаев ненужно. А то что классы пихают везде и всюду лишь говорит о слабоумии разработчиков. По крайней мере никто не смог мне ещё обосновать необходимость ООП, в большинстве проектов.
Я бы согласился если бы ты сказал "ООП как в С++ - в 99% случаев ненужно" :)
А так то - фундаментальная же вещь для усмирения complexity ...
Да не, c# по тому, что я вижу - про энтерпрайзы со сложной бизнес-логикой, эдакая better java - а go'шечка - простая-и-быстрая (в том числе и в разработке) web'ня. Чего больше - чего меньше вопрос дискуссионный (Впрочем, инсорс-разработки на go в сколько-нибудь заметных масштабах я не то, чтобы "не видел", а и "не слышал" даже - а вот коммерческие коробки с wob'нёй на c# вполне себе...)
> Perlbal до nginx и имел сравнимую производительностьДа каэш. Никогда даже близко не стоял, и это даже при том что асинхронные вещи, казалось бы, совсем не важно на чём писать, потому что код там вычислениями не занимается, а только редко дёргает AIO.
> Не говоря о том, что питон и руби буквально срисованы с перла
Ты ни питона, ни ruby видимо в жизни не видел, с скорее всего и перла.
Ник классный у тебя. За место питона лучше дотнет брать, в нём ООП в отличие от ГО есть
Писать на сисярпе под линуксы - сильно душно :(
К примеру наши программеры после полугодового тест проекта - спрыгнули...PS: Программеры - хорошие, хотя и вантузятнеГи ;-)
В случае с развесистой бизнес-логикой вариантов не так, чтобы разогнаться. У той же go'шечки не то, чтобы "хорошо" с ORM и крупными MVC-фреймворками - а делать каждый раз восход-солнца-вручную то такоэ...
c#, java ну и скрЫптота какая-нибудь там, где нагрузки нет.
Обычно не требуется писать только под Линукс, и тем более на С#. А нужно и версию запускаемую в том числе на Линукс. И бюджет на это выделяется небольшой.
И если с нативной сборкой проблемы, то с ними не возятся, а используют Wine, в котором все отлично работает.
Тоже относится к ПО состоящему не из одного выполняемого файла, а комплекса ПО и библиотек, что нативно портировать затратно, и достаточно сделать чтоб в Wine работало.
Wine в продакшене(С) OpenNETТеперь я видел всио!(С) :)
> Обычно не требуется писать только под Линукс, и тем более на С#. А нужно и версию запускаемую в том числе на Линукс.Удивительно, что ещё существуют староверы, которые считают, что дотнет на линуксе как-то не так запускается или вообще с вайном.
Уже лет 9 дотнет крутится в докере
Не надо чтоб крутился, надо чтоб работал!Но!, справедливости ради - это теперь и самому M$-у надо, так что думаю - доведут.
> думаю - доведут.Опять 25. Да всё довели уже 5 лет назад.
В принципе не плохой язык. Странно что для него интерфейс для драйверов ядра линукс нет.
Злонамеренные атаки на ядро будут продолжаться. Пока Линус есть, отобьются. Что будет после него, неизвестно.
Линусу параллельно каким языком пишут его ядро при состоянии в 50 лямов и з/п в полтора мегабакса в год.
Что бы каждый драйвер с собой еще таскал гошный рантайм?))
жаль нет сборщика мусора, уничтожающего устаревшее железо. Отличная была бы идея
export CLEAN_PROTECT="C2D"
"Неплохой", в вашем контексте.
это ЦА golang, для неё это нормально
Вы ещё для джавы сделайте. Го на сборщике мусора построен, он памяти в рантайме жрёт - яибу. Да и как язык довольно убогий. Никакой производительности Си у него разумеется нет - именно поэтому лучшее решение на го всё равно работает в два раза медленнее, чем на Си и Расте на techempower.
>Го на сборщике мусора построен, он памяти в рантайме жрёт - яибу.Меньше жавы жрёт то!
А насчет "ибу" - дык это мужики делают, а ты другая сторона процесса! :)>Да и как язык довольно убогий.
Убогие увидят в зеркале убогость(С)
_ВСЕ_ мажорные облака на нём сделаны. Это - надолго.>Никакой производительности Си у него разумеется нет - именно поэтому лучшее решение на го всё равно работает в два раза медленнее, чем на Си и Расте на techempower.
Нас - орда! ... А нас - рать!(С)
:)
В недрах облаков есть го, но также там c#/dotnet, java, python, c++, rust. Причём, C++ и Раст там как раз потому, что всё остальное неэффективно по ресурсам. А го, питон, жава и дотнет потому, что низкий порог вхождения и любой васян может чё-нить слабать за небольшие деньги.Рать вас там или не рать - никого не волнует. Речь только про то, что в статье опеннета утверждается про скорость Си, а это не соответствует действительности.
> Причём, C++ и Раст там как раз потому, что всё остальное неэффективно по ресурсам.Не неси чушь. В "недрах облаков" ресурсы упираются в асинхронное IO, а не в скорость пердолинга с байтиками. Именно поэтому там Go и прочее.
Полно команий, работающих с высокой нагрузкой, описывавших, чем им помешал гошных сборщик мусора
Да такие компании - есть.
Но всё же - посмотри хотя бы 3 major cloud platform - там всё на Go. Не на 100% конечно, просто так вышло что вот для этого вот всего он (Го) - офигенен. Ну и ...
>А насчет "ибу" - дык это мужики делают, а ты другая сторона процесса! :)А как это называется для другой стороны процесса?
>В принципе не плохой язык.Кому - как. Мне - норм :)
>Странно что для него интерфейс для драйверов ядра линукс нет.
Это одно из основных достоинств! И захотят - в ведро не втянут! ;-)
В плане нет? Может вы плохо искали?
Хотя как по мне функциональщина Haskell именно в дровах может показать себя лучше.
> В стандартную библиотеку включены реализации криптоалгоритмов, одобренных в стандарте безопасности FIPS 140-3.Это же применяется только в США, зачем это нужно для всех? Я не совсем понимаю, в каких случаях это используется.
В принципе пока что это самые лучшие алгоритмы
Нужно ФСТЭК ?
кузнечик.
Гугл - американская контора, все лучшие программисты работают в Штатах, все лучшие компании делающие софт - в Штатах, двигатель софтового прогресса - в Штатах, лучшие зарплаты - в Штатах, и так далее. Все остальные - пассивные получатели выгоды от того, что происходит в Штатах.
> Все остальные - пассивные получатели выгоды от того, что происходит в Штатах.Индия (известна своими IT-услугами и аутсорсингом) и Китай (DeepSeek, Alibaba, Tencent, Baidu) с тобой категорически не согласны.
>DeepSeek, Alibaba, Tencent, BaiduКто это такие? Где их в реальной жизни можно увидеть?
Их можно найти на фондовом рынке США, который просел только от DeepSeek на 1 триллион долларов. "А король то голый". Если считать выхлоп цена/качество, то Россия будет далеко впереди США.
>Их можно найти на фондовом рынке СШАСпасибо. Вот гугл можно найти на почти на любом случайном смартфоне. А эти компании - неизвестно где.
То что это обычный предустановленный мусор ни о чём не говорит. Гугол в принципе много мусора пропихивает в смартфоны, который даром не нужен
Только вот беда, им пользуются
> Вот гугл можно найти на почти на любом случайном смартфоне. А эти компании - неизвестно где.Alibaba - это место откуда твой смартфон приехал к посреднику, у которого ты его купил.
Tencent, Baidu - это то, чем пользуются люди, разработавшие и сделавшие твой смартфон.
DeepSeek - это тот, кто будет делать твой следующий смартфон.А Гугл - это так... мелкая конторка на поиграться конечному пользователю.
Шах и мат.
Рынок прочёл, потому что горе-инвесторы повелись на сказки китайцев про модель за $5 млн. Сколько раз уже повторялось: никогда не верьте китайцам на слово
Они её в свободный доступ вообщето выложили :)
Или ты думашь что ты умнее тех кто и в-правду работает на фондовым базаре? :)))На слово же (если кто забыл) - джентльменам нужно верить ещё меньше чем китайцам. :-\
> считать выхлоп цена/качество, то Россия будет далеко впереди США.Изобретения покажи. Что там вышло из РФ, чем весь мир пользуется? Винда, линукс, чатгпт, фотошоп, хром, гуглопоиск, гуглокарты - что? Про цену-качество можно знакомым рассказывать, что б помассировать эго, но это бестолково.
OpenCV, Nginx, Kotlin. Ну это так, навскидку
Это я ещё не всех перечислил. ByteDance (TikTok), Kingsoft, NetEase, 360 Security Technology...
>ByteDance (TikTok)Похоже, единтсвенная не нишевая компания.
Нет, это лишь свидетельствует о том, что вас интересует в основном только TikTok, и вы проводите в нём много времени.
Я в нём время вообще не провожу, недавно просто говорили о его запрете в США, вот и услышал про ByteDance. Вот есть такая компания, как Jane Street. Узнал я о ней, когда изучал Ocaml. Вот меня и интересует, о каких китайских компаниях можно узнать, просто используя их продукты. Или единственное, что у них есть, это записи на фондовом рынке.
> Вот меня и интересует, о каких китайских компаниях можно узнать, просто используя их продукты.Alibaba - Aliexpress (не, он не только в СНГ популярен, если шо).
Huawei - смартфоны, ноуты, роутеры.
Xiaomi - эти вообще всё вплоть до туалетной бумаги делают.
Какое это отношение имеет к софту? У них есть какие-то уникальные разработки? Вот у Яндекса, например, есть ClickHouse, у некоторых работодателей в вакансиях встречается, хотя они - не Яндекс.
>>Индия (известна своими IT-услугами и аутсорсингом) и Китай..В честь их программистов даже назвали стили г..кода - индусский код, и китайский код.
Программисты других стран не удостоились подобной чести.
Их г..код пользуется большим спросом, в отличие от ...😏
Их г..код видно за километр. А вот кто написал условный nginx - нет. По этому, до тех пор, пока мне не скажут, чей код написан русскими, а чей французами, а чей - не теми и не другими, я этого не угадаю.
Когда я работал в московском отделении американской конторы AlignTech, там любимое занятие всего отдела было - переписывать код, запушеный индусами. Когда в москву приехала большая начальница из Техаса и её спросили нафига нужны эти говнокодящие индусы, она сказала, что они нужны, что бы их уволить когда бизнес замедлится, потому что они - дешёвые контрактники, которых не жалко. При этом знающие люди сказали, что в Индии безусловно есть хорошие программисты, но они очень дорогие и их мало, поэтому нет смысла их там покупать.
Не только в США
> Это же применяется только в США, зачем это нужно для всех?Потому что го пишут в первую очередь для своих.
А вот все остальные его используют потому что им позволили (лицензия и тд).
Но эти остальные не слишком интересуют создателей.Вот если бы в великой и могучей создали ЯП, который использовался бы во всем мире, то там бы в стандартной либе был бы ГОСТ, Магма, Кузнечик и тд
Если бы)))> Я не совсем понимаю, в каких случаях это используется.
Оно и видно...
> Вот если бы в великой и могучей создали ЯП...А ты из США пишешь?
> Оно и видно...
Если ты такой великий эксперт, то где же ты сам это применяешь?
> А ты из США пишешь?Да. В сша много людей, которые знают русския язык. Он конечно забывается, поэтому многие фразы звучат корявенько для нейтивов, но тут некоторые нейтивы иногда так пишут, что даже мне больно смотреть. Хотя уже почти 30+ лет прошло.
> Если ты такой великий эксперт, то где же ты сам это применяешь?
Напр. для того же TLS. Лично для моего кода нет требования FIPS 140-3 compliance, но для тех, кто работает с госухой или подрядчиком, это вполне реальное требование.
Плохо, что go-программму уже невозможно скомпилировать без подключённого интернета.Будучи на даче, обнаружилось, что go build без интернета совсем не работает (выдаёт ошибки подключения к сети). То есть ни одну программу невозможно собрать оффлайн. И это несмотря на то, что все зависимости уже установлены и есть в кэше.
Как воспроизвести:
1) Вначале с включённым интернетом компилируем вот такой hello.go https://pastebin.com/96uYkp4P Он соберётся, при этом все зависимости скачаются автоматически.
2) Теперь отрубаем интернет, создаём новый каталог, в который помещаем только hello.go, и пробуем его собрать. Невозможно, так как лезет в сеть и не может приконнектиться:
exit status 128:
fatal: unable to access 'https://github.com/mattn/go-runewidth/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/nsf/termbox-go/': Could not resolve host: github.com
А go mod vendor выдаёт:github.com/mattn/go-runewidth: no required module provides package github.com/mattn/go-runewidth; to add it:
go get github.com/mattn/go-runewidth
github.com/nsf/termbox-go: no required module provides package github.com/nsf/termbox-go; to add it:
go get github.com/nsf/termbox-go
Что за дейбилизм? Смотрите первый пункт, зависимости-то уже скачаны и в кэше!
А без сети go get уже и не сделать!
Не знаю, как в других языках, но в ocaml сборка проекта и установка зависимостей делаются разными командами, и при сборке вы даже не заметите задержек, если у вас не будет интернета.
Прямая привязка к githаbу это фейл. Представьте мейкфайл, который требует скачать доп. васяносурсы по протоколу gopher с адреса, недоступного ещё с начала 90х. Мейкфейл.
Это просто именование пакета, а не привязка к Гитхабу. Более того если уже назвали пакет github.com\packagename то можно использовать директиву replace для указания пути к пакету.
>Это просто именование пакета, а не привязка к ГитхабуДопустим, я переведу проект с github на gitlab. Это что, теперь по каждому гошному файлу нужно будет ходить и домены менять?
Достаточно снова сделать replace с помощью go mod edit, в файле go.mod будет выглядеть как указано в документацию:Example:
replace golang.org/x/net v1.2.3 => example.com/fork/net v1.4.5
replace (
golang.org/x/net v1.2.3 => example.com/fork/net v1.4.5
golang.org/x/net => example.com/fork/net v1.4.5
golang.org/x/net v1.2.3 => ./fork/net
golang.org/x/net => ./fork/net
)
Хорошо. А как это с пакетным менеджером объеденить? Ведь всё в GOPATH должно лежать.
Replace с помощью go mod edit - это и есть операция "пакентного менеджера". Сейчас не привязано к GOPATH, кешированные пакеты лежат в GOMODCACHE, более того с replace можно указать что github.com/packagename лежит в /home/username/packagename.
>кешированные пакеты лежат в GOMODCACHEТуда можно свои пакеты добавлять?
>более того с replace можно указать что github.com/packagename лежит в /home/username/packagenameКак я понимаю, это попадёт в git и уйдёт ко всем
А почему нет? Можно добавлять что угодно, локальные модули на локальной ФС, если это не будет доступно публично. Если это будет публично, то и модули должны быть доступны публично. Это актуально для всех языков, где есть зависимости.
Тогда делай остальные модули публичными, в чем проблема? А не хочешь - собирый бинарник и распространяй.
Я хочу получить поведение, идентичное ocaml. Есть $OCAMLPATH где перечислены пути к файлам, которые ищет компилятор. Это позволяет скачать зависимости, положить их на диск, а потом при сборке проекта их указать. Исходный код проекта не меняется, как бы я эти файлы ни брал, хоть в виде архива, хоть через пакетный менеджер окамла.
>> Я хочу получить поведение, идентичное ocaml.Хотеть не вредно.
Беда GO в том, что к нему предъявляют претензии адепты из других языков. Кому-то ООП из джавы подавай, кому-то структуры из питона, кому-то сборку "поведение, идентичное ocaml".
GO имеет довольно стройную систему и как язык и как среда. Но лодыри хотят использовать прошлый опыт и не учить новое.
PS
Кстати у противостояния Rust vs C++ те же корни. Поэтому во многих конторах GO и Rust идут вместе, наверно ментальная среда общая. ))
>Беда GO в том, что к нему предъявляют претензии адепты из других языковХорошо, как решить данную задачу, когда зависимости ставятся онлайн, а проект потом пишется оффлайн? Никак? Собирать по кусочкам из других проектов?
>Кому-то ООП из джавы подавай, кому-то структуры из питона, кому-то сборку "поведение, идентичное ocaml".Go выглядит как обрубленный язык из восьмидесятых. У него нет ничего уникального или выдающегося. И когда у людей появляются необычные потребности, то ничего он им дать не может
>GO имеет довольно стройную систему и как язык и как средаGo абсолютно не гибкий, но почему-то это преподносится как фича.
ЗЫ Оказывается, в Go можно сделать нечто подобное, поскольку GOPATH оказывается может принимать несколько путей https://nixos.org/manual/nixpkgs/stable/#sec-language-go Хотя всё равно не понятно, почему я не вижу пометки пакетов для go в nixos, как это есть для ocaml. Так что проблема ТС решена - и поставить зависимости для go через nix всё же можно. Но я не проверял, насколько хорошо это работает.
>Хорошо, как решить данную задачу, когда зависимости ставятся онлайн, а проект потом пишется оффлайн? Никак? Собирать по кусочкам из других проектов?ШтА?!?!?! 8-о
Ты доку на go mod вообще читал?!?!?
Там подробно разжёвано, для хлебушков ... но на ангельском ;) Что великий програ*изд не осилил ёзыка для програ*издофф? :)(*) Если ветку читают дети: Дети! Читайте о "go mod vendor" и будет вам ...
>Go выглядит как обрубленный язык из восьмидесятых.
Ты просто не видел языков из 80-х, которые там и застряли... Зажрались вы робяты :)
>У него нет ничего уникального или выдающегося.
И слава всем богам всех религий сразу!!!!!!!!! :-D
>И когда у людей появляются необычные потребности, то ничего он им дать не может
Купите ябблобук и поставьте Node/JS и Rust! Ну или полЫ поменяйте :)
(*) Трищ маЁр - ещё раз, медленно - пол_Ы_! Призывов к непотребству - нет!>Go абсолютно не гибкий, но почему-то это преподносится как фича.
Хочешь гибкости? Ну возьми JS или сразу лисп... Зачем мучаешь ан*с твЁрдым нефритовым го? :)))
>(*) Если ветку читают дети: Дети! Читайте о "go mod vendor" и будет вам ...Добро пожаловать в js с его загадками уровня [] + {}, в мануале на 100500 страниц всё описано. У вас же нет других дел, кроме как чтения мануала на каждый чих, принцип наименьшего удивления не изобретён
>Ты просто не видел языков из 80-х, которые там и застряли... Зажрались вы робяты :)Если сделать современную обвёртку для далеко не самых передовых идей из 80-ых, то не все поймут, что идеи эти устарели уже в 80-ых, то есть лет сорок назад
И получается, что если будет указаны локальные зависимости, то это уйдёт в репозиторий для всех?
В новую директорию нужно также go.sum скопировать. В нем хеши зависимостей записаны, и по ним компилятор определит что они уже есть на компе.А без этого компилятор просто пытается получить последнюю версию всех зависимостей снова
>В новую директорию нужно также go.sum скопировать.Гениально! А зачем вообще было создавать отдельный каталог и помещать туда hello.go, если можно было остаться в том же? Даже перекомпилировать не надо, бинарник-то уже собран!
Это был пример для гарантированного воспроизведения!Для недалеких: в реальности вместо hello.go может быть другая прога, хотя и включающая те же зависимости (+ другие тоже уже скачанные), но для которой нет готовых go.mod|sum.
>Для недалеких: в реальности вместо hello.go может быть другая прога, хотя и включающая те же зависимости (+ другие тоже уже скачанные), но для которой нет готовых go.mod|sum.А откуда go узнает, какие вам версии нужны? Может вам сейчас нужна версия 2, а скачана - 1.5?
Думаете, только благодаря подключенной сети каким-то образом определяются нужные мне версии? Нет, конечно. Для сторонних наблюдателей небольшой ликбез: гляньте исходник hello.go. Видите, там при импорте с гитхаба не нужно указывать версии? А при создании новой программы на go никаких go.mod|sum для нее изначально нет. Эти файлы с версиями при сборке go автоматически сгенерирует, вручную версии зависимостей указывать не надо. То есть тот же самый алгоритм генерации можно натравить на кэш, но go вместо этого принудительно ломится в сеть. А если гоферов станет гораздо больше, то это еще будет и бессмысленный DDoS ресурсов, с которых импортируются зависимости. Представьте, что при компиляции новой сишной проги через gcc у вас запускается apt-get update, чтобы проверить libxml в репах, хотя этот libxml уже есть в кэше пакетов и установлен.
>А при создании новой программы на go никаких go.mod|sum для нее изначально нет.В таком случае, можно поздравить гопников с их интуитивно понятным пакетным менеджером, который решительно непонятен
>Видите, там при импорте с гитхаба не нужно указывать версии? А при создании новой программы на go никаких go.mod|sum для нее изначально нет. Эти файлы с версиями при сборке go автоматически сгенерирует, вручную версии зависимостей указывать не надоЭто абсурд. Если есть несовместимые между собой 1.5 и 2, то go никак не догадается, какой из них брать. Конечно, можно попробовать взять последнюю выпущенную, но это будет ломаться на каждой обратно несовместимой библиотеке
>То есть тот же самый алгоритм генерации можно натравить на кэш, но go вместо этого принудительно ломится в сетьТакого алгоритма в принципе не должно быть. Поскольку вначале должна ставится какая-то конкретная версия, и потом она должна замораживаться. Условно >= 1.5, но не 2.
>хотя этот libxml уже есть в кэше пакетов и установленА каким образом go должен догадываться, какую версию брать? Может у вас старая версия лежит, которую не обновить из-за техдолга в одном из проектов? Так что теперь, новый проект тоже должен быть на старой версии? Или наоборот, вы попробовали ночную сборку, а теперь хотите рабочий проект на стабильной сделать.
Сборка проекта и установка зависимостей может быть в одном шаге только в том случае, если точно известно, какая версия. Условно как в stack у хаскеля. Хотя тут хаскель скорее отрицательный пример, поскольку если я не хочу компилировать библиотеки самостоятельно, а взять из бинарного репозитория, то хаскель успеет выкачать часть кода самостоятельно, замусорив мне диск.
>>А при создании новой программы на go никаких go.mod|sum для нее изначально нет.
>В таком случае, можно поздравить гопников с их интуитивно понятным пакетным менеджером, который решительно непонятенВ таком случае поздравь себя - ты делаешь выводы вселенского масштаба(С) опираясь на слова недоучек и откровенных тупиц. 8-/
И да в го - можно (и для некоторых проектов даже ___нужно___ !!!) задавать версии модулей.
А если там пусто - действует простая эвристика - качатся будет то, что хозяин модуля указал. Обычно last release ... но можно и наступить :)Чё вам не так? Автоматически полЫ программистам не меняет? Горюшко то какое :-)
>и для некоторых проектов даже ___нужно___
>А если там пусто - действует простая эвристикаЭто не эвристика, это магия. А магия - это не хорошо, так как сейчас магия работает, а через пять минут перестаёт
Любая достаточно развитая технология неотличима от магии (С) сами знаете кто ...Если _это_ для тебя - магия, иы ошибся в выборе профессии, инфа - 146% ;)
> А если гоферов станет гораздо больше, то это еще будет и бессмысленный DDoS ресурсов, с которых импортируются зависимости.Не будет, американцы ещё лет 10 назад начали противостоять DDOS и практикуют хостинг в "облаках". Там достаточно много компьютеров чтобы:
1. Локализовать проблему
2. Выдержать нагрузку
Или вы думаете технологии .Net и Java просто так стали популярными? В последнее время к ним присоединяют JS и Python, но это скорее связано с массовым комьюнити и тема не связана. Посмотрите зарубежные вакансии - много проектов связаны с облачными системами и именно в основном на перечисленных языках. Есть ниша и у PHP, но на этом основная часть вакансий заканчивается.
пользуйся стандартной либой, делов то
Делов-то больше прибавится, ведь тогда придется велосипедить. Это не наш метод!
> Делов-то больше прибавится, ведь тогда придется велосипедить. Это не наш метод!Тогда надо просто сделать пустой stuff_that_i_cant_live_without.go в котором в импорте прописать всё что хочется впихнуть в зависимости оставив func main(){} пустым, сделать go mod init SuperProject && go mod tidy там где есть интернет и ехать на дачу вбивать все остальное
Всё так! Рецепт одного француза с далёкого уже 2021 года :)
Работает до сих пор, но нитакусикам - неподЪёмно ;-)
Альтернативная логика гопников: если в голанге что-то не работает, то процесс нужно выстраивать вокруг того, как это не работает, а не чинить проблему.
>там где есть интернет и ехать на дачу вбивать все остальноеОсобенно хорошо будет, если у кого-то есть интернет, но конкретно сейчас его отломали. Или, если у человека внезапно появилось свободное время.
>Альтернативная логика гопников: если в голанге что-то не работает, то процесс нужно выстраивать вокруг того, как это не работает, а не чинить проблему.Кстати, подсветку синтаксиса там до сих пор не завезли?
> Особенно хорошо будет, если у кого-то есть интернет, но конкретно сейчас его
> отломали.- "Хочу булку из интернета, но интернета у меня нет"
Ребят, у вас с логикой точно все в порядке?
>Ребят, у вас с логикой точно все в порядке?Вам выше написали, что зависимости уже есть на машине, но в другом проекте. Вы читать умеете?
> Вам выше написали, что зависимости уже есть на машине, но в другом проекте. Вы читать умеете?Еще раз, Го-лэнговский кэш, он общий, - для всех модулей. Если один проект подцепил в зависимости что то сторонее, то оно будет в кэше пакетов доступно для всех других, при условии что новый проект(ы) будет хотеть точно такую же версию зависимости как в кэше. Если же человек не умеет читать документацию, для чего нужен вендоринг и шлепает его во всех своих проектах, то это его и есть проблема, так как он изолирует конкретную зависимость в одном модуле. И даже это не проблема, там куча других возможностей как очень просто перетащить зависимость в любой проект изолируя его от кэша , начиная от ручками, го ворк и заканчивая своим собственным локальным прокси. Но почему-то очень хочется "как у других", "как привык" - через мэнеджер пакетов. Нет. Это другой инструмент, не npm, со своими правилами и логикой и в первую очередь пытается предотвратить потерю зависимости, а также её целостноть, где каждая версия зависимости имеет свой хэш. И при всем при этом прекрасно работает в офлайне
>в импорте прописать всё что хочется впихнуть в зависимостиТо есть все версии кэшированных зависимостей должны быть заранее завендорены пока есть сеть (без сети go mod vendor может не сработать, как показано выше), ведь в оффлайне может понадобиться любая. Еще и специальная прога дожна быть, которая отслеживает поступление новых версий зависимостей в кэш для последующего завендоривания. Это же бессмысленное дублирование кэша модулей! Проще тогда залезть в исходники самого go, чем городить софт для автовендоринга.
>Это же бессмысленное дублирование кэша модулей!Вы сперва язык и его тулкит выучите, а потом критикуйте, а то у вас даже ХелоВорд с зависимостями получился. Нет в Го никаких проблем работы в офлайне, для тех кто банально умеет пользоваться гит-ом и языком и его тулкитом
> Еще и специальная прога дожна бытьОна уже в Го тулките
> поступление новых версий зависимостей в кэш для последующего завендоривания.
Вендоринг делается только для того чтобы разрабатывать в офлайне, в изолированной директории и ни от кого не зависящей, ни от платформы, ни от архитектуры, ни от текущего состояния кэша и закаченных пакаджей, просто все в одном фолдере, который можно упаковать и передать кому угодно. Вендоринг поможет исключить зависимость от импортированного компонента (на случай если тот решит пропасть) или привязаться к конкретной версии. Вендоринг никак не связан с кэшем, который изпользуется всеми проектами
> Это же бессмысленное дублирование кэша модулей!
И как вы передадите коллеге проект? Со всей вашей билд системой и зависимостями? А в го достаточно сделать вендоринг, запаковать директорию и отдать и пофиг как там усторенно все на другой машине
> Проще тогда залезть в исходники самого go, чем городить софт для автовендоринга.
Еще проще почитать документацию, чем гадать и делать выводы на мнениях опеннета и многие вопросы и догадки отпадут сами
История анонимного "специалиста" забаненного в гугле?> https://pastebin.com/96uYkp4P
Это не простой "hello.go"
Простой ниже
```
package main
func main() {
println("Привет")
}```
> создаём новый каталог, в который помещаем только hello.go, и пробуем его собрать.
Уже очень давно, перед сборкой полезно сделать сперва
go mod init Shedevr && go mod tidy
которые сами найдут если что в кэше
опционально для оффлайна: go mod vendor
но если ты в каждой новой папке пытаешься опять делать go mod vendor то ты ССЗБ, т.к. это то самое, - чтоб "не из кэша"
> fatal: unable to access 'https://github.com/mattn/go-runewidth/': Could not resolve host: github.com
> fatal: unable to access 'https://github.com/nsf/termbox-go/': Could not resolve host: github.comЭто типа новый прикол?
Т.е. сперва подключаешь зависимости из интернетa, сам, руками, а потом опс? Гениально !!!
Ничего что там https://github.com поставил в зависимости?
> А go mod vendor выдаёт:Если ты тащишь зависимости, сам, с интернета, то go mod vendor надо делать перед тем как интернет отключить, а потом хоть в бункере компиль, так же как и со всеми другими ЯП. И еще, ознакомся как можно очень просто скаченные зависимости (чужие, т.е. не свои) превратить в локальные, отвязанные полностью от интернета (подсказка: go.mod).
> Что за дейбилизм?Действительно !
> зависимости-то уже скачаны и в кэше!
Гнать - не надо, если зависимости скачанны и имееют ту же самую версию, повторно ничего не скачивается если версии и хэши сходятся в go.mod & go.sum
>Это не простой "hello.go"Тоже предлагаете ограничиться только стандартной библиотекой? См. комментарий выше.
>Уже очень давно, перед сборкой полезно сделать сперва
Как вы сделате это для еще не начатой программы? Мне нужно было телепортироваться в будущее на дачу, чтобы заранее сгенерировать go.mod|sum?
>>Это не простой "hello.go"
> Тоже предлагаете ограничиться только стандартной библиотекой? См. комментарий выше.Для Hello_World - 100% !
Это-ж надо быть полным извращенцем, чтоб для Хелло подтянуть кучу АБСОЛЮТНО не нужных пакеджей
> Как вы сделате это для еще не начатой программы? Мне нужно было
> телепортироваться в будущее на дачу, чтобы заранее сгенерировать go.mod|sum?Вы хотите выиграть медаль за лучший тролинг здесь, на опеннете?!
Типа - "Хочу программу, и чтоб самому не писать уже готовое и чтоб оно халявненькое магически прилетело ко мне без интернета... на дачу"
Я уже выше сказал, - как это делается, но если и правда не понятно, то специально для вас, пошагово: https://gist.github.com/gmolveau/f09c1038ca622620e54d0579ba0...
Вместо того чтоб позориться говоря полную ерунду, потратьте время на гыгл. Тем кому надо на даче или в бункере, работают в эиргапе позади собственного go mod proxy ака - "athens" вместо того чтоб кидать подобные заявы
>специально для вас, пошаговоЭтот offline_modules.go не поможет, когда его импорты не успел обновить. Ведь без сети можно оказаться не только на даче, но и в результате поломок у провайдера, или внезапной недоступности ресурса, с которого импортируется зависимость. То есть когда зависимости все есть в кэше, но offline_modules.go не успел обновиться, то go опять не соберет программу без сети.
>уже выше сказал, - как это делается, но если и правда не понятно, то специально для вас, пошагово: https://gist.github.com/gmolveau/f09c1038ca622620e54d0579ba0...Интересно, что же там есть?
>copy go.mod and go.sum files from the offline PC to the internet PCЕсли вы бездомный, то просто купите себе дом. Спасибо
>и чтоб оно халявненькое магически прилетело ко мне без интернета... на дачуВыше вам уже описали что хотят - достать версию, которая есть в кеше. Когда авторы голанга, движимые NIH зачем-то создавали go, не просто язык, а ещё и изобрели к нему пакетный менеджер, вместо того, чтобы взять существующий нормально работающий. Далее, они наполнили этот пакетный менеджер магией, чтобы он умел скачивать напряму с гитхаба(что он ещё умеет/не умеет?). Но как и полагается велосипеду, этот велосипед умеет далеко не всё
>Тем кому надо на даче или в бункере, работают в эиргапе позади собственного go mod proxy ака - "athens"Предположим, я захотел посмотреть, что это за go такой. Вы предлагаете мне читать кучу мануалов и ставить себе дополниельные кешы? Вы уверены, что это в каждом самоучителе на первых страницах написано? А если язык мне не понравится, зачем столько усилий прикладывать? В нормальных языках данная проблема решается просто: есть отдельная фаза установки зависимостей и отдельно - сборка проекта. А установка делается через универсальный пакетный менеджер, а не свой собственный велосипед, который почти ничего не умеет. Универсальный пакетный менеджер осваивается, а потом используется для всех языков и систем, а не только для go. И одной из фич этого пакетного менеджера - работа оффлайн, когда он берёт уже скачанные версии и из них формирует рабочее окружение. То есть, даже после отключения интернета, можно взять зависимости от другого проекта, если они есть, в кеше, при чём это будет полностью прозрачно. То есть, если у меня есть проект a зависимый от z, y, и проект b зависимый от y, x, которые совместимы, то я могу полностью оффлайн собрать проект c зависимый от x, z, хотя ни один из проектов не содержит обе эти зависимости одновременно. Более того, я могу даже не просто указать абстрактный y, а даже заморозить его версию. А советы всех гошников здесь - это найдите машину с интернетом. Но если я могу найти машину с интернетом, то и описанной проблемы нет, поскольку проблема в том, что у меня нет машины с интернетом.
> Выше вам уже описали что хотят - достать версию, которая есть в кеше.Хорош тролить.
Нет проблемы в Го изпользовать то, что уже закэшированно.Гугл в зубы и вперед, вместо того чтоб телепатировать у кого NIH а у кого нет
> когда он берёт уже скачанные версии и из них формирует рабочее окружение.
Не, не, не - пусть это чудо без интернета скачает, так же как вы хотите от Го. А то, что вы описали, это точно так, как работает Го и все укладывается в одну команду тулкита, - кэшируется и юзается всеми проектами кому нужнo сторонний пакедж.
> Но если я могу найти машину с интернетом, то и описанной проблемы нет, поскольку проблема в том, что у меня нет машины с интернетом.Топите дальше, порадовали :)
> Но если я могу найти машину с интернетом, то и описанной проблемы нет, поскольку проблема в том, что у меня нет машины с интернетом.В следующем треде предлагаю обсудить более реалистичный вариант - машина без клавиатуры (чай пролить реальнее, чем оказаться без сети) и на каком языке можно писать без оной. Если таков будет найден, присвоем ему статус "нормальный" и перейдём к обсуждению остальных маловероятных случаев и костылей для героического исхода.
Воткни новую клаву чере Ю-Эс-бЕ и програмЪ на том на чём программил ... да это магия!(С) ;-)
> Плохо, что go-программму уже невозможно скомпилировать без подключённого интернета.Документацию читать надо, да.
> Как воспроизвести:
GO111MODULE=off - не воспроизводится.
>GO111MODULE=off - не воспроизводится.Да ну?
$ GO111MODULE=off go build -v hello.go
hello.go:8:8: cannot find package "github.com/mattn/go-runewidth" in any of:
/usr/lib/go/src/github.com/mattn/go-runewidth (from $GOROOT)
/media/temp/go/src/github.com/mattn/go-runewidth (from $GOPATH)
hello.go:7:8: cannot find package "github.com/nsf/termbox-go" in any of:
/usr/lib/go/src/github.com/nsf/termbox-go (from $GOROOT)
/media/temp/go/src/github.com/nsf/termbox-go (from $GOPATH)С тех пор, как в go принудительно включили модули по умолчанию, то $GOPATH пустует, или там хранятся завалы легаси. Кэш теперь в другом месте. Тут даже включенная сеть не поможет.
> Да ну?Ну да
> $ GO111MODULE=off go build -v hello.go
> /media/temp/go/src/github.com/mattn/go-runewidth (from $GOPATH)У тебя GOPATH пустой
> С тех пор, как в go принудительно включили модули по умолчанию, то
> $GOPATH пустует, или там хранятся завалы легаси. Кэш теперь в другом
> месте. Тут даже включенная сеть не поможет.Нет
>У тебя GOPATH пустойСпасибо, кэп. Про прибитость современных версий go к модулям повторяться не стану. Вылазь уже из криокамеры.
Посмотри https://nixos.org/manual/nixpkgs/stable/#sec-language-go , может из go и можно получить подобие нормального языка
Это вряд ли - всё к чему прикасаются nixos-ники неизбежно превращается в оно :(
Карма.
Они уже почти ко всему прикоснулись, посмотрите на их гиганский репозиторий.
из всех экспертов в этом треде ни один не написал про go mod download.А впрочем, чего еще ждать от опенка
>go mod downloadЗависимости уже есть в кэше. См. пункт первый.
> Будучи на даче, обнаружилось, что go build без интернета совсем не работает (выдаёт ошибки подключения к сети)В 2025 году жаловаться на отсуствие интернета, тем более, когда пишешь на языке, основной уклон которого, этот самый интернет (бекэнды).
Чес слово, странно читать.
>В 2025 году жаловаться на отсуствие интернетаВ 2025 году вам запрещают скомпилировать программу без интернета, а в 2035 году вам запретят компилировать программу без отправки sms на специальный корпоративный номер, в 2045 году вам запретят скомпилировать программу без специальной биологической идентификации. И так далее...
А как вам запрет вести разработку на гитхабе без следящего маячка в виде зондосмартфона? Сам go еще активно собирает подробную информацию о вашей системе и готов отправлять ее куда надо https://opennet.ru/58639/. В каком году go-программы перестанут компилироваться без отправки телеметрии? А если гоферов станет гораздо больше, то это еще будет и бессмысленный DDoS ресурсов, с которых импортируются зависимости. Зачем на каждый чих насиловать сеть, если все необходимое есть в кэше? А еще, когда на даче нет городского шума и не отвлекаешься на интернет, то работается лучше.>бекэнды
Это если речь исключительно о деньгах, а вообще на нем пишут практически все https://github.com/avelino/awesome-go
> В 2025 году вам запрещают скомпилировать программу без интернетаЕсли у тебя зависимость лежит в интернете, то логично, что ты не можешь скомпилировать без того, чего у тебя нет.
Компилить без интернета тебе никто не запрещает. Более того, предоставлены инструменты на такие случае и они описаны в офф. документации.
В 2025 году интернет - это уже давным-давно не роскошь. Поэтому по дефу сделали более удобное поведение для подавляющего большинства. Нужен модуль - просто импортируешь и при сборке оно само подтягивается. Вместо того, чтобы как обезьянка одно и то же набивать - abstr_pckg_mngr install super_dependency. Компилятор и пакетный менеджер - два в одном... с достаточным функционалом, чтобы отвязаться от сети.> а в 2035...
И тут Остапа понесло...
> А как вам запрет вести разработку на гитхабе без следящего маячка в виде зондосмартфона?
Для второго этапа авторизации? Так там можно хардварные ключи использовать, а не смартфон.
> А если гоферов станет гораздо больше, то это еще будет и бессмысленный DDoS ресурсов, с которых импортируются зависимости.
Я, конечно, могу ошибаться. Надо проверить, но лень.
Оно видит в коде зависимость, идёт в go.mod, видит версию, идёт в кэш, если у тебя есть модуль нужной версии, то в тырнет никто не идёт. О каком ДДоСе идёт речь? По такой логике тогда и бравзеры - это инструменты для ДДоСа. А сервера просто так должны быть, для красоты. Поставил, настроил и пусть стоит.> А еще, когда на даче нет городского шума и не отвлекаешься на интернет, то работается лучше.
Я вот дачу за это люблю. И использую её для цифрового детокса. Телефон валяется целый день дома. Проверяю 3 раза в сутки. И то на даче есть интернет. 120 км от города и 50 км от ближайшего райцентра. Если есть задача работать с дачи, то нет никаких проблем организовать там интернет. Хороший модем m2/minipci-e + адаптер на usb + роутер выходит не так дорого. Опционально - направленная 4g антена. Зимой, когда никого нет, скорость 170 Мбит/c, что больше, чем у меня дома. Летом не замерял, но на стримминг в 1080p всегда хватает.
Или ты специально его не делаешь, чтобы не отвлекаться на него? Тут это уже или к психологу, или самоконтроль, или пара правил iptables на роутере...
> Это если речь исключительно о деньгах, а вообще на нем пишут практически все
Ну, и навскидку две трети из этого или непосредственно с сетью работает, или подразумевает использование в сетевом контексте.
Так или иначе сейчас почти всё завязано на сеть. Такие времена.
>Обеспечена полная поддержка обобщённых псеводонимов типовНадо же, а как же возможность выучить язык за пару вечеров?
>В команду "go" для Go-модулей добавлен механизм отслеживания исполняемых зависимостейТого и глядишь, за лет двадцать доростут по удобству до php
Кто-то может объяснить, зачем голангу более пятиста мегабайт виртуальной памяти даже в hello world?
Ты документацию почитай и используй флаги.go build -ldflags="-w -s" .
> -s disable symbol table
> -w disable DWARF generation
Это к чему? В момент появления заявлялось, что для любых программ хватит того минимума, что был реализован в go. Потом по мелочам его стали править - то дженерики введут, то for расширят.
... то стандартный net/http сделают такой! что пейсатели веб фрэймворков дружно идут на выход :) (только с версии 1.21.чегото)Но куму нужен этот http в 2к25-ом то?!?! ;-D
по удобству выстрелить себе в ногу? просто других удобств в пыхе не было
А какие удобства в go - interface {}?
Ну во первых - это красиво! (С) ;-)
А ещё, падает во время исполнения, прямо как динамически типизированный бидон, ой то есть питон.
> Кто-то может объяснить, зачем голангу более пятиста мегабайт виртуальной памяти даже в
> hello world?Хорош уже гнать, спецы блин, оно в принципе, больше чем полутора мега максимум не сожрет для хелло
Rust здорового человека.
Может быть - borgo. Поскольку груз обратной совместимости с go никто не отменял.
Тогда Cargo?
Шта? Да он Rust и в подмётки не годится.
Ничто и никто и никогда не годится в подмётки языку для переписывани!(С)
Мы внимаем - доставляй езчщiо! :)
Посмотрим как оно будет бутстрапится. Вроде как через одну версию можно перепрыгивать. Уже не rust, еще не gcc. gcc может через несколько версий перепрыгивать.
ещё 15 лет будешь "посмотрим"?
Сколько бог даст. Исходный код должен работать, собираться, а не валятся как готовый бинарник. Имея один файл исходника, можно собрать бинарники под множество архитектур. Это очень круто.
Обратная совместимость не имеет никакого отношения к тому, насколько новый компилятор нужен для самосборки
То ли дело mit-scheme. Чтобы 12.1, нужна mit-scheme 12.1
И как из этой петли выходить?
Бинарник качать
А бинарник откуда берётся? Если я хочу его сам собрать, то мне что, коммит за коммитом собирать?
Хороший язык во всех отношнениях, и если бы я начилал изучать программирование, я бы выбрал гошечеку. Но я уже старый и на пенсии.
Ужасный язык, так как отметает любой прогресс в области разработки языков. Добро пожаловать в восьмидесятые, снова, хотя уже в восьмидесятых были варианты гораздо лучше, типа StandardML
Фичи ради фич и торможения? Но для этого уже есть Раст.
>Фичи ради фичВам нравится получать NPE? Хотя стоп, у вас же исключений нет, только паника
>и торможения?Ocaml сопоставим по скорости сборки с go.
>OcamlТы в курсе что оно даже сейчас в 2k25-ом ... как бе это сказать то ... оно - однопоточное! 8-\ Так что иди с Питоном сравнивай, да поторопись там вот-вот GIL устранят :)
>как бе это сказать то ... оно - однопоточное!Уже нет. В 5.0 завезли многоядерность, а сейчас уже 5.3
>Так что иди с Питоном сравнивай, да поторопись там вот-вот GIL устранят :)Обожаю такие соревнования. На них ещё не пришёл, а уже выиграл
>Уже нет. В 5.0 завезли многоядерность,
>>> The OCaml 5.0.0 release in 2022 is a complete rewrite of the language runtime, removing the global GC lockО! Во - другое дело! СПС анон@13-Фев-25T14:04 - пойду гляну на выходных.
ПредЪява - снимается! Ocaml неуиноват!(С) :-)
>Но для этого уже есть Раст.За тормозами - в haskell. На расте сборка проекта может быть быстрой.
>На расте сборка проекта может быть быстрой.Если бы ты собирал проекты на чистом Си, ты бы знал по настоящему, что такое быстро. На самом деле ни C++, ни Rust не быстрые.
>Если бы ты собирал проекты на чистом Си, ты бы знал по настоящему, что такое быстроСи и скорость? Не смешите меня.
https://www.opennet.me/opennews/art.shtml?num=56449 Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%
Для сравнения, в ocaml завезли модули. И там не нужно на каждый include километры исходников гонять. А потом наступает второй файл, и там опять include
>На самом деле ни C++, ни Rust не быстрые.Я собирал вот это https://crates.io/crates/gluon/0.18.2/dependencies. С учётом того, что всё - и зависимости и сам проект скачивались и собирались с нуля, то собралось быстро.
Зато сборка самого rustc не быстрая.
Не меряйте по его сборке всё остальное. Особенно с учётом того, что llvm тоже не мгновенно собирается
Изучать программирование никогда не поздно. И начинать лучше не с Go.
> Изучать программирование никогда не поздно.Ага, скажешь это, когда перевалит за 60. Посмотрю я как ты будешь зазубривать неделями то, что 18 летние схватывают за 5 минут просмотра на ютубе.
В 60 лет можно освоить чат гпт и программировать лучше 18 летних, которые видео длиннее 15 секунд смотреть не могут.
С чатгпт ты напрограммируешь только хеллоуврот на 100 строк максимум. Оно не съест контекст из 100500 зависимостей на тысячи строк.
> видео длиннее 15 секунд смотреть не могутНе не могут, а не хотят. Для того чтобы понять что видео полное Г достаточно 10 секунд. Они не хотят тратить время на ненужное.
>Изучать программирование никогда не поздно. И начинать лучше не с Go.Наверное да. Есть бэйсик, паскаль, лого и хаскель :)))))
> Хороший язык во всех отношненияхТы хочешь сказать раскрученные всякими unix оидами, финами, ну такое себе skillfactory, и skillbox сами себя не окупят.
Ведро - официально самый успешный софтвер прожэкт за всю историю человечества!(С)
Нравится тебе это или нет :)
В новостях забыли про вкусную фичу: Config.EncryptedClientHelloKeys
которая будет делать Encrypted Client Hello (ECH) in TLS делая ХТТПС наконец то полностью шифрованным
С map[P]struct{} они конечно многим свинью подложили(
ммм, няшный Go.)
Вот когда голосовали за generics - ты как проголосовал?! Теперь то чего ... наслаждайтесь :)
Да нормальный синтаксис, не хуже "угловых скобок". Можно углядеть даже метафору "массива типов" в этих квадратных скобках.
Для тех, кто не пишет на go, в чём проблема?
Когда тебя завалят на собесе по Го - поймёшь :)Го - жив ==> hence НЕ идеален. Вот это - нюанс, тупо нужно знать. Гугли отрок, да и пройдёшь собеседование окояЪнное! :)
Я просто оставлю это здесь: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...Краткие выводы из статьи, сделанные с помощью ChatGPT:
В статье автор подробно рассматривает несколько ключевых технических недостатков языка Go, из-за которых, по его мнению, он не подходит для серьезных производственных систем.
Основные недостатки Go по версии автора:
1. Отсутствие дженериков в течение долгого времени
Автор указывает, что отсутствие дженериков (до их добавления в Go 1.18) приводило к необходимости писать повторяющийся код или использовать неэффективные обобщенные структуры данных (например, interface{}), что снижало производительность и безопасность.
2. Ошибка обработки ошибок через if err != nil
В Go ошибки обрабатываются вручную с помощью множества проверок if err != nil, что засоряет код и увеличивает вероятность пропуска ошибок.
В отличие от языков с конструкциями try/catch или Result/Option (как в Rust), в Go нет механизма, который вынуждает программиста учитывать возможные ошибки на уровне типов.
3. Слабая система управления зависимостямиGo изначально использовал GOPATH, что было неудобно.
Даже с появлением Go Modules, автор считает систему неудобной и несовершенной по сравнению с менеджерами зависимостей других языков (например, Cargo в Rust).4. Бедная система типов
Автор указывает, что отсутствие иммутабельности, сложность работы с nil-указателями и слабая выразительность системы типов приводят к ошибкам, которые можно было бы избежать в языках с более строгой типизацией.
5. Отсутствие возможностей для абстракции
В Go нет традиционных механизмов ООП (наследования, перегрузки методов и т. д.), что заставляет писать много шаблонного кода.
Интерфейсы Go хоть и простые, но недостаточно мощные для создания гибких архитектур.6. Garbage Collector (GC) вместо ручного управления памятью
Хотя GC упрощает управление памятью, он может стать проблемой для высоконагруженных приложений.
В языках вроде Rust управление памятью производится без GC, что даёт лучшие характеристики по производительности и предсказуемости работы.7. Стандартная библиотека и культура «ручного» кодирования
В отличие от Python или Rust, в Go не так много удобных встроенных решений (например, нет из коробки хорошего JSON сериализатора).
Разработчики Go часто гордятся тем, что «код пишется вручную», но это приводит к большему количеству ошибок и дублирования кода.Вывод автора
Он считает, что многие оправдывают использование Go мифами о его «простоте», но на практике язык создаёт больше проблем, чем решает. По его мнению, если нужен производительный и безопасный язык, стоит рассмотреть альтернативы вроде Rust.
"По его мнению, если нужен производительный и безопасный язык, стоит рассмотреть альтернативы вроде Rust"Ага пока не увидишь этот самый код на Rust
Это потому, что его надо подготовленным смотреть - то есть, какую-никакую документацию почитать о семантике языковых абстракций. А если с наскоку, после Питона, Джава скрипта или Си - таки да, ничего не понятно.
Говорят, вот люди которые в чем то разбираются могут обьяснить простыми терминами так что даже 5 летний ребенок поймет.
КНо ведь всё равно надо, чтобы кто-то объяснил, не правда ли?
Давайте, объясните пятилетнему ребёнку, как работает система аффинных типов на примере borrow checker, чтобы он после этого сел и начал писать код. Или то, чем система типов раста и окамла похожа, а чем различается, и что из этого вытекает, пускай он напишет систему типов.ЗЫ пятилетний ребёнок не поймёт никаких сложных вещей. А если ему начать объяснять, то к тому моменту, когда он их поймёт, ему будет уже намного больше, чем пять лет.
> Говорят, вот люди которые в чем то разбираются могут обьяснить простыми терминами так что даже 5 летний ребенок поймет.Не "говорят", а "говорил". Ричард Фейнман заявлял подобное, и он в общем-то говорил про физику. Причём не про физику в целом (попробуй объяснить пятилетнему ребёнку уравнение Шрёдингера, лол), а про интуитивное, качественное понимание физических процессов. Количественные законы в физике уже требуют матана, и подчастую нетривиального, которого на первом курсе не рассказывают.
Так что не надо делать из заявлений Фейнмана выводов, что если ты не понимаешь чего-то, несмотря ни на какие объяснения, что все вокруг идиоты.
Объяснять сложные вещи посредством более простых - это именно то, что делается в С++ (всё через классы). Например, лямбда-функция - это класс, интеллектуальный указатель - это класс, и т.д.
Однако разве это хорошо? Основываясь на ненадёжном фундаменте, вся эта сложная конструкция сложных объектов становится совершенно неустойчивой, и трудно понять почему код не работает в конкретном случае, где в нижележащих классах ты не учёл какую-то мелочь. Заставить классы работать как надо - трудная задача.
Надёжнее было бы сложные вещи сделать встроенными понятиями языка.
>Ага пока не увидишь этот самый код на RustГм, ну я каждый день вижу и создаю этот самый код на Rust. И пока вроде никто не умер. Красивый лаконичный выразительный код.
>>Ага пока не увидишь этот самый код на Rust
> Гм, ну я каждый день вижу и создаю этот самый код на
> Rust. И пока вроде никто не умер. Красивый лаконичный выразительный код.дай кусок посмотреть, может я даже не умру от кринжа а наиборот проникнусь
Ну вот, например (хотя зачем ты начал обсуждать Rust в теме про Go — ума не приложу):
fn get_config_file_path(dir: &Path, config_path: &Path) -> (PathBuf, PathBuf) {
let root_dir = dir.ancestors().find(|a| a.join(config_path).exists()).unwrap_or_else(|| {
messages::unravel_errors(
"",
&anyhow!(
"{} not found in current directory or ancestors, current_dir is {}",
config_path.display(),
dir.display()
),
);
std::process::exit(1);
});// if we got here we found root_dir so config file should exist so we could theoretically unwrap safely
let config_file_uncanonicalized = root_dir.join(config_path);
let config_file = config_file_uncanonicalized.canonicalize().unwrap_or_else(|e| {
messages::unravel_errors(
&format!("Could not find canonical path of {}", config_file_uncanonicalized.display()),
&e.into(),
);
std::process::exit(1);
});(root_dir.to_path_buf(), config_file)
}
> хотя зачем ты начал обсуждать Rust в теме про Go — ума не приложу):я?
>
>весьма вырвиглазно, но, наверное привыкнуть можно
>> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон.Вообще в книгах не только Си и Оберон в заимствованиях встречается. Там вроде и Паскаль упоминается и вроде бы даже и Пролог!
Нормальный язык программирования, я на нем для роутера на Openwrt под mipsel делал сервачок, при этом особо языка не зная. Но с документацией быстро разобрался. Все было просто и понятно.
Раз уж не возбраняется приводить доводы нейросетей, что вот что даёт ChatGPT по запросу «Какой из двух языков эффективнее с точки зрения качества исходного кода: читабельности, простоты написания и сопровождения, скорости выполнения программ: Go или Nim» — то, что ближе мне.Привожу лишь резюме.
Общий вывод
Критерий Победитель
Читабельность Nim
Простота написания Nim (но Go проще для больших команд).
Сопровождаемость Go (из-за единообразного кода).
Скорость выполнения Nim (ближе к C).
Если важна читабельность и скорость → Nim.
Если важна простота сопровождения в команде → Go.🔹 Go лучше для корпоративных решений и больших команд (безопасность, предсказуемость).
🔹 Nim лучше для высокопроизводительных задач и исследований (скорость, гибкость, метапрограммирование).