Представлен релиз языка программирования Go 1.17, который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55647
> сочетающее высокую производительность компилируемых языковс GC? хм
А куда ты так торопишься? Твой Хеллоу Ворлд без GC лучше не станет.
я топовый программист, я востребован и получаю много кэша, и я отвечаю за свои слова: GC это УГ; попомни их, смузибой
Школу сначала закончи, поповый)
Чушь написал. Ещё в 90х годах проводились исследования, которые наглядно показали, что даже на малых объёмах памяти СМ не уступает рукам, а на больших объёмах -- имеет откровенный выигрыш, видимый невооружённым глазом. МС с этим утверждением согласна, Оракл согласен, Гугель согласен, но ты -- крупный диванный шпециалист имеешь своё мнение с особенностями, угу.
Конечно, правда с 90-х годов так и не написали ни одного сопоставимого приложения с GC которое бы было быстрее аналогичного без него. А вот аналогов софта с GC, который в последствии был переписал на С\С++ и другие языки без GC полно, и в подавляющем большинстве он оказывается быстрее, намного быстрее.
Любое приложение с множеством (ре)аллокаций. Сотни тысяч их, этих приложений.Обработка тех же списков, графов, деревьев. Если вам надо освободить сто тысяч мелких объектов просто потому, что они уже не нужны, на free займет десятки секунд, против одной-двух миллисекунд с gc.
Именно поэтому в С++ были задизайнены кастомные аллокаторы, чтобы в отличие от глупых анонимов, профессионалы могли встраивать gc в язык без gc.
Лол, што?! Поехавший что-ли?! Уж точно не реди GC это сделали, а для оптимизаций работы с памятью
GC и есть один из видов оптимизации работы с памятью, молодой человек.
Вообще-то нет. GC это способ для бизнеса использовать НИЗКОквалифицированных программистов, которые забывают освобождать память и у бизнеса из-за этого убытки и проблемы.Т.е. GC - это памперсы. Есть определённая группа лиц которые в силу возраста (старые, совсем маленькие) или психических отклонений срё..ся и ссы..ся. Подгузники им облегчают существование в социуме. Программисты, не способные удержать в голове более менее сложную логику, так же нуждаются в аналогичных "памперсах", которые зачистят за них то, что они наделали.
Других проблем GC не решает. И, тем более, он ничего не ускоряет. На Хабре полно историй разной степени эпичности "как мужики с GC боролись". Вплоть до отключения (если язык позволяет) и перезапуска процесса, ибо так производительнее.
Забавно наблюдать людей, топящих за GC, но не понимающих что это такое и зачем это нужно. Вы же не кричите налево и направо "Вам нужны памперсы! В неспокойное время живём - вы же можете обос..ся!"
Ни разу на реальных проектах анонимы опеннета так и не смогли продемонстрировать ВЫСОКОквалифицированных специалистов которые освобождать память не забывают.Может быть вы станете первым.
кастомные аллокаторы это не GC
Два болвана сразу - неплохой улов.
а че сразу на личности переходите? ГЦ не аллокатор, вам сказали.
минусаторы не вкурсе, что ГЦ не занимается выделением памяти :)хотя в той де википедии в определении написанно "одна из форм автоматического управления памятью.", а далее пишут "периодически освобождает память, удаляя объекты, которые уже не будут востребованы приложениями."
управлять памятью это - выделить, освободить.
сборка мусора (ГЦ) - освободить.и они не равны.
Капитан Очевидность, спасибо.Минусаторы как раз в курсе, от того и минусуют.
> Минусаторы как раз в курсе, от того и минусуют.Спасибо кэп, а я то думаю у меня в рейтинге переполнение плюсов
Рейтинг: -100 баллов (+9480/-9580)
Репутация: +1004/-1490 голосов
> Спасибо кэп, а я то думаю у меня в рейтинге переполнение плюсовВаш то рейтинг тут причём?
> не написали ни одного сопоставимого приложения с GC которое бы было быстрее аналогичного без него.Это правда.
> А вот аналогов софта с GC, который в последствии был переписал на С\С++ и другие языки без GC полно
А вот это - не правда.
Переписывают очень специфичный софт. Скажем, переписано 0.01% софта, написанного с GC в первой версии на версию без GC. Ибо только в 0.01% случаев выигрыш производительности оправдывал труд программистов на переписывание.
Потому что с GC тупо удобнее. Больше говнокода Богу Говнокода.
Ты можешь выключить GC для своего хелловорлда
Я знаю топовых программистов. Ни кто из них ни когда не говорит "я топовый программист".
Haskell, в сочетании со сборкой мусора с поколениями, может выдавать произодительность, сравнимую с C++
Не верю, у функциональных языков сплошное копирование.
Это что бы кеши прогреть до 90˚C.
Очень жирно
Ты забыл добавить, что ещё надо упарываться несколько месяцев для этого и что в итоге получится совсем неидиоматичный код.
Сколько нужно выжрать смузи, чтоб захотелось в Haskell?
Хаскель для смузихлебов слишком сложен. Только старая гвардия, только хардкор.
Хотите сказать, что Эаскелл сложнее Rust? Если да, то почему?
Хинт: теория категорий.
a может не выдавать...
вы можете писать программы по дефолту(с использованием gc), с ручным управлением gc(если нужно), так и вовсе без использования gc. Подавляющее большинство гошников пишет с дефолтным gc, поскольку в отличии от, он молниеносно быстрый, почему - читайте в спортлото
Для управления хипом там, да, GC.
Единственный нормальный язык программирования.
> Единственный нормальный язык программирования.Нет. Для меня единственный нормальный язык программирования -- это Оберон. А Го -- это испорченный Оберон. Лучше чем питон, сисярп, раст -- но не единственный и не лучший.
Это синдром утенка, с этим стоит бороться.
> Это синдром утенка, с этим стоит бороться.Читайте внимательней. ДЛЯ МЕНЯ.
Хаскель жи!
А вы из секты Информатика21. Ничего это лечится, со временем все пройдет.
Не, у этих обычно не проходит. Так и носятся со своим обероном до пенсии, не сделав при этом ни одного полезного на практике проекта.
> Не, у этих обычно не проходит. Так и носятся со своим обероном
> до пенсии, не сделав при этом ни одного полезного на практике
> проекта.Страйк за враньё. идите на сайт Информатика-21 и читайте про более чем практически-значимые результаты деятельности в сфере Оберон-технологий. В отличии от любителей похрустеть -- оберонщики не переписывают работающие драйвера и не встраивают кривые фильтры в ядро Линукса.
Так в том и дело, что там вся деятельность в "сфере оберон-технологий", замкнутая на саму себя. Чисто академическая деятельность, без практического применения в производстве. Я даже не о мейнстриме говорю. Можно сравнить с другим алголоподобным языком, Ada, который, не будучи мейнстримом, тем не менее широко применяется в оборонке, авионике и управлении воздушным движением. Где применяется Оберон, какие насущные задачи помогает решить?Если есть контрпримеры - всегда готов признать свою неправоту. Но не встречал ни одного.
> Так в том и дело, что там вся деятельность в "сфере оберон-технологий",
> замкнутая на саму себя. Чисто академическая деятельность, без практического применения
> в производстве. Где применяется
> Оберон, какие насущные задачи помогает решить?
> Если есть контрпримеры - всегда готов признать свою неправоту. Но не встречал
> ни одного.Ещё раз страйк за "без практического применения".
Надо ходить по ссылкам и читать, о результатах более чем практического применения Оберона. Причём, по ссылке выше -- ИСКЛЮЧИТЕЛЬНО В РОССИИ (энергетика, производство, сельское хозяйство, атомная электростация и даже антитерор -- без подробностей по понятным причинам). Т.е. я намекаю, что существует масса применений Оберон-технологий в том числе -- и за рубежом. Начиная от боевых самолётов, заканчивая медицинскими приборами. Тут гугель вам в помощь.
А, открылась со второго раза ссылка. Ну это хоть что-то, хотя так и не понятно, внедрено это все промышленно, или разовые экспериментальные разработки, которые не продвинулись дальше опытных образцов или единичных экспериментальных внедрений. Но признаю, что частично не прав.
> А, открылась со второго раза ссылка. Ну это хоть что-то, хотя так
> и не понятно, внедрено это все промышленно, или разовые экспериментальные разработки,
> которые не продвинулись дальше опытных образцов или единичных экспериментальных внедрений.
> Но признаю, что частично не прав.Это всё внедрено и работает лучше, чем швейцарские часы (благо Оберон придуман в Швейцарии). Это не было бы частными инициативами, если бы решения во власти принимали специалисты, а не любители принять конверты от посетителей. Впрочем, могу сказать что потихоньку заказчики, которые рискуют ОЧЕНЬ большими деньгами, либо жизнями людей -- начинают поворачиваться в сторону Оберонов. Есть несколько организаций, которые используют Оберон в качестве единственного решения и клиенты потихоньку начинают выстраиваться в очередь.
Более того, из всех языков программирования я знаю только два языка с промышленной надёжностью: это Ада и Оберон. К обоим языкам у меня есть придирки, но потенциально у Оберона кратно больше шансов стать настоящим языком промышленного назначения. Спойлер: вот эти вот все ваши Си, С++, Раст, питон -- ни разу не языки промышленного назначения. Го занял двоякую позицию (фактически промышленным языком не является), но как наследник Оберона и имеющий мощное инструментальное окружение -- может в некоторых немногих нишах исполнять обязанности промышленного языка программирования.
Вы забыли про Форт.
> Вы забыли про Форт.Форт не является языком промышленного назначения по определению.
>> Вы забыли про Форт.
> Форт не является языком промышленного назначения по определению.По предопределение которого у вас нет?
>> Вы забыли про Форт
> Форт не является языком...Две какашки о чём-то спорят.
Очень забавно, следует отметить!
Для того, чтобы об этом рассуждать, надо для начала ввести критерии языка промышленного назначения. Критерии, очевидно, будут зависеть от конкретной области деятельности. Скажем, для интернет-магазина и PHP отлично подходит.Если же говорить об областях, в которых от бесперебойной работы ПО зависит жизнь и здоровье человека (как экстремуме), то даже в Ada с ее богатой системой типов выразительных средств недостаточно, чтобы дать 100% гарантии. В идеале, для критических алгоритмов должно требоваться доказательство их корректности, а типы должны учитывать контекст. Такой язык есть, хоть и в экспериментальном статусе (по сути, разрабатывается одним человеком) - Idris. Да, ФП а-ля Haskell, и чтобы программировать в этой парадигме, нужна определенная подготовка, но без выделения pure functions эта задача вряд ли вообще решаема.
> Для того, чтобы об этом рассуждать, надо для начала ввести критерии языка
> промышленного назначения.Легко. В двух словах: промышленный язык программирования -- должен быть предельно прост (но не примитивен), для успешного переноса с платформы на платформу ,возможности внедрения даже на самые смешные контроллеры и максимально препятствовать совершению ошибок со стороны программиста с одной стороны, и позволять легко проверять код с другой стороны. Семантика языка должна быть жёстко зафиксирована.
> Критерии, очевидно, будут зависеть от конкретной области деятельности.
> Скажем, для интернет-магазина и PHP отлично подходит.Нет. Куча дыр в самом языке, и ещё больше дыр во всех программах написанных на нём.
> Если же говорить об областях, в которых от бесперебойной работы ПО зависит
> жизнь и здоровье человека (как экстремуме), то даже в Ada с
> ее богатой системой типов выразительных средств недостаточно, чтобы дать 100% гарантии.Ада по определению не может дать 100% гарантии. Так как ВНЕЗАПНО её компилятором является gcc, который никто никогда не проверял и не верифицировал даже для основных платформ. Более того, на компанию, которая делает Аду распространяются требования торговой палаты США, а значит она не имеет права продавать Аду в Россию со всеми вытекающими последствиями. Делайте выводы.
> В идеале, для критических алгоритмов должно требоваться доказательство их корректности,
> а типы должны учитывать контекст. Такой язык есть, хоть и в
> экспериментальном статусе (по сути, разрабатывается одним человеком) - Idris. Да, ФП
> а-ля Haskell, и чтобы программировать в этой парадигме, нужна определенная подготовка,
> но без выделения pure functions эта задача вряд ли вообще решаема.Всё это не может быть использовано в качестве промышленных языков программирования по причинам смотрите выше в кратком определении.
Автомат Калашникова -- потому и автомат Калашникова, что он _предельно_ прост, что влечёт за собой надёжность и эффективность. Ни Идрис, ни Хаскель не удовлетворяют этим требованиям.
> В двух словах: промышленный язык программирования -- должен быть предельно прост (но не примитивен), для успешного переноса с платформы на платформу ,возможности внедрения даже на самые смешные контроллеры и максимально препятствовать совершению ошибок со стороны программиста с одной стороны, и позволять легко проверять код с другой стороны. Семантика языка должна быть жёстко зафиксирована.Это довольно специфический набор требований, у другого человека будет другое определение. Особенно специфично про внедрение на контроллеры - вы же понимаете, что большинству людей это не надо?
К вашему определению, кстати, golang подходит.
> Куча дыр в самом языке, и ещё больше дыр во всех программах написанных на нём.
В языке уже давно всё поправили, а в программах - всё зависит от конкретного программиста. Чем ниже порог входа, а у PHP он минимальный, - тем ниже среднее качество кода.
Дыры в PHP в основном в логике, он как язык нелогичен и неконсистентен. Но писать на нем можно. Начинать на PHP проект с нуля я бы не стал - при нынешнем богатстве выбора нет смысла так себя мучать. А если речь о доработке и развитии уже существуюшей кодовой базы, и код написан прямыми руками (такое нечасто, но бывает), все нормально.
> Ада по определению не может дать 100% гарантии
Как и любой другой язык, не имеющий встроенных в компилятор средств формального доказательства корректности.
> на компанию, которая делает Аду распространяются требования торговой палаты США, а значит она не имеет права продавать Аду в Россию со всеми вытекающими последствиями. Делайте выводы.
Во-первых, не в Россию, а российским компаниям, находящимся под санкциями. Возможно, для вас это важно, но для большинства людей нет.
Во-вторых, на open source это никак не распространяется, GNAT под GPL 3.> Всё это не может быть использовано в качестве промышленных языков программирования по причинам смотрите выше в кратком определении.
В соответствии с вашим определением - да. И это нормально, каждый выбирает инструмент по своим потребностям.
В областях же, где потенциальный баг грозит катастрофой, и нужны 100% гарантии, более высокая сложность самого языка вполне оправдана.
> А вы из секты Информатика21. Ничего это лечится, со временем все пройдет.Да, у нас своя секта и не надо завидовать. Организовывайте свою.
А как же Elm?
Го включает уборку мусора где надо и не надо, порой высоконагруженное приложение проще написать на питоне, чем бороться с уборкой мусора и его нагрузкой на го. Раньше думал, что го это идеал, но теперь как-то он мне не очень.
Вызывай уборку мусора руками. Делов-то.
Ты всегда можешь сделать это эффективнее сам. Все инструменты для этого есть.
Да, опыт того же Дискорда подсказывает, что Го достаточно далёк от идеала
Но большинству далеко до Дискорда по нагрузке, а значит и Питона хватит
Это была откровенно тупая статья от чувака из дискорда. Ему там же в каментах насовали, что он чушь написал. Так что опыт показывает, что люди нихера не читают, а слышат звон 😄
К тому же дискорд принадлежит microsoft, а этим ребятам нет веры. И надежды. И любви.
> дискорд принадлежит microsoftОткуда дровишки?
Статья дискорда устарела до ее выхода.
> Го включает уборку мусора где надо и не надо, порой высоконагруженное приложение
> проще написать на питоне, чем бороться с уборкой мусора и его
> нагрузкой на го. Раньше думал, что го это идеал, но теперь
> как-то он мне не очень.Шта?)))
Ты мне не рассказывай. Даже когда Го не умел все ядра пользовать -- я не поленился и написал тест для сравнения Го 1.13 и питон 3.4 -- Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз, Visual Basic 6.5 порвал питон наравне с Си в 60 раз, чем старичок меня ОЧЕНЬ СИЛЬНО удивил, даже питон 2.7 сделал питон 3.4 примерно в 1.7 раза, PascalABC.Net уже умел многоядерность и порвал питон уже тогда примерно в 180..200 раз.). Теперь Го имеет многие оптимизации и многоядерность. На моей домашней машине Го 1.16 рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 раз по скорости и примерно 5 раз по потреблению памяти.Ты так написал про СМ в Го, что можно подумать, что его в питоне нет. Ах да: задержки на стоп-ворлд в Го давно исчисляются временем по 10..15 мксек. В питоне -- 1...1.5 мсек. Это я тоже проверял лично, чтобы ты знал великий ыксперд.
Попробуй организуй асинхронную обработку 50к запросов одновременно на питоне, вперде. Если тебя начальник не уволит за такие финты, значит тупой у тебя начальник.
Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет, как го порвал ассемблер в 10 раз.
Чувак просто не умеет в алгоритмы :)
>Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет, как го порвал ассемблер в 10 раз.во-первых, Го порвал в 40 раз, а во-ворых, С не делает программы быстыми магическим образм.
> На моей домашней машине Го 1.16 рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 развчитываться научись о потом спорь
>вчитываться научись о потом спорьВот именно, научись.
В тесте, где учавствовали и Го и С тестировался питон 3.4.
А в тесте, где Го уделал питон в 200 раз, был уже 3.8.Так что не надо тут мешать попугаев.
Не только. В дополнение:
- в тесте, где учавствовали и Го и С, го быстрее в 40 раз, Си в 60. Си быстрее, как хочет этот хейтер. И Го "без многоядерности". Т.е. этот тест у си и го скорее всего одноядерный/однопоточный.- в тесте, где Го уделал питон в 200 раз, про Си ничего не говорится, сишного теста не было, а Го к этому моменту "имеет оптимизации и многоядерность", что "какбе намекает", что там уже не одноядерность/однопоточность.
> - в тесте, где Го уделал питон в 200 раз, про Си
> ничего не говорится, сишного теста не было, а Го к этому
> моменту __"имеет оптимизации и многоядерность"__, что "какбе намекает", что там уже
> не одноядерность/однопоточность.Неужели кто-то умеет читать?))
> Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет...Из написанного им похоже, что Сишное запускал он на одном ядре, а Гошное на всех доступных ядрах.
OpenMP он не осилил.
А нах**?
Человеку нравится го, он пишет на го, сравнивает многопоточку на го с многопоточкой на питоне. При чем тут Си?
Вы ещё скажите, что он плохой, потому что не включил в сравнение ассемблер и аду.
> При чем тут Си?а вы у этого человека и спросите к чему он всё это приплел
>> При чем тут Си?
> а вы у этого человека и спросите к чему он всё это приплелДля чего написал? Т.е. то, что я даже процитировал то, зачем написал -- вы даже это не прочитали?
> сравнивает многопоточку на го с многопоточкой на питонеА чего их сравнивать? И так всё понятно. GIL же.
> Из написанного им похоже, что Сишное запускал он на одном ядре, а
> Гошное на всех доступных ядрах.
> OpenMP он не осилил.Вроде по русски написал, что Го 1.13 в этой версии не умел многоядерность. OpenMP в Го? Ты немного неадекватный, брат анон. И текст про PascalABC.Net (в котором таки как раз есть OpenMP) ты тоже пропустил (судя по твоему комменту).
> Вроде по русски написал...А как был ты необразованным чучмеком, так и остался.
Читайте внимательно. Акцент при чтении делайте на поддержку многоядерности и сами цифры.Вроде очевидно, что начало списка (превосходство в 40-50-60 раз) - это
> когда Го не умел все ядра пользовать
И сравнивая цифры можно сделать вывод, что тесты на других языках тоже на одном ядре/в однопоток выполнялись).
А потом уже
> PascalABC.Net уже умел многоядерность и порвал питон уже тогда примерно в 180..200 раз ...
> Теперь Го имеет многие оптимизации и многоядерность... рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 раз по скорости...Вы где-то увидели упоминание про многоядерную/многопоточную вторую версию теста на Си?
Согласен, слегка сумбурно изложено, без деталей и уточнений, но понятно же, чего придираетесь?
> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 разА я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то подразочаровался. Свой парсер у него говённый, но даде с биндингами к либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.
>> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз
> А я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то
> подразочаровался. Свой парсер у него говённый, но даде с биндингами к
> либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.Наверное, потому что ты как-то не так готовил кошек? Прямо сразу из твоего сообщения я вижу, что как минимум, вместо того, чтобы использовать strings.Builder() ты использовал строки (которые в го -- неизменяемые сущности, поэтому таки да -- использовать строки налево и направо - -в го весьма дорого). Типичное решение в го в таких случаях -- использовать срез рун. А уж как ты там парсил и почему ты не посмотрел решения на github.com с кодогенерацией, которая даёт ускорение под конкретный XML в 5-10 раз -- вот тут мне понятно, что навыки программирования у тебя на уровне джуниора.
Ты использовал биндинги? А ты хоть немного интересовался, какие ограничения накладываются на использование сишных биндингов в Го? По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию. Использовать колёса разных размеров и иногда немного квадратные в одном автомобиле -- это не айс. Подучил бы ты сначала го-вей, а потом садился писать высоконагруженные штуки.
Я на чтение пробовал, а не на запись. Мне нужен был SAX парсер - гигабайтный файл был маленьким семплом. Нахера там стрингбилдер? Строки, полученные из ХМЛ - зачем их менять? Просто Го делает обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или, наверное, петон, но медленнее опасных языков в разы.
> Я на чтение пробовал, а не на запись. Мне нужен был SAX
> парсер - гигабайтный файл был маленьким семплом. Нахера там стрингбилдер?
> Строки, полученные из ХМЛ - зачем их менять? Просто Го делает
> обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или,
> наверное, петон, но медленнее опасных языков в разы.Даже если ты просто читаешь -- ты выделяешь память. Если ты просто заполняешь поля структур строками -- ты выделяешь память. Так вот, если бы ты использовал срезы рун -- ты бы память выделял -- ровно один раз. А strings.Builder() -- довольно не дурно сам понимает -- сколько ему памяти удерживать, а сколько отдать назад сборщику мусора (т.е. нет лишнего выделения памяти). Кроме того, эта штука умеет очень быстро почти без накладных расходов преобразовывать свой буфер в байты/руны/строки. Так что, инструмент надо не только уметь держать, но ещё и пользоваться им. Так что ты бы попробовал кодогенерацию. Безопасно, достаточно быстро для безопасного парсинга, ещё и код писать не надо руками -- только описать структуры в шаблоне.
Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь. И к библиотекам нет вопросов, я попробовал их все, что были на тот момент за исключением родной гошной укуренной. На Го быстрее просто невозможно - копируешь строку как минимум один раз, что из го-кода, что при передаче из опасной libxml. Там и тормозить-то больше нечему.
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и
> передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь.Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это значит, что вся конкурентность го идёт псу под хвост. Если у тебя даже 128 ядер будет -- фактически работать у тебя за счёт сишной либы всегда будет только одно ядро.
> И к библиотекам нет вопросов, я попробовал их все, что были
> на тот момент за исключением родной гошной укуренной. На Го быстрее
> просто невозможно - копируешь строку как минимум один раз, что из
> го-кода, что при передаче из опасной libxml.Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз -- волшебное слово.
На го можно достаточно быстро, чтобы сравнивать с чистым си (не на порядок будет отставание, а в типовом случае в 2х..4х раза -- это плата за безопасность, но стоит она дороже, чем 2х...4х).
Родная гошная библиотека просто даёт возможность что-то сделать. Фактически, существует по 3-5 реализаций каждой гошной библиотеки с оптимизациями 5х..20х раз. Что JSON, что XML, что HTTP.> Там и тормозить-то больше
> нечему.А так-то да. Всё что мог затормозить -- ты успешно затормозил))
> Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это
> значит, что вся конкурентность го идёт псу под хвост. Если у
> тебя даже 128 ядер будет -- фактически работать у тебя за
> счёт сишной либы всегда будет только одно ядро.Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а не в ЦПУ :-D
> Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз --
> волшебное слово.Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не сможет.
> А так-то да. Всё что мог затормозить -- ты успешно затормозил))
Ну разве что тебя, да и то не хотел, прости ;-D
> Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а
> не в ЦПУ :-DЗадачу парсинга XML вполне можно параллелить.
> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
> сможет.Зато параллельно парсить сможет.
> Задачу парсинга XML вполне можно параллелить.Задачу парсинга параллелить не нужно. IO тормознее всех остальных операций.Параллелить лучше то, что происходит уже после парсинга. Собственно с этой целью я на Го и смотрел. Но горутины когда начинешь их обмазывать каналами и прочей мутотой начинают захламлять код не хуже многопоточных реализаций на каких-нибудь опасных языках. И ещё куча всяких мелочей делающих бессмыссленным переход на Го. Но тормоза при работе с данными - это первая причина. БОльшая часть того, с чем работает энтерарайз - это не какие-то космические вычисления, это просто парсинг потоков данных вагинирующих от одного сервиса к другому с какми-то элементарными операциями над ними. А Го в это не может. И тут ещё такой момент - теоретический предел производительности при парсинге XML, безразлично каким количеством потоков, это биндинг опасной libxml2. Есть поделки и намсамом Го со сравнимой производительностью, но они сильно срезают углы ради этого: ничего не знают про кодировки, например. И меня бы это устроило в том конкретном случае потому, что данный тип файлов у меня в ASCII и го вообще хоть регэкспами чеши. Но кто гарантирует что так будет всегда? А случись пояаиться кодировкам в даанных и эти поделки придется заменять на те, что будут перекодировать данные внося очередной раунд аллокации-копирования-удаления строк. Нет никакого смысла закладываться на такой ущербный инструмент. Тем более, что если мы пишем приложение на опасном языке, и наши данные не требуют особой магии, то появляется возможность маневра в сторону реализаций вообще без аллокации памяти: просто отображаем фай в память и используем строки прямо из этой памяти - такие парсеры прямо в мапе разбрасывают нули в конце строк и передают адрес строки пользователю. Быстро, дёшево и сердито. Но в Го такое випринципе невозможно.
>> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
>> сможет.
> Зато параллельно парсить сможет.И что нам это даёт? Неконкурентоспособное решение, которому нужно несколько ядер там, где и одного-то за глаза?
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки...Этот чел вообще мало что понимает. Полный п-ц, на самом деле.
> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.Постоянно вижу сишный sqlite в программах на go
>> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.
> Постоянно вижу сишный sqlite в программах на goЯ вообще не понимяу какая там разница. Ну вот допустим кто-то перепишет sqlite на Го.Что изменится? на каком-то этапе Го всё равно придётся взаимодействовать с опасным внешним миром, написанном на сях. Только это будут сырыа данные из файла, не отфильтрованные опасной библиотекой sqlite, т.е. копирований опасного контента в безопасный будет только больше, производительность будет хуже.. Так чем же это лучше??
А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может быть я могу помочь вам с оптимизацией :)
> А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может
> быть я могу помочь вам с оптимизацией :)Нет. Ни тем ни другим. Там в тесте банально было - никакой осмысленной логики: парсер нашел тег, создаём соответствующего типа объект (просто заглушки со списком детей, на такой случай дженериков тоже языку не хватает кстати), говорим паренту, что у него родился сын - и всё. По возвращении на верхний уровень, скидываем объект верхнего уровня в канал на обработку и всё начинается сначала. Иерархии там не очень большие, каждый такой тег верхнего уровня килобайт примерно сто наверное, хотя бывают всплески и до пары сотен МБ. Но это не важно с т.з. парсинга - что что миллионов раз по сто тысяч байт байт переварить, что сто тыщ раз по сто миллионов байт - без разницы просто.
Короче, оптимизировать там банально нечего. Просто в силу особенностей языка он гарантирует издержки при работе с данными, by design.
Я не хочу показаться хейтером Го. Есть куча ПО, написанного на Го, которое наглядно демонстрирует преимущества этого средства на петоном и прочей "безоппасной" лабудой. Приложения, написанные на Го как правило значительно шустрее и надежнее написанных на этих странных ЯП. Я просто не понимаю зачем на н1м писать :)
Вы код и sample дайте. Я просто уже давненько применяю Go в high performance, и частенько вижу жалобы (вроде вашей), но в >95% люди просто не правильно использовали Go для своей задачи. И каждый раз твёрдо верят, что такого не может быть.
Увы, не выйдет. Это было более полутора лет назад - я уже повыкидывал и Го и хелловорлды свои, да и синтаксис самого Го успел забыть.
Ну что тогда сказать? В общем, на самом деле Go нормально подходит для почти любой высокопроизводительной задачи (хотя это нередко приводит к заменителям стандартных package-ей). Реальная проблема там с safety, а не performance. И вызвана она, например, отсутствием immutable переменных (там нет ДАЖЕ аналога Сишного const) и вообще невыразительной системой типов.
Так я об этом и говорю, что по всей видимости потери идут при переходе данных из опасного внешнего мира в безопасные потроха гошной программы, на парсинге ХМЛ это очень заметно, потому что очень много строк приходит. Константных, одинаковых. Не знаю, возможно что-то с этим можно что-то сделать на уровне биндинга к libxml2 - например не конвертировать строку, содержащую имя тега каждый раз как его надо отдавать в Го-программу, а держать таблицу гошных строк и на них ссылаться если такая строка уже есть.
>высоконагруженное приложение проще написать на питонеага. просто "высоконагруженное приложение на питоне" потребует от 64гб памяти и 32+ ядра, плюс его нужно будет раз в пару часов перезапускать. но ты прав, написать проще
для пруф-оф-консепта сойдет, а потом можно нанять нормальных программистов и переписать на с.
Если хочется ещё больше багов понаделать - можно и на си. Кто там у нас пишет распределённые системы на сях? Ух ты, никто, здравый смысл видимо ещё есть.
Очень много пишут рапределёных систем на Си до который недоязычкам никогда не дотянуть. Пример Oracle.
Класс, целый один пример. И то без пруфов. Ясно, понятно :)
Tarantool, PostgreSQL
> Очень много пишут рапределёных систем на Си до который недоязычкам никогда не дотянуть. Пример Oracle.Ха! Уморили! Худшего примера привести не могли. Я средненький ораклоид-быдлокодер, с этого только и живу, эту БД уважаю, но почитайте из первых рук про тот ад в разработке этого проекта. От бывшего разработчика, поучаствовавшего в разработке Oracle Database 12.2:
https://news.ycombinator.com/item?id=18442941
"Oracle Database 12.2.
It is close to 25 million lines of C code.
What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
...
The only reason why this product is still surviving and still works is due to literally millions of tests!
...
The fact that this product even works is nothing short of a miracle!I don't work for Oracle anymore. Will never work for Oracle again!
"Вольный перевод
https://habr.com/ru/post/429946/
Посмейся ещё. С версии не позже чем с 11 Oracle делают почти одни индусы. Когда делали белые американцы всё было отлично. Я Oracle Юзал когда он ещё был версии 9.x.Нужно отделять проблему быдлокодинга индусов и возможности Си. Если кривые руки индусов исправить нельзя то Сишный код можно дробить на модули, так делают все. Если всё свалить в один большой проект то в нём будет трудно ориентироваться.
> Посмейся ещё. С версии не позже чем с 11 Oracle делают почти
> одни индусы. Когда делали белые американцы всё было отлично. Я Oracle
> Юзал когда он ещё был версии 9.x.
> Нужно отделять проблему быдлокодинга индусов и возможности Си. Если кривые руки индусов
> исправить нельзя то Сишный код можно дробить на модули, так делают
> все. Если всё свалить в один большой проект то в нём
> будет трудно ориентироваться.Возвращаясь к топику - если Оракл переписать на Го, то что-нибудь улучшится?
> Посмейся ещёСпасибо, посмеялся. Прям оборжался. По ссылкам, видимо, не сходил?
Там про проблемы еще с Oracle8i и даже с 1980-90-х тянутся.
Самое с чего оборжался, это
> Когда делали белые американцы всё было отлично. Я Oracle Юзал когда он ещё был версии 9.x.
Вы работали в Оракле над их БД и видели исходники "до индусов" и после? Я юзал Оракл с 8i и юзаю поныне. И? Факт того, что я юзаю, как-то круто улучшило оракловский код?
И еще - ты думаешь, пришли индусы и всё там переписали с нуля в лапшу, не оставив старого кода? Тот ад, что описали разрабочики, в большей степени связаны со старым кодом и невозможностью рефакторинга. И индусы и белые американцы просто уже не могут его отрефакторить.
> Если хочется ещё больше багов понаделать - можно и на си. Кто
> там у нас пишет распределённые системы на сях?Интернет -- это достаточно распределённая система? Из чего она состоит?
> для пруф-оф-консепта сойдет, а потом можноНи кого не нанимать, и силами тех же питонщегов переписать на Go.
Это правда на половину. Память там не "течет" бесконечно, она отжирается до определенного объёма в свой аллокатор. Потом перестает отжираться когда внутри ее достаточно.
На практике надо очень сильно постараться, чтобы GC pause стала критичной. При этом в языке с ручным управлением памятью в аллокатор упереться можно даже раньше.То есть проблема, конечно, существует, но большинство типичных для go I/O-bound проектов просто никогда в нее не упрутся.
> надо очень сильно постараться, чтобы GC pause стала критичной.Ну, разработчики жабы, похоже, таки очень сильно постарались.
В java и golang очень разные GC.
Го "включает сборку мусора" там, где происходит передача переменной по ссылке за пределы контекста создания переменной.
Передавай небольшие структуры по значению, не кидайся лишний раз данными за пределы скоупа, а когда таки нужно постоянно передавать много экземпляров одной структуры, юзай sync.Pool, чтобы снизить объем работы для gc.
Ну и pprof в помощь.
Подскажите, пожалуйста.
А новичку (60-летнему гуманитарию) будет ли сложно освоить этот язык?
С одной стороны, язык довольно простой, так что освоение могло бы быть не труднее других. С другой стороны, литературы по Go, рассчитанной на новичков в программировании, я не встречал. На английском, вероятно, что-то уже есть, но на русский не переводилось.
Нет, не будет.В этом одна из основных проблем современных языков - их делают с очень низким порогом вхождения ценой переусложненности всего, что хоть чуть-чуть выходит за рамки хелловорлда.
Для вхождения достаточно пройти примеры на офсайте https://golang.org/
>их делают с очень низким порогом вхожденияНизкий порог у тебя в русском языке и матчасти, сынок.
И что же в golang переусложненного?Единственное, что действительно мешает в более-менее крупном проекте - это отсутствие дженериков. Приходится либо писать нетипобезопасный код с interface{}, либо заниматься кодогенерацией. Но дженерики с точки зрения языка это таки усложнение, а никак не упрощение.
В остальном же с ростом объема кода будут те же проблемы, что и в любом другом языке, и решаются они так же, как и в любом другом языке - архитекурно: модульностью и понижением связанности.
Пусть зазубрит https://gobyexample.com/ потом можно сразу коммитить в мастер и на прод.
Если он плохо умеет в английский (что странно) то https://gobyexample.com.ru/ там некоторых тем нет, но тоже сойдет.
можно полюбопытствовать - для чего 60 летнему гуманитарию golang ?
пусть изучает python если так хочется, он для более широкого круга задач с кучей либ на все случаи жизни
Для гимнастики мозга. Сейчас с FreePascal'ем балуемся.
Вот подумал, может что серьезней. С и С++ - это вряд ли. Рython - как-то душа не лежит.
Сейчас пытаюсь понять - что за звери такие Go и Rust. Поэтому и спрашиваю, чтоб выбрать в кого из них сунуться или пожизненному гуманитарию лучше с ними не связываться.И вообще - это лучше, чем со стариками козла забивать.
деда учи 1с
Она у меня уже поперек горла стоит. Почти 30 лет за ней, окаянной, отсидел. Изучил похлеще наших компутёрщиков. Ко мне консультироваться бегали.
Вот тут https://plana.mybb.ru/viewtopic.php?id=1528
человек тоже лет 30 отсидел на 1С и теперь пишет свой язык.Вот http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=401 он же
Где вы такие ссылки находите? Поразительно! Откуда столько сумасшедших в одном месте?
> Где вы такие ссылки находите?Элементарно, Ватсон. Все ссылки находятся в Интернете.
> Поразительно! Откуда столько сумасшедших в одном месте?
В моём сообщении ссылки на два места, значит Вы промазали ответом?
Эх, молодо-зелено. Русский синтаксис им в новинку. Поисковики (все!) хоть и скатились в говно за последние 5 лет, но интегрированную систему Мастер Веселова помнят пока ещё (что удивительно).
Дело не в русском синтаксисе (он может быть вполне уместен в DSL для областей с исключительно русскоязычной терминологией, как в том же 1С), а в мотивации и образе мышления :-)
Как раз мышление участников обсуждений по моим ссылкам различается кардинально. Язык Санда создал 1С-практик, которого существующая система не устраивает, для своих целей. Даже где-то умудрился внедрить. А кто-то очень много рассказывает, что должно быть всё русское, выпущенное в России и на кириллице, но обязательно под написанной на английском лицензией, и при этом сам ничего не сделал.
> пытаюсь понять - что за звери такие Go и RustИз этих двух новичку однозначно легче будет разобраться с go. Rust создавался как замена C++, потому и получился изначально довольно сложным (не как C++, но всё же).
Не для чего rust не создан, это просто кусок говна.
Rust и C++ точно не стоит, это слишком сложно для начинающего. Да и вообще сложно: слишком много специальных концепций и особых случаев.А C я бы так не отвергал, просто нужен хороший учебник. Как язык он простой и даже минималистичный, надо только понять, что такое указатели, и попрактиковаться. Как зарядка для ума это вообще самое то.
Ну и вообще, я лет в 14 был уж точно поглупее вашего, но с хорошей книжкой (не помню имя автора, к сожалению) разобрался без проблем на чистом интересе, имея только доступ к старому 80386 с Turbo C. Тогда и интернета не было, и совета спросить было не у кого, и со случайно выбранной книжкой просто повезло. О нынешней ситуации, когда можно что угодно нагуглить или задать вопрос на каком-нибудь stackoverflow, я и мечтать не мог.
Julia, если для себя программировать
Разве это не язык для математики?
Математику на Julia, безусловно, писать приятнее, чем на чём-то ещё. Но нет, математикой она не ограничена.
> Для гимнастики мозга. Сейчас с FreePascal'ем балуемся.
> Вот подумал, может что серьезней.Это вполне серьёзный язык, просто он не всем нравится. Например, А.Ахо, Дж.Хопкрофт и Дж.Ульман используют Паскаль в книге "Структуры данных и алгоритмы". Интересно, сколько программистов на Go прочли что-то похожее.
Для описания алгоритмов алголоподобные языки это вообще классика жанра. Можно воспринимать как псевдокод - они понятны сходу, даже если языка не знаешь. Многословность тут скорее плюс.А вот для практического промышленного программирования эта многословность становится минусом.
Да, для промышленного программирования некоторым достаточно баша, всемирно известная ОС Rosa Tresh на нём написана. Но тут для гимнастики мозга, может и не надо менять Паскаль.
Менять - это, да, неверная постановка. Скорее в дополнение, для расширения кругозора.Но тут я скорее C посоветую, осилить концепцию указателей - отличная гимнастика.
Golang все же чисто практический язык, предназначенный для промышленных I/O-bound задач, на учебных задачах не особо понятно, почему он такой, какой есть.
на go оказали влияние python и pascal
если с pascal балуетесь то наверно go
Честно говоря, не вижу особого влияния python.Да и влияния паскаля тоже немного, если кажется, что := оттуда, то не совсем, в go у этого оператора куда более узкое назначение. Больше видно влияния других паскалеподобных языков (типа Ada), реализующих CSP, вариацией на тему которых и являются горутины. Но на самом деле - учитывая, кто авторы языка - это явно взято из Alef (диалекта Си из Plan 9), где были и корутины, и каналы.
Vala. Сила чистого Си, простота Паскаля.
> Сейчас с FreePascal'ем балуемся.Как по мне, объектный паскаль - самый красивый язык. К тому же гуй из коробки, вроде даже два. Для расширения кругозора можно и не метаться между языками. Освойте что-нибудь полезное в нём - например локлесс там вроде сосёт. Есть какая-то библиотека, но сильно ограниченная и без внятных док. Сделайте свою. Хоть польза будет обществу.
> он для более широкого круга задачЭто какие же задачи, интересно, решаются на python проще и эффективне, чем на go?
Прогрев процессора, утилизация дискового пространства и канала ввода/вывода, трудоустройство программистов для написания дополнительных средств проверки
Вангую, хочет войти в айти. Грести бабло лопатой, попивая смузи в подвале
Хреновая из тебя Ванга. Человек написал, что в АйТи уже 30 лет почти, 1с программировал. Теперь захотелось что-то новое.
Вообще-то я не совсем в АйТи, Даже совсем не АйТи.
Кладовщик я. В 1С разобраться просто, тем более в юности попалась книжка по Рапире. А они малость похожи.
Есть мнение (не только мое), что ЯП в 1С скомунизженная Рапира с последующей переделкой под свои нужды.
Покукарекай тут еще, гребень
Рекомендую Perl, без шуток
> unsafe.Add и unsafe.Slice для безопасных арифметических операций с указателями и безопасного преобразования указателей в слайсыUnsafe - это небезопасно.
Плохой небезопасный язык. Всем нравятся языки плохиши.
Вообще-то, за использование unsafe в секте go обычно применяют суд Линча. И доказать тимлиду, что unsafe ну очень очень нужно -- практически невозможно. И это лучше в 10..50 раз адресной арифметики в Си. На всякий случай.
А если работаешь в культуре без тимлидов? :)
> А если работаешь в культуре без тимлидов? :)Как это мешает суду Линча?)
Ну вот я работаю в компании, где нет суда Линча.
> Ну вот я работаю в компании, где нет суда Линча.Это плохо. Общество лишённое цветовой дифференциации по цвету штанов -- обречено. И надень цак, дорогой.
Прекрасный язык, лёгок в освоении, надо обновиться.
> лёгкость написания кода, быстрота разработки и защищённость от ошибоктолстота
Какой бессмысленный расход энергии и ресурсов!
Зачем эти сотни "языков", если давно существует Си?
О нет, ты снова его выкопал. Закопай уже обратно и не трожь.
Бессмысленный расход энергии и ресурсов на борьбу с уязвимостями и утечками.
Зачем же Вы пишете уязвимый код, да еще и с утечками памяти?
А Вы видимо из тех, кто пишет с ними, но думает, что без них? Ничего страшного, осознание придёт с опытом.
Во-первых, причем тут я?
Во-вторых то же.
Напиши для сравнения два сервиса на Го и С.Шняга которая делает много запросов в какой-то апи и сохраняет данные в файл.
И сравним реализацию.
А давай, ты напишешь на Go и C приложение с GTK на борту. Хотя бы что-то простое а-ля текстовый редактор GEdit. Можно для примера написать модуль ядра Linux с простой функцией, которая спамит произвольный текст в файл.
> А давай, ты напишешь на Go и C приложение с GTK на
> борту. Хотя бы что-то простое а-ля текстовый редактор GEdit. Можно для
> примера написать модуль ядра Linux с простой функцией, которая спамит произвольный
> текст в файл.Если было всё так радужно с С, то гугл с его объемами данных не стал бы вкладываться в Golang. Кодили бы все подряд на сях и в ус бы не дули.
Гугл на этом собаку съел, у них до Goland всё высоконагруженное писалось на Сях. Чтоб ты представлял на сколько там все серьезно - они дошли до разработки железа и архитектуры камней под себя.
Под словом "ресурсы" подразумеваются не только ресурсы окружения где работает ПО, но и ресурсы разработчиков, время, легкость и сложность разработки, разворачивания и масштабирования.
Сюда же отказоустойчивость и затраты для его достижения и поддержания.
Си для ОС более чем идеален, но даже там начинают подтягивать Rust, ибо немножко устали и решили чуточку облегчить себе разработку.
Что касается GTK. Golandg создан для работы в backend, для пользовательского ПО существует Java и C++, и боже упаси - электрон.
А какая проблема использовать GTK в Go. Да GTK делался для Си only,но никто не запрещает эти функции дёргать из Go. По поводу ядра -- это особенность ядра Linux, а не языка программирования.
> Зачем эти сотни "языков", если давно существует Си?Для тех, кто не может осилить указатели с адресной арифметикой, но очень хочет что-то там программировать.
Да, сейчас таких миллионы.
Ты так говоришь, как будто это что-то сложное и всегда нужное. Это выдаёт в тебе неофита.
> не может осилить указатели с адресной арифметикойА что сложного в unsafe.Pointer.Add()?
Тем что арифметические операции можно было просто делать арифметически операциями. Только вот не надо тут говорить что перегрузка операторов это плохо.
Ну приводи к uintptr и делай арифметические операции. И перегрузки никакой не надо.
Адресную арифметику даже усиливать не надо: она и так всем понятна. Но при этом её в небезопасной форме всё равно лучше избегать, чтобы сократить поле для случайных ошибок в коде.
Я бы хотел C с синтаксисом Go. Без GC, map, slice, каналов и select. Но со строками и горутинами.
Аналог горутин относительно легко реализовать на C (как и на любом достаточно низкоуровневом языке), на основе setjmp/longjmp.Чтобы было похоже на go, можно обвешаться макросами.
Да, аналог горутин легко намутить. Но если будут в языке, то будет приятно пользоваться.Но согласен: можно и без них.
Я тут уже упоминал как-то Alef из Plan 9, сомневаюсь, что найдёшь живой компилятор, но хотя бы описание языка спокойно гуглится. Возможно, это и есть ровно желаемое.
goroutine-ы без chan-ов и select-ов? Эх. Не ценят люди CSP (ради которого и делались goroutine-ы).
Мне чаще всего макросов достаточно. И если потребуется, CSP смогу намутить какой нужно.Просто механизм каналов и select в том виде, как он сейчас есть, крепко завязан на GC. Если хотеть “без GC”, то по-любому придётся переписывать под «свой аллокатор/RefCnt/Epoch Based/Region Based/etc».
Ежели смириться с GC, то нужно просто брать Go, какой он есть.
Блин, не «макросов достаточно», а «мьютексов достаточно».
Либо бывает можно sync.Pool применить, например.А тонны mutex-ов в большом сложном проекте -- тоже бывает не очень хорошо (с точки зрения сопровождабельности кода).
Может кто объяснит как так получилось что Гугол пиаря Go не собирается его использовать в fuchsia?
благодаря стараниям пайка, Go получился слишком свободным от гугла, в отличии от Kotlin и Dart, которые без средств и регистрации гугла использовать не реально.
Kotlin - это JetBrains.
Go затачивался для асинхронных серверных приложений (у него лапки^WGC) для ядра не подходит.
Для компонентов есть выбор https://fuchsia.dev/fuchsia-src/development/languages
спасибо за вменяемый ответ
> Go затачивался для асинхронных серверных приложений (у него лапки^WGC) для ядра не подходит.https://embeddedgo.github.io/
Bare metal RISC-V programming in Go и т.п.
>> Go затачивался для асинхронных серверных приложений (у него лапки^WGC) для ядра не подходит.
> https://embeddedgo.github.io/
> Bare metal RISC-V programming in Go и т.п.Кто то говорил что это невозможно сделать? При желании можно самые странные комбинации составить - и это будет работать, по крайне мере в тепличных условиях. Другой вопрос стоит ли, если только это не ради развлечения.
Собирается и использует, но зачем язык для бекенда совать в приложения с гуем если в Фуксии уже для этого придуман Dart?
> Может кто объяснит как так получилось что Гугол пиаря Go не собирается его использовать в fuchsia?Google не пиарит Go, более того в Google принято недолюбливать Go и использовать его только вынужденно, по необходимости. Миф об этом "пиаре" форсят укурыши чтобы обосновать свои нелепые идеи.
Во-первых, Go используется в Fuchsia. Во-вторых, у Go всё же немного не ядровая ниша изначально.
злопыхателям GC скажу так: и в Go и в Dlang есть средства регулирования работы GC и можно предотвращать его работу вовсе. Dlang - уже показал, что работает быстрее чем Go и C++. подробности спрашивать в группке dlang.ru в телеге.
Странно но D за двадцать лет так и не получил популярности.
Сайт Дланг точка ру, лол там совсем обкурились? вершки картотфеля курите? А чо, говорят вставляет нехило.
Что видит анонинм на сайте посвященном языку программироания? рекламу сомнительной политической организации?
> We're sorry but hello-world doesn't work properly without JavaScript enabled. Please enable it to continue.ROFL
Да ладно, на сайте голанга тоже самое, только про негров.
Раст тоже мало где используется. Может это языки родные братья?
Тут надо смотреть на производную по времени, и тогда видно, что совсем нет.
> рекламу сомнительной политической организации?Видим мутное НВЛП на флаге. Правильное движение -- слева направо. Сравните с антилопой GCC на той же странице.
>Странно но D за двадцать лет так и не получил популярности.Уж очень на С++ похож.
На последнем пишут от безысходности и легаст, никому второй не скучный С++ не нужен.
>Сайт Дланг точка ру, лол там совсем обкурились? вершки картотфеля курите? А чо, говорят вставляет нехило.Что видит анонинм на сайте посвященном языку программироания? рекламу сомнительной политической организации?
А что там за организация такая?
Вроде норм с виду православненькое что-то.
Вот это как раз не странно. К сожалению, сам в своё время наступил на эти грабли. Язык, на первый взгляд, неплохой. Но когда начинаешь вникать, становится видно, что разрабатывается он несколько бессистемно, без надёжного костяка computer science. Сплошной ad hoc, короче. Ну и когда в 2021 году чуть ли не каждый changelog содержит исправления регрессий, вера в будущее языка несколько снижается с каждым релизом. В общем, начиналось всё серьёзно, а в итоге всё делается спустя рукава.
> н Но когда начинаешь вникать, становится видно, что разрабатывается он несколько бессистемно, без
> надёжного костяка computer science. Сплошной ad hoc, короче.Это про С++ что-ли?
А про C++ это надо умножить на 3.
Про сайт никто ничего не говорил, а только о группе в телеграме.
Официальный сайт - dlang.org
Паскаль вернулся с засенной набок челкой и модном шмоте
модном в 1970-х шмоте
Дай угадаю: ты увидел оператор := и поэтому вспомнил Паскаль?
Прорвёмся! Опера!
> unsafe - unsafe.Add и unsafe.Slice для безопасных арифметических операций с указателями и безопасного преобразования указателей в срезыА они точно безопасные? Звучит как будто бы не особо..
Когда дженерики завезут?
В версии 2.0
В версии 1.18, которая запланирована на февраль 2022
Без дженериков ты кодить не умеешь, да.
Он умеет только с.
Уже подвезли: https://github.com/mattn/go-generics-example
Кстати, а вы знаете, я использую арч линукс на десктопе!!1Так ещё и не просто арч с каким нибудь кде, а arch+i3wm!!11
ну как вам??7
Больной yблюдок.
Я конечно знал что ты конченый, но не знал что настолько.
Дай думаю гляну на (не буду рекламировать биржу, но она одна из крупнейших международных) вакансии для голанг и как он вообще востребован, но то ли искал не там или вводил не то, но никто го разработчиков не ищет. Для js например отдельная категория из 9999 вакансий. Про другие смежные разделы где так же требуются js разработчики умолчу, о чем можно говорить, если js это полный стек. Честно говоря я этого не ожидал, даже для dart+flutter есть вакансии, а го нет.
Искал не там. В Москве нормальный Го-шник найдёт работу на раз-два: Mail.Ru, Yandex, Ozon, Avito, Lamoda, Joom, AliExpress - это только про кого лично знаю, что ьам многочисленные команды с Go.
> Mail.Ru, Yandex, Ozonкто в эти помойки в здравом умей пойдет работать?
Помойка у тебя в голове, а эти компании дают рабочие места с достойной оплатой за свой труд. Эти компании ничем ни лучше и ни хуже своих конкурентов.
Чето ор, достойная оплата может только у суперархитектора сеньора. В среднем там сильно меньше рынка для просто программиста, оно и понятно дефицита в кандидатах у них нет.
> достойная оплата может только у суперархитектора сеньораА ты хотел, чтобы тебе, джуну-неумехе, за которым глаз да глаз нужен, столько же платили?
Так и зачем тебе к ним идти? Есть сильно более лучшие компании. Это все равно что среди аудиторов считается плохим идти в большую четверку.
Если ты про интернов и всякие другие летние стажировки то им вообще ничего не платят или совсем символично. Эти компании могут себе позволить выбирать из опытных кандидатов и выбрать того кто просить меньше. Но опять же это характерно для всех больших компаний.
Дефицит в кандидатах везде есть в той или иной мере. Но, конечно, высококвалифицированного специалиста найти намного сложнее. В крупных компаниях эту проблему решают единственным возможным для них способом - наймом большого количества не особо квалифицированных кадров. Потому что деньги есть, а кадров нет, да.В одной ныне немаленькой компании, где я работал, когда она еще была стартапом, сейчас порядка ста человек решают по факту те же задачи, которые мы тогда решали командой в 12 человек.
Особенно печально, когда работает и делает результат кто-то один, а остальные десять человек просто для мебели. На ЗП это конечно же не сказывается.
Это именно что помойки, обслуживающие власть и цензуру в стране.
У go несколько неподходящее название для поиска, потому его на биржах почти всегда пишут как golang.Не знаю, где вы искали, но та том же upwork вакансий дофига.
Работаю исключительно на Go с 2013. Текущая зарплата у меня 700к.
А я на расте. Зп 1300к
Вроде бы заявлялось, что под Go нет работы. Причём тут Rust.
Надеюсь на расте написан?
Надежды вьюношей питают - надейся
[Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python]Ну вот откуда из вас это лезет?
>> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка PythonНу вот откуда из вас это лезет?
Из википедии, учите матчать, молодой человек https://en.wikipedia.org/wiki/Go_(programming_language)#History
Согласен, го как перл, нечитабелен.
Нет связи ни с С ни с питоном.
> Синтаксис Go основан на привычных элементах языка СиИ зачем если есть Си. Ах да, макакам.
Это не нужно уже есть раст