Представлен релиз языка программирования Go 1.13, который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51417
Что-то релизы зачастили
Это специально чтобы новостей на опеннетике было больше. Серёжка он же сам читает опеннет на русском и пытается порадовать ресурс частыми новостями.
> Что-то релизы зачастилиИщут.
Кто? Что? Зачем?
Информативность уровня Andrey Mitrofanov_N0.
> Кто? Что? Зачем?
> Информативность уровня Andrey Mitrofanov_N0.Они там наверху.
Когда найдут, чего ищут, обязательно напишут в релиз-нотесах.Пока -- ищут, говорю же.
Понималка уровня опенета... знаю-знаю.
Вот уже много дет релизы два раза в год. Причём, обычно летний релиз в августе. Так что в этом году они даже припозднились.
Да вроде по плану. У них же плановый цикл: https://github.com/golang/go/wiki/Go-Release-Cycle
После питона и котлина синтаксис выглядит кривым, но хотя бы читабельным в отличии от раста
Он не выглядит кривым,просто в нём мало синтаксического сахара, в отличии от того же котлина и питона. Для тех кто всю жизнь писал на си, го это манна небесная.
Так же было с java пока туда говна в виде синтаксического "сахара" не напихали
> Так же было с java пока туда говна в виде синтаксического "сахара"
> не напихалиС го думаю будет тоже самое, хотя это зависит от настойчивости Роба и его команды противостоять желаниям потребителей этого языка.
А чем сахар не угодил? Обязательно язык должен выглядеть как привет из 70х? Без этого нет чувства элитарности? Между Python, Swift, Kotlin можно прыгать почти почти не ощущая дискомфорта. А тут давайте простыни писать. Ну ради простыней можно Obj-C использовать, там при всем желании не получится компактно.
Тем, что теряется представление о том, что происходит под капотом.
Поддерживаю, необходимые абстракции всегда можно написать самим и держать внутри проекта.
В go нельзя.
можно
нужно by design
Можно. Как работник проекта (коммерческого), бинарь которого приближается к 200MB, заявляю: можно.
> бинарь которого приближается к 200MBПопробуйте собирать с ключиками -ldflags -s.
Я бы не отказался от синтаксического сахара для BigInt
f = f + 2*d вместо new(big.Int).Add(f, new(big.Int).Mul(big.NewInt(2), d))
Всё правильно сделано. Так ты десять раз подумаешь, нужен ли тебе BigInt, прежде чем его использовать, и напишешь на порядок меньше оно-кода.
так можно и до Си дойти, там-то на каждом шаге нужно думать, что делаешьно моднейшие смузихлёбы такой подход не одобряют и всячески поливают, называя выстрелами в ногу
Ну да, чтобы глядя на f = f + 2*d нельзя было сказать что происходит, складываются ли тут числа, матрицы, векторы или черти в ступе.
Эк ты ловко обгадил c++.
А вообще, надо пойти математикам рассказать, как тупо они делают, что для сложения чисел, матриц и векторов используют один и тот же символ.Люди, что у вас в голове? Вы пишете программный продукт, или занимаетесь автофелляцией?
одно другому не мешает!
> Люди, что у вас в голове? Вы пишете программный продукт, или занимаетесь автофелляцией?Это ты, видимо, пишешь программный продукт (или мечтаешь об этом). А люди ещё и поддерживают кодовую базу на протяжении многих лет.
В понятие написания программного продукта входит понятие его поддержки. И именно поэтому намного лучше иметь перегрузку функций по параметру, чем по новой функции для каждого типа аргумента.Например, openGL вынужден был вводить по двадцать функций glVertex с различными суффиксами (2f, 2d, 2fv, 3f, 3d, 3fv, ...), ибо С и нет перегрузки. И это реально задалбывает, каждый раз самому считать количество и типы аргументов. С++ обертка столько нервов экономит, что диву потом даешься.
программирование - это не (только) математика.
ну да, лучше как в Nim - не***ческая гора операторов вида ^@%$!!~= для каждого типа :D
Или в Go нет перегрузки операторов?или ты просто модный смузехлёб, а шутки про C/CPP как раз в моде?
> Или в Go нет перегрузки операторов?Нет.
вот почему мне так нравится питон. там не надо так обгаживаться каждый раз)) и да я хотел было глянуть раст и го, но как глянул на примеры кода.... желание отпало . решил вспомнить с и с++. но вы ребята кричите о достоинствах. для меня возможность использовать простую формулу а+в=с всегда лучше чем вырвиглазный код с кучей функций вложенных в скобки. звиняй в питоне тоже есть похожие вещи, но не до такой обдолбанной степени. после этого код си и питона кажется манной небесной.))
> для меня возможность использовать простую формулу а+в=с всегда лучше чем вырвиглазный код с кучей функций вложенных в скобки.Go как-то более о том, чтобы писать логически правильный код, чем о том, чтобы строчки красиво выглядели. Тут кому что важнее.
А найти в коде объявления f и d, конечно же, нельзя, да.
Что с тобой не так? Там полно этого сахара!
https://rust-lang-nursery.github.io/rust-cookbook/science/ma...
>Для тех кто всю жизнь писал на си, го это манна небесная.Всю жизнь, это два квартала?
Это не манна небесная, это ж ПП с медным тазом.
Укуренная смесь Кобола и Неведломой Фигни.
>Для тех кто всю жизнь писал на си, го это манна небесная.но в гопники идут почему-то исключительно похаписты и джаваскриптеры, что как бы намекает на тысячи мух, которые не могут ошибаться
Не только. Сишники тоже идут.PHP, Ruby, Python, JavaScript (NodeJS) программисты идут за скоростью без большой потери простоты.
С-шники идут за простотой без большой потери скорости. (Я из таких)
C++ и Java программеры стараются не идти. Идут только если место новой работы нравятся.
> в гопники идут почему-то исключительно похаписты и джаваскриптерыОбласть применения у него такая, что больше пересекается с похапе, питоном, нодежс и прочей жабой, нежели с си. Вот и идут в него те, кто в этой области специализируется.
Возможно однажды завезут Готлин: транслятор из сахара в го
Готланд тогда уж)
Не знаю чего пыхтеть давно есть flex/bison хотите всякой херни грамматику сделать можно за пять минут при нужном уровне владения инструментом. Вот только надо ли ?
есть сомнения, что в rust нормальный синтаксис;
вроде использовать никто не заставляет все возможности rust?
есть сомнения, что самых базовых возможностей rust вполне достаточно, чтобы написать большинство программ
А еще можно не страдать и взять нормальный язык, где не только базовые конструкции не будут вызывать кровь из глаз
а какой язык нормальный?
Го это раст здорового человека.
вы серьёзно? а может наоборот?
Круто, а как в го работать без сборщика мусора и при этом руками память не выделять? Я что-то пропустил.
При помощи встроенного пакета unsafe.
> как в го работать без сборщика мусора и при этом руками память не выделять?Пиши так, чтобы использовались только стековые переменные. Про стандартную библиотеку забудь.
Иногда помогает sync.Pool, иногда unsafe, иногда всякие "//go:", но важнее всего: переосмысление кода.
Жаль, что на го нельзя системные библиотеки писать (читай - выпилить GC из рантайма)
Можно его вызывать руками пакет runtime вам в руки.
Но выпилить рантайм из бинарника вообще и вручную управлять памятью конкретного объекта всё равно нельзя.
Не всем нужно писать «системные библиотеки». Большинству нужно херачить стартапы, чтоб и писать быстро, и работало быстро. Go в среднем удовлетворяет обои потребности.
Тогда в чём смысл сравнения Go vs Rust, если Rust как раз про системное программирование? Мы ж не сравниваем трактор и жигули по критериям удобства сидений в салоне?
И что такого системного написано на раст? Только куча хеллоу ворлдов написали и все. Тот же редокс не более чем погремушка.
Системные приложения писать можно (например, в контейнеризации весьма трендово использовать Golang). И писать библиотеки для таких (написанно на Golang) системных приложений можно. Можно ли сказать, что тогда можно писать системные библиотеки?
если точнее после питона все компилируемые языки выглядят... переусложненными что ли? я все смотрю и нигде не могу найти хотя бы проекта с синтаксисом как питон , но компилируемым. видимо писать компилятор для такого синтаксиса мало кому по зубам. а жаль. хотя вот честно когда изучал чистый Си он мне не показался таким сложным. а вот синтаксис раста... я увидел то , что должно сводить этих программистов с ума))) там реально жутко.
> все смотрю и нигде не могу найти хотя бы проекта с синтаксисом как питон ,
> но компилируемым.Есть cython, Nuitka
или
Nim(rod), если не пугает примесь паскальщины, но там автор слишком уж много напихал всего, если на мой вкус.
И вне винды могут быть проблемки в скорости IO – тыкал я его пару лет назад, хотел найти замену небольшим питоноскриптам.Ну или конкретизируйте "синтаксис" - там [в python] на самом деле не так уж и много хорошего. Другими словами – "кривоват", что вылезает в самых неожиданных местах:
>>> type( {} ),type( { () } )(<type 'dict'>, <type 'set'>)
>>> 1, + 2,(1, 2)
>>> (1,) + (2,)(1, 2)
>>> (1,) + 2,Traceback (most recent call last):
File "<input>", line 1, in <module>
(1,) + 2>>> __ = [1,2]; _= range(5);[_ for _ in _ if _ not in __]
[0, 3, 4]
>>> __[1, 2]
Таких "прикольчиков" достаточно.> видимо писать компилятор для такого синтаксиса мало кому по зубам.
На самом деле проблема в "динамизме", т.к. или придется создавать код для всех возможных комбинаций-вариаций типов или же результат компиляции будет делать проверки-касты-диспатчи в рантайме и получится очередная разновидность интерпретатора.
Для таких ЯП эффективны tracing JIT - когда во время выполнения отслеживаются конкретно "на месте" используемые типы и "ветки" кода и только они компилируются в машкод.
Что думаете про синтаксис Haskell и OCaml?
Не пугай пацана, он словей-то таких не слыхивал.
Был такой язык Boo под .Net . Почему-то не особо взлетел
Приведи пример нечитаемого раста?
я не сказал что он нечитаемый. но в нем такие чудеса пишут.... увы пока читаешь до середины уже вылетает из головы , что было вначале. до того код "забойный" порой. нет может кому то нравится, но мне как то не по вкусу. вы можете жевать конечно . это ваш выбор.
Годно, обновляем.
По крайней мере на Go существует некоторое кол-во вменяемых утилит, в отличии от хруста, на котором вообще ничего адекватного не видел (даже некий браузер и то вызывает вопросы).
https://github.com/jwilm/alacritty
есть
https://www.reddit.com/r/rust/comments/cysvjh/what_are_some_.../
90% из которых это переписанный coreutils?Приведи пример проекта хотя бы уровня kubernetes, docker, etcd или prometheus, тогда посмотрим.
> 90% из которых это переписанный coreutils?Напишут компилятор Си -- будут "как GNU". ""RWU"" ! "скоро в кинотеатрах и опенетах"
Написать и забыть каждый дурак сможет, а вот поддерживать десятки лет - не каждый.
> скоро в кинотеатрахДавно уже было: https://www.youtube.com/watch?v=qP3wvX55_gQ
>>будут "как GNU". ""RWU"" !
>> скоро в кинотеатрах
> Давно уже было:Да, отсылка была именно туда. Но теперь же "пора переписывтьс на ржу".... или как-то так... Римейк затмит.
https://github.com/firecracker-microvm/firecracker
https://github.com/intel/cloud-hypervisor
https://github.com/Azure/iotedge/tree/master/edgelet
> Язык достаточно лаконичен, но при этом код легко читается и воспринимается.Почему здесь "но"?
Потому что лаконичный код сложно читается и воспринимается.
потому что perl тоже достаточно лаконичен, но кто бы чё понял и воспринял, кроме бородачей
Для этого нужно знать язык, и в данном случае не какой-то вообще (типа петона), а именно Perl.
для чтения чужого перлокода- совершенно не нужно.
достаточно знания как устроены и с чем едят regex'ы, но оно не перлоспецифичное.собственно, для того его таким и делали.
Давайте ещё вспомним однострочники на perl.
Перлы на перле.
перлом перлу перламутят))))
Что проще понять?i v или integer velocity?
>Добавлена поддержка новых префиксов цифровых литералов для определения двоичных чисел (например, 0b101), восьмеричных (0o377), мнимых (2.71828i) и шестнадцатеричных с плавающей запятой (0x1p-1021), а также обеспечена возможность использования символа "_" для наглядного разделения цифр в больших числах (1_000_000);Еее! Даёшь перл!
Забрать все из перл, а сам перл закрыть.
>мнимых (2.71828i)кто-то реально работает с комплексными числами на сабже?
Почему перл? Это все было в лиспе еще году, эдак, 86м.И снова десятое правило Гринспена работает!
$ clisp[1]> (print 1000000)
1000000
1000000
[2]> (print 1_000_000)*** - SYSTEM::READ-EVAL-PRINT: variable |1_000_000| has no value
Что-то не работает.
> Снято ограничение на использование только беззнаковых счётчиков в операциях сдвига, что позволяет избежать лишних преобразований в тип uint перед использованием операторов "‹‹" и "››";Почему бы им и с операциями сравнения так не сделать? Ну или по крайней мере не впилить автоприведение всех стандартных, возвращающих размеры, функций (len, cap, что там ещё?) к uint?
Потому что в 99% случаев такое сравнение ошибочно.
Почему поделки аля раст и го в каждой новости обзывают «основанным на языке Си» если этот вырвиглаз похож лиш фигурными скобками?
Они компилируемые, а не интерпретируемые и не используют никаких виртуальных машин. Этого достаточно.
В Go сборщик мусора.
>В Go сборщик мусора.Точно мусора? Что-то гошники не самовыпиливаются.
>>В Go сборщик мусора.
>Точно мусора? Что-то гошники не самовыпиливаются.Ой, да ладно то обижаться.
Go - язык и компилятор
разработанный и поддерживаемый транснациональной корпорацией добра,
на свой корпоративный бюджет,
ради своих корпоративных целей - иметь отдачу от инвестиций в сервисы.Основная идея "нам сложно и дорого разрабатывать-сопровождать с++ код, эти умные хипстеры нас задолбали, опять хотят прибавку и бонусы"
Нашли группу идеалистических старперов, те за 5 лет избрели C без указателей.
И синтаксисом от форта. И якобы без malloc.И все, кто не хипстеры с большой зарплатой, сказали
"Слався корпорация Бобра! Ты возмешь всех нас на работу? Правда? Правда-правда?"Правда указатели разработчики быстро вернули, но вколотили в компилятор массу
"чувак, ты тупой, тут должно быть КАПСЛОКОМ, без КАПСЛОКА не соберем"
s/стартаперов/старпёров/s/старпёров/известных своим значительным вкладом в развитие всего компьютерного личностей/
Заманивают сишников.
Не выдет пока не дадут управлять потоками и процессами самостоятельно. Люди привыкшие к власти над ресурсами так просто ее не отдадут =)
Ну может быть правильнее сказать, что основанные на синтаксисе Algol'а? Там правда вместо фигурных скобок begin/end, но это мелочь а не отличие. Они настолько похожи, что можно программно конвертировать C->Pascal и Pascal->C. Что студентота постоянно и проделывала, у студентов постоянно чесались руки написать транслятор.Сравни Algol с Haskell, OCaml, Python, Lisp, и ты поймёшь, что значит _другой_ синтаксис.
> Они настолько похожи, что можно программно конвертировать C->Pascal и Pascal->C. Что студентота постоянно и проделывала, у студентов постоянно чесались руки написать транслятор.Ничего, что у паскаля LL грамматика, а у С - LR?
>> Они настолько похожи, что можно программно конвертировать C->Pascal и Pascal->C. Что студентота постоянно и проделывала, у студентов постоянно чесались руки написать транслятор.
> Ничего, что у паскаля LL грамматика, а у С - LR?Совершенно неважно. Это для писателей парсеров важно, а для человека использующего язык для написания программ -- совершенно фиолетово. Человеческая психика содержит в себе универсальный парсер грамматик, для которого LL не сложнее LR.
>позволяет добиться производительности, сопоставимой с программами на языке СиНе позволяет. С Си может тягаться C++ или Rust, но никак не Go.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Не позволяет.Позволяет.
Оверхед у оптимизированного софта на Go ~10-15% по сравнению с Си (в зависимости от профиля нагрузки).Если так любите синтетику, вот, кушайте:
https://www.techempower.com/benchmarks/#section=data-r18&hw=...А еще есть научная работа по написанию сетевого драйвера на Go:
https://www.net.in.tum.de/fileadmin/bibtex/publications/thes...
Раздел "Benchmarks" вполне подтверждает тезис "добиться производительности, сопоставимой с программами на язике Си".Ссылки на benchmarksgame это моветон.
> Оверхед у оптимизированного софта на Go ~10-15% по сравнению с Си (в
> зависимости от профиля нагрузки).Разница в скорости скомпилированного с различными ключами С может запросто быть более 20% (при том что -Os внезапно обгонит -O2). Так что подумаете, что откуда в тех измерениях такая "точность".
Кто синтетику делает тот её и подгоняет. В одной ссылке подогнано под го, а в другой нет.
Это мои личные наблюдения на прикладной задаче (UDP сервер).
Не претендую на точность, разница может быть и в два раза.Вот в benchmarkgames в одном примере разница с растом в несколько раз, а там unsafe через unsafe интрисинками погоняет, когда гошная версия не использует ни того, ни другого.
В приведенной мной статье тоже больше 15% оверхеда, но вполне сопоставимо.
> Это мои личные наблюдения на прикладной задаче (UDP сервер).То есть основная работа происходит в ядре ОС. Может так оказаться, что интерпретируемый Erlang покажет те же 15% оверхеда.
Оперативку ест.
Как язык со сборкой мусора можно сравнивать с языком без сборки мусора в плане производительности?
Напрямую берут и сравнивают, в чем проблема то? И получают вполне сопоставимые результаты.
> Напрямую берут и сравнивают, в чем проблема то? И получают вполне сопоставимые
> результаты.А то что есть накладные расходы это никак никого не волнует? Или же "спецы бенчмарков" пишут такой код, который не использует динамическую память (и соотвественно сборку мусора), гоняя переменные по стеку?
При правильной организации сборщика мусора (и стратегии выделения памяти) - накладные расходы стремятся к одному проценту.Например, для целого класса диалектов лиспа (я просто в курсе кода) выделение нового объекта делается так: { new_object = ptr; ptr+=size; }, что в ассемблере выливается в одну единственную команду; точно так же, как и выделение объектов _на_стеке_ в языках без СМ.
Далее, при непосредственно сборке мусора дерево объектов разворачивается (линеаризируется), при этом установкой одного бита отмечаются используемые объекты; далее сворачивается назад (с автоматической очисткой бита) и элементарнейшим образом компактифицируется. И пусть это звучит страшно, на деле занимает 10 строк С кода. Ну 15, ладно.
Зато "магическим" образом неиспользуемые объекты никак вообще не затрагиваются, и просто исчезают.
А теперь сравниваем это с выделением объектов на куче в С, например. И, главное, с освождением оных (и процессом объединения "пустих" зон, с кучей трюков как бы этот алгоритм ускорить и т.д. и т.п.)
Отсюда выводы: пусть даже такие языки и проигрывают в скорости непосредственно исполняемого алгоритма, но во многих классах задач выигрывают очень хорошо.
Например, парсинг и обработка текста. Чисто на реаллокациях строк с++ влегкую проигрывает у того же коммон лиспа. Плата - объемы используемой памяти.
Ах да, забыл дописать - реализация маллок содержит более 5000 (пяти тысяч) строк кода. С комментариями, конечно же, но!
Это никак не сравнить с 20 строками кода сборщика мусора.
Что за дичь. Покажи мне в пхп, го, джаве или лбом другом сборщик мусора на 20 строк.
Образовывайся, неуч.
https://gitlab.com/owl-lisp/owl/blob/develop/c/ovm.c#L285Развелось макак, понимаешь.
>При правильной организации сборщика мусора (и стратегии выделения памяти)Угу.
И в конечном итоге будет использоваться аналог malloc()/free() и деревья/таблицы/списки выделения памяти "для правильной организации сборщика мусора" =)
Второе десятилетие вижу идеалистов из школы. Некоторые знатно велосипедят.
Вещи, которые сильно бьют по GC, можно выгрузить в sync.Pool или переосмыслить (переделать так, чтобы не били по GC), а другие вещи -- и хрен с ним. В результате околоручное управление памятью производится в 5% кода, а GC жрёт лишь 1% CPU.
Ну хорошо, в лиспе, а как это к Го относится и к другим языкам? Никто же из них не реализовал подобную модель сборки мусора.
Ну я, как бы, не утверждал что они реализовали.
Я просто указал, что в некоторых задачах сборщик мусора может быть существенно эффективнее.
> И пусть это звучит страшно, на деле занимает 10 строк С кода. Ну 15, ладно.А дотнетчики не догадались, что можно за 15 строк сделать...
https://raw.githubusercontent.com/dotnet/coreclr/master/src/...
Это вопросы к МС. Они, помнится, и ОС умудрились на 15 гигов раздуть.
Оно бы все неплохо, но вот за такие ошибки "var1 declared and not used" с дальнейшей остановкой компиляции хочется руки на разработчиков наложить. :D Это мешает отладке настолько, что порой проще на Python прототип написать, а потом уже готовое переложить на Go. Поэтому про "легкость написания" разработчики малость загнули.
Не правильно ты дядя Федор программы отлаживаешь. А так это спасает от говнокода. Да и чтение документации и конкретно про символ "_" сильно помогает.
Я знаю про символ нижнего подчеркивания. И актуален он только тогда, когда объявляется две или больше переменных. А одну можно просто закомментировать, символ нижнего подчеркивания в этом случае не нужен.
Проблема возникает тогда, когда в уже написанной функции выявляется ошибка. И порой проще отыскать ее закомментировав какой-то кусок кода. И вот тут начинаются сюрпризы с переменными объявленными выше. Надо лазить по коду, комментировать их или нижнеподчеркивать. Не исключено, что по нескольку раз.Чтобы убрать неиспользуемые переменные, хватило бы обыкновенных предупреждений. И таким образом от говнокода это спасает только в том случае, если программист предупреждения игнорирует. То есть очевидно, что в гугле как раз такие программисты, коль скоро потребовались такие меры.
Кстати, в том-же Python, в Emacs, эти самые неиспользуемые переменные легко высвечивает flycheck. И они совершенно элементарно удаляются, когда на самом деле не нужны.
> в уже написанной функции выявляется ошибка. И порой проще отыскать ее закомментировав какой-то кусок кода.Научись пользоваться отладчиком.
>Научись пользоваться отладчиком.Отладчик используется в последнюю очередь, при сложных задачах. Так как время отнимает больше, чем что либо еще. Либо при откровенном говнокоде, начинающими. На кой он мне сдался, когда то же самое можно сделать в Python, без всяких отладчиков. О чем я и написал выше.
> проще отыскать ее закомментировав какой-то кусок кодаТы не совсем понял предыдущего анонима. Была функция:
func some() {
a := 0fmt.Print(a)
}Если закомментировать печать, то получим ошибку неиспользуемой переменной. Но есть финт ушами:
func some() {
a := 0_ = a
//fmt.Print(a)
}Но в целом, я с твоими претензиями согласен - можно было бы и помягче. Варнинги, не гошный путь, слишком демократично. Но можно было выводить варнинги в "go run", и ошибку при "go build".
Очень интересно читать людей которые не осилили даже "An introduction to programming in Go".
Вы хоть понимаете какой вы бред несете с точки зрения Golang разработчика ?
>Очень интересно читать людей которые не осилили даже "An introduction to programming in Go".Очень неинтересно читать людей, которые осилили только "An introduction to programming in Go".
Особенно если ты уже 30 лет говнокодишь и не писал разве что на брейнфаке. Хотя стоп, и на брейнфаке ты тоже писал..
И что, прям очень мешает, что на го нельзя, как на брейнфаке? Беда…
Хотя погоди! Вакансию брейнфак-кодера поискать не пробовал?
Не как на брейнфаке, а так же легко как на С, например. Ну или каком-нибудь питоне, на крайняк.
> Оно бы все неплохо, но вот за такие ошибки "var1 declared and not used"И что, таки, не настраивается?
>И что, таки, не настраивается?Если знаете как, то подскажите? Я такой возможности не нашел.
Полистал стаковерфлоу. Я вас обрадовать ничем не могу.
> И что, таки, не настраивается?Нет, это go-way. Есть только один путь, или привыкай, или отваливай.
Звучит очень отталкивающе. Надеюсь, вы это не от себя
Хорошо бы опцию компилятору добавить, чтоб не ругался.
А что, исходников нет?
> А что, исходников нет?Так исходники, небось, на Го? :)
go нужен...был в 1980х, но сейчас уже есть современный C++, в C++ уже давно есть умные указатели, и эти умные указатели решают проблемы с памятью и с многопоточностью
Но есть одна проблема. Макаке с++ дать нельзя - она просто не сможет на нем писать. А содержать большой штат умных программистов гуглу дороговато. Вот они и решили лучше потратить часть денежек на простое подмножество с++ (завернув его в простую понятную обертку) и загнав "программиста" в жесточайшие рамки с расстрелом за любой шаг влево или вправо.
Зато теперь можно нанимать тысячу макак по цене одного программиста.
и это при том, что сам же гугл разрабатывает fuchsia os на c++, вроде на c++17
Ага, при этом разработчик фуксии просит автора растовских крейтов уменьшить размер бинарей, а то в фуксию не влезают.
Откуда столько злобы? Уволили за профнепригодность из го?
У макаки всегда - если критика, то либо завидуют, либо просто злятся.Обычная констатация факта, гражданин. Не более и не менее.
C++ просто чудовищно раздут, даже Страуструп уже перестал писать свою книгу потому что просто невозможно уже всё описать в одном томе. А комитет не собирается останавливаться, скоро C++20.
> C++ просто чудовищно раздут, даже Страуструп уже перестал писать свою книгу потому
> что просто невозможно уже всё описать в одном томе. А комитет
> не собирается останавливаться, скоро C++20.Поэтому лучше начинать использовать Игого. Сомнительно, что ГУЛАГель допустит разбухания языка в ближайшие годы, пока есть кому заниматься.
>C++ просто чудовищно раздут
>всё описать в одном томеДа ну нафик. Много пафоса.
https://en.cppreference.com/w/
http://www.cplusplus.com/Там описания базовых классов и шаблонов.
vector, map, set, queue, list, array, iostream, tuple, regex, chrono, shared_ptr.Все это же самое велосипедят в golang, только через опу и расово верно.
Смотрим go проекты. В более-менее сложном проекте один хрен
10500 модулей, насосаных из гитхаба, и все одно черт ногу сломит где и что.Смотришь на это великолепие, манной кашей по стенам тонким слоем,
и думаешь: "лучше бы они это на С со структурами написали"И универсальное: Никто не заставляет писать замороченный код там, где можно писать просто и архитектурно продуманно.
> Там описания базовых классов и шаблонов.Сам язык раздут, а не стандартная библиотека. В ней-то, как раз, многих базовых вещей до сих пор не хватает (особенно если сравнить с гошной).
А что лучше, Go или Rust? Думаю, чтобы новое по-изучать.
> А что лучше, Go или Rust?Что лучше, помидор, или карандаш? Сравнивать имеет смысл только в контексте решаемых задач.
> Что лучше, помидор, или карандаш?Помидор.
Ух ты, неуместные сравнения в треде! Я в деле. Как вам такое: "Раст это как соплянка, а ГО - как пижамка"?
Ну если вы сейчас на C++ пишите, то Rust. А если нет - Go. Так и польза будет и работа.
Раст конечно. На нём можно сделать что угодно, от эмбеддед до десктопного гуя. Го - уже круг задач, из-за сборщика мусора. Ну плюс го очень ограниченный, для мазохистов.
Делать может и можно, но на расте не сделано ничего. Нет ни одного готового к применению продукта написанного на расте. Даже редокс не юзабелен. Можно написать еще один хеллоу ворлд и успокоится.
По минимальным версиям операционок очень проблемно.Это тогда не язык для серьёзного софта. Кроме бизнес сирвисочков на годик и выкинуть через полтора.
> По минимальным версиям операционок очень проблемно.
> Это тогда не язык для серьёзного софта. Кроме бизнес сирвисочков на годик
> и выкинуть через полтора.Верно. Из-за такого подхода Игого не представляет интереса в долгосрочной перспективе.