Comments 55
Использование словам "класс" — это наследство от java, так как первое знакомство, он местами проскакивает. На самом деле да, тут используются структуры, что непривычно по началу.
Проблема в том, что в go привычных классов и вместо наследывания предлагают встраивание (например, тут и тут). Это позволяет некоторым, например мне, считать, что Golang больше крутой мейнстримный процедурный язык, который был нужен многим, потому что у них был только C, но подходящий для узкого круга задач.
А отсутствие шаблонных типов превращает работу там, где они нужны в мешанину из interface{}. Хотя вот в go 2.0 вроде они будут.
del
(хотя логично, docker на нем написан)
А docker-compose написал на python, хотя причин я не понимаю до сих пор)
В треугольнике винда-линукс-андроид?
Java. Вы, конечно, можете попробовать делать это на Go, но я бы не советовал. И они пока тоже.
Вот наглядный пример.
Ну я вот D не знаю совершенно, а код справа вполне понятен.
Вот только Ruby я знаю ещё меньше чем D, а код всё равно понятен. (:
Так-то соглашусь, что если у человека есть опыт исключительно С, то да, Go будет очевидно проще. Но как по мне, изучать свой инструмент всё равно надо, а дальше можно бесконечно спорить и кривой обучения и пороге входа.
Не знаю причем тут магия, но то что Вы видите в строке 7, называется Uniform Function Call Syntax, который позволяет писать функции не по-отдельности, а через точку, в таком случае первый аргумент функции будет являться тем объектом, к которому Вы эту функцию присовокупили (иными словами foo(a); это аналог a.foo();): https://tour.dlang.org/tour/ru/gems/uniform-function-call-syntax-ufcs
И эта особенность как раз сильно сокращает время на чтение и понимание кода. А также дает некоторые интересные возможности.
Go не для GUI.
Но выглядит пока не очень. JNI и чистый OpenGL. Ждем GUI-libs
2. Нет, генерация кода html не является GUI
А gui на вэб-формах html/css/js уже не gui? Пример реализации можно увидеть в syncthing.
Но ведь куча крупного серверного софта написана на го?
2 из 3 это k8s и docker? Docker раньше был одним процессом (плюс commandline клиент), его разделили из-за необходимости масштабирования компонентов независимо друг от друга. Рантайм отдельно, управление отдельно. Благодаря такому разделению в нем теперь есть такая вещь как live restart (перезапуск управляющего демона без перезапуска контейнеров). Звучит как хорошая причина для разделения?
На тему k8s, я хотел бы услышать ваше мнение за счет чего можно сократить количество демонов. Но независимо от их числа, вы прямо так считаете тот же kubelet "небольшим"?
Для не слишком навороченных программ под винду Go вполне себе годится благодаря github.com/lxn/walk — качественная тонкая обёртка для стандартных win api контролов в декларативном стиле.
я бы тоже взял С++, поскольку возится с не поддерживаемыми биндингами нет ни какого желания
В качестве nextget плюсов по-моему пока только Rust выступает. Все-таки у обоих D и Go есть GC. Поэтому если вам не нужна zero cost abstraction, то стоит задуматься может подойдут не компилируемые в native языки, типа Java, C# и т.д.
Не-компилируемые хотят рантайм. Например, была задачка — собрать тонкий Node.JS сервис из толстой нативной либы и засунуть в докер. Подружить этот зоопарк, чтобы собирался одной кнопкой — нетривиально, хоть и решаемо. А потом корректно проставить всё в контейнер и вычистить мусор. Куда проще скрутить и запаковать монолитный бинарь.
В качестве "некстгена плюсов" однозначно D, но к сожалению в текущей реализации на 100% плюсы он заменить не может, если конечно не писать без использования сборщика мусора. Хоть это и возможно, но все равно без GC теряются дефолтные фишки языка такие ассоциативные массивы, делегаты и т.д. (в будущем возможно будут какие-то изменения касательно отвязки библиотеки от GC). В принципе и для этих примитивов есть замена без GC, если понадобится.
Сейчас D напоминает скорее нечто среднее между C# и Java, но только не требующее никаких виртуальных машин и рантаймов, т.к. исполняемый файл можно статически слинковать со всеми необходимыми библиотеками.
Для большинства прикладных задач сборщик мусора ничем не мешает и даже очень сильно помогает.
Ну и плюс если хочется совсем низкий уровень или откат к C, есть режим Better-C.
Так что если не пишите какие-то супербыстрые сетевые сервисы, то из этих двух однозначно D (хотя для сетевых сервисов в D есть фреймворк vibe.d)
В итоге язык больше обрубок какой-то напоминает. Про серьезные проекты на нем читать вообще смешно. Ну да. Запилили на нем REST сервис который JSON отдает. Замечательно! Просто прорыв. А что дальше? Язык не поддерживает элементарные обобщения и обработку данных на нем вести практически невозможно. В итоге кроме как JSON-ом плеваться ничего другого не остается.
В этом и смысл. Поэтому большинство любителей Golang — автоматически становятся любителями микросервисов, потому что большие монолиты на нем не напишешь. А микросервисы, без всего этого ООП и боли отлично пишутся.
Раньше, если вам нужен был микросервис, у вас был только Python или C++, не очень крутой выбор. А тут теперь и Golang докинули.
обработку данных на нем вести практически невозможно
а можно примеры, пожалуйста, не могу представить такие данные, что не обработать в Go
кроме как JSON-ом плеваться ничего другого не остается
так сейчас время такое и большинство бизнес-процессов вокруг этого построено, разве нет?
>так сейчас время такое и большинство бизнес-процессов вокруг этого построено, разве нет?
Сейчас время BigData и очень часто на сервере нужно что-то посчитать и обработать прежде чем отдать.
Я могу такой код еще 6 раз скопировать, и он будет еще больше казаться. Сравненип кода абсолютно неверное, нет использования интерфейсов, например.
Слева у вас код дублируется аж четыре раза. Без этого ненужного дублирования код сокращается ровно до 10 строк, что не так уж и много.
for _,y:=range []int{1,2,3,4,5} {x+=y}
fnt.Println(x)
В одну строку
Да к примеру простое суммирование превращается в ад. Аж 40 строк. Нафига спрашивается?
автор того сниппета с сайта dlang очевидно болен, не думаю, что здесь есть что обсуждать
Сейчас время BigData и очень часто на сервере нужно что-то посчитать и обработать прежде чем отдать
вот в этом гошечке просто нет равных ибо идеоматичный код:
1. автоматически масштабируется на любое количество доступных ядер (будь их хоть 2, хоть 64)
2. практически не блокируется
3. в принципе быстро работает: даже при одном потоке Go, в среднем, быстрее Java и NodeJS (популярный нынче выбор для бэкендов) и во много раз (до 10) быстрее Python3.
4. имеет небольшое и прогнозируемое потребление памяти
в принципе быстро работает: даже при одном потоке Go, в среднем, быстрее Java и NodeJS (популярный нынче выбор для бэкендов) и во много раз (до 10) быстрее Python3.
Есть сайт для сравнения скорости разных платформ: https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
Примечательно, что если кто-то считает, что решение неэффективно — он всегда может это исправить.
Итак, судя по этому сравнению, на всех типичных задачах Go медленнее, чем Java или C++ .
Отсюда вопрос: а на каких бенчмарках Python оказался медленнее в 10 раз, чем Go? На каких бенчамарках Java оказалась медленнее, чем Go?
Сейчас время BigData и очень часто на сервере нужно что-то посчитать и обработать прежде чем отдать.
в бигдате есть явно разделённые этапы, типично это
- Выделение и преобразование данных
- Скармливание данных в хранилище (Clickhouse, Vertica, Prometheus, очередной уродец из Java-стэка для любителей вёдер с болтами и т.п.)
- Обработка данных средствами хранилища (какие-нибудь маркетологическеие метрики в Кликхаусе-Вертике, метрики для мониторинга в Прометеусе и т.п.)
Для выделения и преобразования данных дженерики не нужны. Для скармливания тоже. Обработка — тот же самый прометеус написан на Go. Дженерики могут быть как-то полезны только в простейших случаях.
1. на выходе исполняемый файл не требующий с потребителя «скачать еще сто мегабайт неведомой фигни и проинсталлировать обеспечив что бы уже не стояла неведомая фигня в путях»
2. кросс-компиляция осуществляется без плясок с бубном, всеголишь настройкой пары параметров и под линуксом вполне билдятся версии под винду и мак
Go, go, go… Первые впечатления