Комментарии 41
В быстро развивающемся мире разработки программного обеспечения язык Go является оптимальным выбором для проектов любого масштаба и сложности.
Очень спорное утверждение. Для написания сложной бизнес логики Java/C# куда лучше подходят.
На самом деле для написания сложной бизнес логики по хорошему просто нужен человек, который умеет качественно и надёжно писать код, а также правильно проектировать эту логику. Язык же выбирается исходя немного из других параметров: скорость разработки, производительность языка, количество и компетентность людей в штате знающих определённый язык, как этот язык поддерживается,тип типизации и многое другое. К примеру, если для какого-то приложения характерно множество io-bound задач, то go,java,rust,c(++/#) не сильно выиграют по сравнению с js,python и тд. Другой пример, приложению характерны cpu-bound задачи с возможностью их распараллелить - тут уже победа будет за go,rust и тд. Но это касается средне-крупных компаний, в более маленьких компаниях зачастую не используются 10 разных языков, поэтому и выбирать не из чего.
Ну и плюс, редко требуется писать с нуля всё приложение
Безусловно, грамотный специалист и на С поддерживаемый код напишет. Просто вопрос, что язык должен помогать, а не мешать решать поставленную задачу
На самом деле go отлично подходит для сложной бизнес логики, как и С, Java, Rust. Чего только стоит возможность легко превращать синхронный код в асинхронный(Правда это дает возможность по неопытности выстрелить себе в ногу датарейсами, дедлоками, лайфлоками и прочими интересными вещами). Есть и нейтральные моменты, обработка ошибок, хотя она позволяет не пропускать обработку ошибок, но и прокидывать их по стеку вызова при необходимости не очень приятно. Из неприятных моментов большое количество бойлерплейта.
Для работы с большим числом разных данных лучше подошел бы python к примеру, для кроссплатформенности я бы до сих пор предпочел Java и тд.
В любом случае языки приходят и уходят, это просто инструмент, любой разработчик, начиная наверное с мидла, при необходимости может поменять за 1-2 месяца яп, естественно с небольшой потерей грейда, но это быстро восполняется(ну и с условного python, js или php переходить на go/c/c++/c#/java/rust больнее, чем наоборот).
Главное не доводить до состояния, под названием "когда у тебя в руках молоток все вокруг превращается в гвозди".
Очень спорное утверждение про Java/C#. Может для бизнес логики больше подходит 1с? Ведь именно в конфигурациях 1с работают сотни тысяч организаций по всей России.
Для сложной лучше Haskell =)
Действительно, давайте выкинем кобольное легаси пятидесятилетней давности и перепишем всю мировую банковскую систему на го
Зачем другие языки, если есть Go?
Контр вопрос - зачем Go, если есть Rust и другие языки?
Go по сравнению с C++/Rust нужен для быстрого изучения, единообразного кода, быстрой компиляции и отсутствия заморочек с владением памятью. Создатели довольно неплохо описали, какие проблемы C++ они пытались решить. Я б сказал, это у них получилось.
Но, как я написал в другом комменте, в Rust гораздо сильнее типы и он мне больше нравится. Ради них приходится просто мириться с лишними заморочками с владением. Я пишу не настолько низкоуровневые вещи, чтобы они реально требовались и наличие GC/рантайма было проблемой
Я не уверен, что можно просто взять и добавить GC в раст. Его система владения ещё предотвращает ошибки связанные с потоками. Не хотелось бы отказываться от этого
Взять и добавить можно. Естественно, из-за borrow checker там позволено меньше мутации, чем в типичных GC языках, но я только за. Проблема таких библиотечных решений в том, что они добавляют очень много синтаксического шума. Условно, Gc<GcCell<T>> вместо T. И то же самое со стандартными умными указателями типа Rc и так далее. Такие типы в раст коде как раз многих отпугивают от языка. Было бы интересно посмотреть, каким был бы раст, если бы все объекты были просто garbage collected T (всё ещё с контролируемой мутабельностью), а RAII не было. По сути, это уже почти Haskell, но с тонной синтаксического сахара для ST
заголовок конечно отвратительный холиварный - не нужон это ваш сисярп/жаба/змейсо-итыпы. ну-ну, с нарочным отсутствием многих привычных концепций, с инопланетным синтаксисом и другими особенностями, вот прям всё в печку. и он даже не мультипарадигменный, не мультиплатформенный не многоцелевой (вот приведу в пример свой любимый Котлин - пиши хочешь в ооп-стиле, в функциональном, хоть в процедурном, и компиляция и в jvm-байткод, и в js, и в натив - вот это хорошая заявка), ну нет, ну не захватит он (виртуальный) мир.
нет, я не спорю, язык неплох, и много кому зашёл. но пожалуйста, не надо писать такие провокационные заголовки...
> nil в 2023
> нет sum types
> нет first-class tuples
> нет контроля мутабельности
> гонки горутин
> этот код возвращает err в рантайме, а не ошибку компиляции:
var num int
fmt.Print("Enter an int: ")
_, err := fmt.Scanln(num) // Тут должно быть &num
if err != nil {
fmt.Println("Error: ", err)
} else {
fmt.Println("You've entered: ", num)
}
Язык вроде с типами, но с очень слабыми. Как бы я хотел Rust, но со сборкой мусора...
Попробуйте Ocaml или Haskell
В случае когда в rust нет gc, команду на хаскеле не собрать, ява ест слишком много, undefined is not a function in 2023...
Остаётся только go
Haskell пробовал, тоже очень нравится. Rust выделяется превосходным тулингом и удобством написания контролируемой императивщины. Я уже в другом комменте написал про Rust с GC:
По сути, это уже почти Haskell, но с тонной синтаксического сахара для ST
Ну и сейчас понял ещё, что без контроля IO. Для кого-то это плюс, для кого-то минус.
А я пересел с Си на Хаскель. Использую как и Си для микроконтролеров. Оч нравится!
Было бы интересно статью про это, как контролируете потребление памяти и т.п. Не знаю конечно, насколько она оправдана. Может там тот же подход, что и везде. Про space leaks уже много написано
Потребление памяти – статика. Использую хаскель как макро-язык на стероидах для си. Использую фреймворк https://github.com/GaloisInc/ivory.
> этот код возвращает err в рантайме, а не ошибку компиляции:
Может я что-то не понимаю, но разве в каком-то языке возможно на подобное получать ошибку компиляции, а не ошибку в рантайме? Ведь мы же на этапе компиляции не знаем, что введёт пользователь и окажется ли введённая им строка целым числом.
Там проблема в другом. Функция fmt.Scanln() принимает any, т.е может принять любой тип, а по факту сама функция хочет получить указатель на переменную, в которую нужно будет положить значение. Из-за того, что мы передаем не указатель, мы и получаем ошибку (type not a pointer) в рантайме, а компилятор видит, что в any кидают любой тип и его это устраивает.
rust
Проблема не в том, что введёт пользователь. Scanln возвращает err всегда. Сразу же, не дожидаясь ввода. Можете запустить на Go Playground и посмотреть
Однако Go не лишён своих ограничений. Отсутствие генериков <...>
Вы из какого года статью писали?
Например, если в GCC использовать флаг -Wall (который включает все предупреждения), то среди множества других будет выдано предупреждение следующего вида: warning: unused variable 'a' [-Wunused-variable]. Но кто же это включает по умолчанию?
Любой нормальный программист?
На всех проектах, в которых я участвовал, неиспользуемая переменная приводила даже не к предупреждению, а к ошибке компиляции. -Wall -Wextra -Werror в помощь.
Из графика видно, что скорость компиляции в Go значительно выше, чем во многих из этих языков, что ещё больше подчеркивает его эффективность.
И что же там видно из графика? Все же ровно наоборот, в оригинальном сравнении это явно указано
Для одновременного выполнения различных задач требуется несколько процессоров.
Спасибо за сведения, а то вдруг (shit happens) меня бы занесло на Ваши курсы. Про то, что видно из графика, выше уже написали...
По популярности он даже обогнал Swift
При столь специфическом понимании популярности, что хоть отдельную статью пиши. Попытка гуглить говорит - обычно Swift болтается в конце списка, а Go в нём отсутствует.
Поскольку разработчики продолжают искать эффективные и производительные инструменты
Раз продолжают искать, значит не находят пока. С другой стороны, какое языкам дело до разработчиков с их исканиями? А вот то, что корпорации продолжают искать такой язык, чтобы много ума не требовал, так дешевле, и свободы не особо давал, так дисциплинированнее, влияет ещё как.
в других языках кроме него (цикла for) есть масса подвидов: while, do/while, until, repeat, и достаточно сложно не запутаться во всём этом разнообразии.
Детский лепет какой-то. Вы, когда кушаете, ложкой-то в рот попадаете? Не дай бог запутаться.
C++ (подключаем стороннюю библиотеку Boost.Beast):
В C++ нет встроенного способа создания HTTP-серверов, поэтому нам необходимо использовать сторонние библиотеки, например такие, как Boost.Beast. В результате код становится намного сложнее.
Ни в каком языке нет "встроенного способа создания HTTP сервера". Везде надо "подключать стороннюю библиотеку". То, что в Go такая библиотека включена в стандартный набор - просто спасибо разработчикам языка. Надо подключать что-то более лаконичное и специализированное, чем Boost:
#include <httplib.h>
int main(void)
{
using namespace httplib;
Server svr;
svr.Get("/hi", [](const Request& req, Response& res) {
res.set_content("Hello World!", "text/plain");
});
svr.listen("localhost", 1234);
}Вы в Вашем замечательном, не спорю, Go попробуйте REST API сервер с JSON сделать...
С++ точно так же, почти без бубнов, собирается под все современные платформы.
В Go чтобы собрать под другую OS, и архитектуру достаточно
GOOS=win GOARCH=amd64
и это будет также под любой платформой и архитектурой где запускается GO
А в с++ на арм маке насколько без бубнов можно сделать кросс компиляцию в винду? (мне правда интересно)?
К сожалению M1 под рукой нет проверить, понимаю смысл вопроса. Но это скорее проблема Apple, а не компиляторов.
Под Intel, естественно, Mingw должен все собрать. Конечно в реальности далеко не все. Надеюсь старшие товарищи, кто каждый день кросс-компилирует, ответят более содержательно.
Я согласен, что более молодой Go лучше вписывается в современные реалии, чем неповоротливый монстр C++.
Зачем GO если есть другие языки
Считать в 2023-м CMS-сборщик преимуществом - это странно. Например в Java сборщик Concurrent Mark Sweep появился в 2002-м, а в 2017-м признан устаревшим. Причём в Go ещё и неуплотняющая его версия, что ведёт к неоптимальному использованию памяти и исключает долговременную работу приложения без регулярного перезапуска.
Да и Escape Analysis тоже не эксклюзив для Go, в уже упомянутой ранее Java он тоже есть.
Ну а простота Go не той породы, которая делает язык гибким и изящным, а той, которая делает его примитивным и ограниченным.
А можете сравнить GO с Luajit?
Почему язык Go популярен