Родословная или Should I Go?
Last updated
Was this helpful?
Last updated
Was this helpful?
Размышляя о рождении языка, мне на ум всегда приходят таблицы Менделя. Да-да, те самые, которые о наследовании. Биологическом. И не мудрено, ибо все явления во вселенной так или иначе , покуда движется стрела времени, подчинены законам эволюции. Хотите рисунков? Их есть у меня.
На исходе века Взял и ниспроверг Злого человека Добрый человек. Из гранатомета Шлёп его, козла! Стало быть, добро-то Посильнее зла...
Как вы уже поняли, рассматриваемый нами язык Go оформился к 2009 году в недрах Корпорации Добра. Стараниями таких корифеев Google как Роб Пайк и Кен Томпсон. Да что там Google, оба персонажа - звёзды первой величины в мировой истории IT, приложившие руку к созданию C, Unix way, и прочих фундаментальных сущностей.
Судя по представленной выше родословной:
Язык Go изрядно обогатился наследием ортодоксального С (вплоть до прямой возможности вызова C кода). Явные C-like корни имеют функции ввода-вывода и их спецификаторы формата, именуемые в Go термином "verbs".
Также Go неплохо покормился на ниве SCP (Communicating Sequential Processes), что есть по сути не столько язык программирования, сколько алгебраический аппарат исчисления процессов, нашедший достаточно широкое применение в современной вычислительной науке в связи с большим распространением параллельных систем. К слову, в данном аспекте язык Gо на уровне парадигмы имеет сродство с Erlang.
И, наконец, отметим влияние ветки Паскаля и его производных. К худу это или к добру, автор судить не возьмётся.
Говоря в общем, Go разрабатывался как попытка замены языка С/С++ для решения реальных проблем, возникающих при разработке программного обеспечения в Google. Как "язык С XXI века", с непревзойдённой поддержкой кроссплатформенности, механизмом сборки мусора, встроенными простыми и ясными средствами распараллеливания процессов и создания коммуникационных каналов для общения и синхронизации между резидентными модулями.
А теперь предлагаю восхититься кроссплатформенными возможностями этого языка:
Go GOOS and GOARCH (bold values - работает "из коробки")
A list of valid GOOS values:
android
darwin
dragonfly
freebsd
linux
nacl
netbsd
openbsd
plan9
solaris
windows
zos
A list of valid GOARCH values:
386
amd64
amd64p32
arm
armbe
arm64
arm64be
ppc64
ppc64le
mips
mipsle
mips64
mips64le
mips64p32
mips64p32le
ppc
s390
s390x
sparc
sparc64
A list of valid 32-bit GOARCH values:
386
amd64p32
arm
armbe
mips
mipsle
mips64p32
mips64p32le
ppc
s390
sparc
amd64
arm64
arm64be
ppc64
ppc64le
mips64
mips64le
s390x
sparc64
darwin/386
darwin/amd64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/ppc64
linux/ppc64le
linux/mips
linux/mipsle
linux/mips64
linux/mips64le
linux/s390x
nacl/386
nacl/amd64p32
nacl/arm
netbsd/386
netbsd/amd64
netbsd/arm
openbsd/386
openbsd/amd64
openbsd/arm
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64
go
out of the boxdarwin/386
freebsd/386
freebsd/arm
linux/386
linux/arm
linux/mips
linux/mipsle
nacl/386
nacl/amd64p32
nacl/arm
netbsd/386
netbsd/arm
openbsd/386
openbsd/arm
plan9/386
plan9/arm
windows/386
go
out of the boxdarwin/amd64
dragonfly/amd64
freebsd/amd64
linux/amd64
linux/arm64
linux/ppc64
linux/ppc64le
linux/mips64
linux/mips64le
linux/s390x
netbsd/amd64
openbsd/amd64
plan9/amd64
solaris/amd64
windows/amd64
Впечатляет, неправда ли? Добавлю к этому, что зачастую для того, чтобы собрать проект под различные системы и архитектуры вовсе не требуется доработка кода, либо такая доработка может быть минимальной и реализовываться путём ограниченного использования операторов ветвления внутри кода проекта. Это же, с определёнными оговорками, касается и использования некоторых приёмов защиты бинарного кода, о чём мы, возможно, поговорим в своё время. Существуют также способы собрать приложение как нативную службу Windows.
Итак, если вы бэкэнд разработчик, и ваше стремление - с разрабатывать кроссплатформенные, легковесные, высоконагруженные и многопоточные приложения и делать это с лёгкостью - то Go ваш язык выбора. Возможности интегарции с C/C++ и Java не окажутся лишними. Единственной утратой, пожалуй, окажется затруднение работать с системными "сиплюсатыми" API, по крайней мере посредством стандартных пакетов.