Игра с языком программирования Go (более известным в поисковых системах как «Golang») в течение недели открыла мне глаза. Теперь я знаю, что по умолчанию вещи не должны быть такими сложными. Я ценю простоту, и многие концепции Go имеют для меня смысл: например, отсутствие того, что делает программирование громоздким и лишает его удовольствия.
Итак, вопрос: сможет ли он завоевать рабочий стол и превратить «GNU / Linux» в «Go / Linux»?
Представьте, что вы хотите написать крошечный HTTP-сервер, который обслуживает корневой каталог на 80-м порту и сообщает о себе в сети с помощью Zeroconf. Далее представьте, что вы хотите иметь двоичные файлы для Windows, Linux и Mac. 64-битные и 32-битные. Да, и для Raspberry Pi тоже. И почему бы не OpenWrt, работающий на MIPS.
Сколько времени это займет при использовании C или C ++? Сколько часов борьбы с потоками, сетью, общими библиотеками, автоинструментами, настройкой инструментальных средств компилятора, средами сборки Docker, Makefiles или CMake? Только чтобы узнать, что продукт, построенный на Fedora 30, не будет работать на CentOS 6?
Что бы вы сказали, если бы я сказал вам, что все вышеперечисленное можно легко сделать не более чем за 10 минут?
И эти 10 минут предназначены для кодирования программы и кросс-компиляции всего этого, а не только для записи файлов CMake.
Введите Вперед.
Удивительным
Статическое связывание
Отсутствие общих библиотек означает, что двоичные файлы работают (почти) везде, включая старые системы. Не нужно мучиться с glibc, libstdc ++ и многими другими проблемами платформы. Нет необходимости компилировать самую старую систему сборки, которую только можно вообразить, просто для того, чтобы получить двоичные файлы, которые будут работать на всех, кроме самых последних целевых систем.
Кроссплатформенность
Go доступен не только для Windows, Mac и Linux, но и для многих других операционных систем, включая Android, BSD и даже «браузер» WebAssembly. И не только для 64-битных Intel и ARM, но и для многих других архитектур.
Он также может компилироваться для тех, кто использует чрезвычайно простой кросс-компилятор, встроенный по умолчанию!
Написали программу для рабочего стола Linux? Запустите его также на своем компьютере с Windows, Raspberry Pi, PowerPC или маршрутизаторе OpenWrt. Просто нужно передать компилятору Go правильные аргументы. Сравните это с «нормальным способом» делать что-то. Невероятно просто!
Вот доказательство, быстро составленное кем-то, имеющим примерно неделю опыта в го, за пару минут:
Все просто, а?
Добро
Сделано опытными специалистами
Просто погуглите авторов Go. 'Достаточно.
Сосредоточьтесь на простоте
Язык Go идет на компромиссы с намеренным акцентом на
- Простота
- Читаемость
- Ремонтопригодность кода с течением времени
- Параллелизм
- Сети
Я мог бы написать параграф о каждом из них, но на Go уже написано достаточно статей по этим темам. Вместо этого давайте перейдем к так себе.
Так себе
Исполняемые размеры
Понятно, что из-за статической привязки исполняемые файлы, созданные Go, будут больше, чем их динамически подключаемые аналоги C / C ++. Тем не менее двоичные файлы Go кажутся немного больше, чем нужно. Положительно, еще есть возможности для оптимизации (как показывает TinyGo). Даже сегодня Go по крайней мере может удалять двоичные файлы по умолчанию и удалять любые строки пути. Он также может запускать что-то вроде upx для двоичных файлов. Одни только эти меры могут сократить количество обрезков жира как минимум на 2/3.
Все еще слишком сложно
В Go есть одна область, которая кажется слишком сложной, а именно способ импорта. Почему политика не может заключаться в том, чтобы всегда использовать относительные пути к файловой системе? (То же самое верно и для C / C ++, где применяется какая-то безумная магия, чтобы узнать пути, в которые входит live, и для Python.) Почему мы должны иметь дело с переменными среды и сложными соглашениями, когда простые относительные пути к файловой системе (относительно файл, содержащий их) в операторах include, которые уменьшили бы сложность?
- Репозиторий Git
- Репозиторий Go
- Пакет Go
- Модуль Go
- Перейти в рабочее пространство
- ГОПАТ
- Поставленный пакет
- Путь импорта
Эти вещи сбивают с толку (во всяком случае, для меня, как для нового пользователя Go), и все они могут / должны быть более или менее одинаковыми, а именно относительные пути файловой системы. Было бы более чем достаточно для моих случаев использования и гораздо менее хрупким.
Даже после прочтения справки, встроенной в команду co, эти концепции не сразу становятся очевидными.
Моя наименее любимая функция: переменная окружения GO111MODULE. Зачем мне это нужно? Я даже не хочу знать! Я хочу, чтобы все «просто работало», и мне не приходилось возиться с такими вещами. Иногда это необходимо, иногда нет, я не в настроении выяснять, когда я должен или не должен его использовать. Это хромой!
И я все еще задаюсь вопросом: следует ли мне зарегистрировать весь свой GOPATH на GitHub?
Уродливый
Отсутствие кроссплатформенного графического интерфейса с интуитивно понятным интерфейсом.
Поскольку команда Go изначально сосредоточилась на серверах, а не на настольных компьютерах, встроенного кроссплатформенного собственного графического интерфейса нет (пока?). Попытка использовать Qt с Go, похоже, требует установки, которая длится вечно.
Бинарные файлы должны работать где угодно, но не
Двоичные файлы, созданные с использованием последних версий Go, категорически отказываются работать на чем-либо ранее, чем macOS 10.10 (то есть на всех версиях Mac OS X, которые все еще были хороши).
Что было бы здорово увидеть?
Мои личные пожелания на будущее Go. Обязательно с моей субъективной точки зрения как человека, который очень заботится о Linux на рабочем столе.
Больше библиотек
Например, я не мог легко найти библиотеки Go для таких задач, как загрузка с использованием протокола zsync, чтение и запись squashfs со всеми типами сжатия, вычисление размера исполняемого файла ELF по его заголовкам, извлечение файлов ZISOFS, проверка записей рабочего стола. Для всего этого доступны библиотеки C / C ++. (Теоретически можно было бы встроить C / C ++ в программы Go, но тогда можно было бы потерять многие из преимуществ, описанных выше.)
Пользовательская среда Linux, полностью основанная на Go
Другими словами, «Go / Linux», а не «GNU / Linux».
Для командной строки это уже здесь: Gokrazy, пользовательская среда на чистом Go для устройств Raspberry Pi 3.
Теперь мне бы очень хотелось увидеть это на рабочем столе. Новое начало. Никакого наследия. Больше никаких проблем с настольной платформой Linux.
Я убежден, что все успешные приложения хотят быть кроссплатформенными, и Go, кажется, отлично подходит для этого. Почему мы еще не видим много настольных приложений на основе Go?
И можем ли мы пойти дальше и создать на Go не только приложения, но и сам рабочий стол?
Для настольного компьютера необходимо решить некоторые дополнительные аспекты:
- Мощный набор инструментов пользовательского интерфейса, который идеально выглядит и ощущается родным, по крайней мере, для Windows, Mac и Linux (Gtk, Qt). Есть https://fyne.io/ и https://gioui.org/ - подходят ли они для работы?
У Fyne много виджетов, но на рабочем столе Xfce (на базе Gtk) он не выглядит родным:
Это примерно так же «родно», как сейчас с Gio:
Строя это с
~ $ env GOOS = windows GOARCH = 386 GO111MODULE = on go build scatter.im/cmd/scatter
а попытка сделать это в Windows 10 просто приводит к:
С Fyne я даже не могу скомпилировать для Windows:
РЕДАКТИРОВАТЬ: Спасибо @andydotxyz за указание на это
@Fyne_io компилируется для Windows из других систем, но когда вы устанавливаете GOOS, вам также понадобится CGO_ENABLED = 1, поскольку компилятор отключает его для кросс-компиляции ...
Но на самом деле все приятные вещи, которые я написал выше о «статической компоновке», похоже, перестают работать, как только вы захотите использовать графический интерфейс:
Wayland? Почему? Есть ли это в CentOS 6? По крайней мере, для этого не нужен совершенно новый glibc, версии 2.4 кажется достаточно.
- Способ встраивания метаданных (например, значков, переводов) в исполняемые файлы (узнайте из того, как ресурсы обрабатываются в Haiku, возможно, используя что-то вроде стандартизированных архивов ar в разделах ELF - кто захочет провести со мной мозговой штурм по этому поводу? )
- Эквивалент Launch Services на Mac (для создания настольной системы, которая меньше отстой - кто захочет провести со мной мозговой штурм по этому поводу?)
Говоря о Haiku, я думаю, что официальная цель сборки Haiku для Go была бы потрясающей.
probono - основатель и ведущий разработчик проекта AppImage, основатель проекта PureDarwin и участник различных проектов с открытым исходным кодом. Он очень заботится о #LinuxUsability на рабочем столе.
