Комментарии 25
Весьма приятный язык для различного веб-бэкенда, консольных утилит и прочего серверного софта. Давно хотелось реализовать некоторые идеи для веба и/или с веб-интерфейсом, но имея основной опыт С/С++, было весьма непросто и больно писать на php. Переменные без явного объявления это кошмар, одна опечатка и привет поиск ошибки. Питон вообще не переношу, там и переменные без объявления, да еще и отступы вместо скобок.
Думал уже не написать ли backend на С++, но решил попробовать Go, и понравилось. Можно писать в процедурном стиле как на Си, можно использовать некий аналог ООП. Все переменные явно объявляются! И масса возможностей для работы с вебом. Не нужно никаких сторонне-костыльных утилит, типа композера, npm и прочей мути, которая ради hello world скачивает пару гигов.
Когда я смотрю опенсорс проекты на других языках (на том же С/С++) в гитхабе, у меня от изобилия всяких непонятных скриптов и конфигов, не являющихся файлами исходного кода, сразу пухнет мозг. Что это за мусор, зачем он нужен? Я не знаю что это всё такое, зачем оно мне, и это порядком раздражает. В Go проекты идеально чистые, только файлы go, единственный файл go.mod (который хоть и не является файлом проекта, но в какой-то мере ему соответствует) и ничего больше!
Раст тоже неплох как замена Плюсов, но к синтаксису и логике сложнее привыкнуть. А работа с асинхронными задачами в Tokio уже почти такая же простая как в Go (есть каналы, броадкасты всякие, таск трекер аля WaitGroup).
К примеру
use std::time::Duration;
use tokio::time::sleep;
use tokio_util::task::TaskTracker;
#[tokio::main]
async fn main() {
let tracker = TaskTracker::new();
for i in 0..10 {
tracker.spawn(some_operation(i));
}
// Once we spawned everything, we close the tracker.
tracker.close();
// Wait for everything to finish.
tracker.wait().await;
println!("This is printed after all of the tasks.");
}
async fn some_operation(i: u64) {
sleep(Duration::from_millis(100 * i)).await;
println!("Task {} shutting down.", i);
}
сторонне-костыльных утилит, типа композера, npm и прочей мути, которая ради hello world скачивает пару гигов
Не спора ради, а просто инфа для новичков: текст в цитате это очень сильное преувеличение. Даже если вы поставите жирный фреймворк (что не обязательно для простого сервера), это займёт сотню мегабайт максимум в экосистеме JS и PHP. Go в этом плане не лучше, потому что в устанавливаемых зависимостях находятся бинари для всех поддерживаемых платформах, то есть много не нужного вам.
Go скачивает только исходный код зависимостей и компилирует всё статически. Место занимают только код и объектные файлы в кэше после компиляции. Я вообще сомневаюсь, что он в принципе с готовыми бинарями умеет работать на уровне go mod.
Вы правы, я с чем-то перепутал. Прошу прощения.
Тем не менее, у меня сейчас папка с зависимостями для одного вер-серсиса занимает почти 3ГБ. Там всего по-немногу, самое жирное это aws-sdk-go, 294MБ.
Ну с "завязкой" на гит, скорее всего прям таки может. Как минимум можно поэкспериментировать, засунув в репозиторий .so-шники и собрав через CGO "вторую половину бинарника" - и всё это через go.mod.
Да, писать на go достаточно легко, пока не надоедает обработка ошибок через строчку. Или необходимость запятой в конце строк инициализацией в столбик, но это можно пережить форматтером.
Хуже то, что компилятор всё тащит в кучу при малейшем чихе. Надеюсь что хотя бы вызовы методов по (this type) девиртуализовали в своих же методах...
По мне, явная обработка ошибок это плюс.
Во-первых она, да - назойливая. В итоге действительно начинаешь обрабатывать. А чтобы не пришлось писать лишнего, приходится отделять грязный код, где могут быть ошибки, от чистого - где их не может быть в принципе. Чем-то похоже на хаскель.
Во-вторых она простая и однообразная. Когда твои плюсанутые товарищи только начинают разбираться в иерархииях наследования исключений. В гошечке достаточно выучить пару приемов и у тебя уже диплом.
Вторая половина моего поста меня беспокоит больше. Тут да, дело привычки.
Уже выкачал себе репу гошного компилятора и ковыряюсь. Пытаюсь понять как можно улучшить эскейп- анализ, который избыточно перестрахован и не инлайнит одноразовые функции, т.к. они больше 80 попугаев - решили вопрос или таки нет?
Который не умеет собирать деферы в клозуру с несколькими входами - даже не надеюсь, нереально на этом уровне реализации.
Выбрасывает в кучу факт. параметр только потому что формальный - интерфейс.. даже если это тупо указатель в 4 байта..
Метод с (this *type) вызывается внутри своего же подобного метода через виртуальную таблицу .. девиртуализация? Не не знаем как это.. Исправили? Про это и спросил..
Реализация интерфейса (контракта) может получать свои параметры только в куче.. зачем такое?
Суммарно из небольшого набора правил эскейп- анализа вылезает 21 причина выброса переменной в кучу, даже если она bool .. одын бит!
Когда этот список начнет сокращаться? Или доклаырять репу и форкать?
Имеется какой-то набор ченджлогов, чтобы мне после чтения учебника 2020-го года дополнить знания до современных версий, а не ждать учебника 2024-го года и искать, что есть нового?
https://go.dev/doc/devel/release
Cмотришь какой версии Go в книге и далее по версиям вверх просматриваешь Release Notes.
Либо искать в каком-нибудь блоге пост с компиляцией изменений по версиям
решена давняя проблема с циклами "for", приводившая при вызове сопрограмм (goroutine) к совместному использованию переменных цикла в разных итерациях;
каким образом? Это слом семантики кода в прошлом? Только внутри for?
продолжена работа по задействованию в компиляторе оптимизаций на основе результатов профилирования кода (PGO - Profile-guided optimization), позволяющих учитывать особенности, определяемые во время выполнения программы. В новой версии в компиляторе задействованы средства девиртуализации для замены непрямых вызовов различных методов на выполнение развёрнутых inline-блоков. При включении PGO добавленное изменение позволило повысить производительность большинства программ на 2-14%;
перепутана скорость компиляции и скорость программы
Проблема с циклами:
Потыкать можно вот тут https://antonz.org/go-1-22/#no-more-sharing-of-loop-variables
А скорость программы и компиляции не перепутаны: почитайте сначала что такое PGO, перед тем как писать комментарий
так pgo применено для компилятора
Profile-guided optimization (PGO) — техника оптимизации программы компилятором, нацеленная на увеличение производительности выполнения программы. (c) Wikipedia
)))
компилятор Go - программа. Для этой программы известны обычные её нагрузки, там применимо PGO, некий компилятор, вероятно gcc, собрал эту статистику и оптимизирует программу называющуюся компилятор языка Go
Для пользовательских программ у компилятора Go данных о рантайм собственно данных (информации для PGO) нет, как он сможет оптимизировать - непонятно
некий компилятор, вероятно gcc, собрал эту статистику и оптимизирует программу называющуюся компилятор языка Go
Компилятор Go написан на Go
Для пользовательских программ у компилятора Go данных о рантайм собственно данных (информации для PGO) нет, как он сможет оптимизировать - непонятно
Ну почитали что-ль для приличия бы. Компилятору скармливаются дампы профилировщика с прода и на их основе он уже оптимизирует.
🤦 Ну неужели так сложно поискать в интернете?
Кто применяет результаты профилирования при компиляции программ? Компилятор
Что перспективнее, Go или C#?
По моему небольшому кругозору-
go- для монолитного приложения, микросервиса, т.к. в нем отвратительная система плагинов (разделяемых библиотек). Пока что скудная реализация графической части - всего несколько библиотек отрисовывающих нативные графические интерфейсы.
C#- точно нужен при работе с unity, gamedev; знаю, что он хорошо себя чувствует с отрисовкой графики на windows, хотя net есть и для linux
А в целом- зависит от задач и целей
Спасибо за публикацию! Информация полезная. Особенно радует, что изменения небольшие и аккуратные... И ни кто не пытается даже вид делать, что вот "бросим таки вызов С++ !" ))) Пусть С++ остаётся непревзойдённо крутым, а Go продолжает быть удобным и практичным инструментом. И некоторое количество несуразностей - это всего лишь заявка на возможность появления в будущем некоего Go++, уже более стройного академически ... Хотя подозреваю, что сообщество в ближайшие годы может вполне удовлетвориться только улучшениями компилятора и дальнейшим совершенствованием и расширением библиотеки! Как считаете?
Вышел Go 1.22