https://opennet.dev/openforum/vsluhforumID3/136004.html После шести месяцев разработки представлен релиз языка программирования Go 1.24, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62710<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#309 Mon, 17 Feb 2025 13:08:28 GMT Раз уж не возбраняется приводить доводы нейросетей, что вот что даёт ChatGPT по запросу &#171;Какой из двух языков эффективнее с точки зрения качества исходного кода: читабельности, простоты написания и сопровождения, скорости выполнения программ: Go или Nim&#187; &#8212; то, что ближе мне.<br><br>Привожу лишь резюме.<br><br>Общий вывод<br>КритерийПобедитель<br>ЧитабельностьNim<br>Простота написанияNim (но Go проще для больших команд).<br>СопровождаемостьGo (из-за единообразного кода).<br>Скорость выполненияNim (ближе к C).<br>Если важна читабельность и скорость &#8594; Nim.<br>Если важна простота сопровождения в команде &#8594; Go.<br><br>&#128313; Go лучше для корпоративных решений и больших команд (безопасность, предсказуемость).<br>&#128313; Nim лучше для высокопроизводительных задач и исследований (скорость, гибкость, метапрограммирование).<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#308 Fri, 14 Feb 2025 15:46:56 GMT А ещё, падает во время исполнения, прямо как динамически типизированный бидон, ой то есть питон.<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#307 Fri, 14 Feb 2025 15:43:54 GMT Кто рекомендует? В go нет арифметики указателей, но это не делает язык типобезопасным. Прочитайте определение терминов, прежде чем придумывать<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#305 Fri, 14 Feb 2025 10:00:06 GMT Ваш пост про скорость Явы и немыслимость обработки без нее больших объемов данных сделал мой день гораздо веселее :D :D :D<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#303 Fri, 14 Feb 2025 09:13:53 GMT &gt; хотя зачем ты начал обсуждать Rust в теме про Go &#8212; ума не приложу): <br><br>я?<br><br>&gt; [code] <br>&gt; [/code] <br><br>весьма вырвиглазно, но, наверное привыкнуть можно<br> https://opennet.dev/openforum/vsluhforumID3/136004.html#302 Fri, 14 Feb 2025 08:54:47 GMT &gt; думаю - доведут.<br><br>Опять 25. Да всё довели уже 5 лет назад. <br> https://opennet.dev/openforum/vsluhforumID3/136004.html#299 Fri, 14 Feb 2025 07:28:43 GMT Ну вот, например (хотя зачем ты начал обсуждать Rust в теме про Go &#8212; ума не приложу):<br><br>[code]<br>fn get_config_file_path(dir: &Path, config_path: &Path) -&gt; (PathBuf, PathBuf) {<br> let root_dir = dir.ancestors().find(&#124;a&#124; a.join(config_path).exists()).unwrap_or_else(&#124;&#124; {<br> messages::unravel_errors(<br> "",<br> &anyhow!(<br> "{} not found in current directory or ancestors, current_dir is {}",<br> config_path.display(),<br> dir.display()<br> ),<br> );<br> std::process::exit(1);<br> });<br><br> // if we got here we found root_dir so config file should exist so we could theoretically unwrap safely<br> let config_file_uncanonicalized = root_dir.join(config_path);<br> let config_file = config_file_uncanonicalized.canonicalize().unwrap_or_else(&#124;e&#124; {<br> messages::unravel_errors(<br> &format!("Could not find canonical path of {}", config_file_uncanonicalized.display()),<br> & https://opennet.dev/openforum/vsluhforumID3/136004.html#297 Fri, 14 Feb 2025 03:22:48 GMT &gt; Вам выше написали, что зависимости уже есть на машине, но в другом проекте. Вы читать умеете?<br><br>Еще раз, Го-лэнговский кэш, он общий, - для всех модулей. Если один проект подцепил в зависимости что то сторонее, то оно будет в кэше пакетов доступно для всех других, при условии что новый проект(ы) будет хотеть точно такую же версию зависимости как в кэше. Если же человек не умеет читать документацию, для чего нужен вендоринг и шлепает его во всех своих проектах, то это его и есть проблема, так как он изолирует конкретную зависимость в одном модуле. И даже это не проблема, там куча других возможностей как очень просто перетащить зависимость в любой проект изолируя его от кэша , начиная от ручками, го ворк и заканчивая своим собственным локальным прокси. Но почему-то очень хочется "как у других", "как привык" - через мэнеджер пакетов. Нет. Это другой инструмент, не npm, со своими правилами и логикой и в первую очередь пытается предотвратить потерю зависимости, а также её целостноть, где каждая версия зависимос https://opennet.dev/openforum/vsluhforumID3/136004.html#296 Fri, 14 Feb 2025 02:31:03 GMT Когда тебя завалят на собесе по Го - поймёшь :)<br><br>Го - жив ==&gt; hence НЕ идеален. Вот это - нюанс, тупо нужно знать. Гугли отрок, да и пройдёшь собеседование окояЪнное! :)<br>