Golang в крупных проектах возможен (back)?

Не вижу здесь проблемы. Всё в полном соответствии стандарту.

Ну, на нет и суда нет.

Её отсутствие станет очевидно и вам, если вы выведете не только представление результата операции, но и операндов. Как представил 1/10 и 2/10 интерпретатор.

Если вы считаете, что 1/10 + 2/10 равняются 0.30000000000000004, то у меня к вам нет никаких вопросов.

Конечно писать на таком языке будет не очень удобно, как мне кажется

На Паскале неудобно писать?

походу в каком-то одном языке писал на php, на python, на java, немного писал на C.

Желательно конечно знать, а не догадываться.

я не скрываю, что ни строчки не написал на нем.

ты удивишься, но можно и догадываться. желательно, конечно знать, но догадываться тоже можно.

в отличие от 99% апологетов голанга я в многопоточном программировании и его проблемах хотя бы что-то понимаю.

Горутины […] Они же зелёные потоки в JVM.

грин-треды в java существовали пару лет в конце 90х и были заменены нормальными тредами. с таким же успехом ты мог бы сказать, что грин-треды в жаве - это те же самые нормальные треды, а нормальные треды - это те же самые горутины в голанге. твои высказывания, как всегда, очень приблизительны и очень поверхностны.

Каналы это просто пайп

«просто пайп» не смог бы быть полезен в многопоточном программировании. как не смогла бы например «просто очередь».

Банки-пылесосы тоже получали лицензию, и тоже «имитировали следование процедуре», служа прокладкой «вполне конкретным»(тм) выгодоприобретателям.

Конечно, банк может вести себя недобросовестно, но это а) жесткая уголовка б) не зависит от того, на чем написана бухкнижка.

Еще раз:

не зависит от того, на чем написана бухкнижка.

Разговор в треде был в этом ключе, а не как защититься от мошенников.

нет никаких вопросов

Это вы зря.%)

Интерпретатор python заботливо округляет для вас результаты при выводе, а внутри у него:

1/10 => 0.1000000000000000055511151231257827021181583404541015625
2/10 => 0.200000000000000011102230246251565404236316680908203125
        результат сложения после округлений:
        0.3000000000000000444089209850062616169452667236328125

а если так сделать:

>>> print(0.1 + 0.2) 

?

На Паскале неудобно писать?

Подумал сейчас, что родной редактор турбопаскаля, такой весь ламповый и няшный, это же тихий ужас по сравнению да хоть с вимом. Да, нифига неудобно

Go создал Гугл для себя, тк тысячу индусов Пишущих на С++ в сотня проектах постоянно лажали с правилами написания многопоточных приложений. В итоге они сделали свой упрощенный С++ вшив в него правила написания кода требуемый Гуглом. Буквально, программа не соберётся если где-то объявлена, но не используется переменная.

То что Go стал популярен показывает что остальные С++ программисты недалеко ушли от индусов и такой унифицированный подход с жёстко вшитыми алгоритмами решения распространённых сетевых и многопоточных задач - работает.

Другими словами Go такой из-за его основной аудитории, а не аудитория такая из-за языка.

вы выдали тезис, я опроверг его, вы согласились с тем что это все было уже. И как с вами спорить?

Ну так это же хорошо когда ЯП создается для людей.

P.S. На самом деле его создавали последователи Оберона/Модулы.

Ну так это же хорошо когда ЯП создается для людей.

Инженерия вообще отличается от естественной науки тем, что в ней нет ничего богом данного, всё что существует в инженерных дисциплинах создано людьми и для людей. И в этом плане очень странно видеть людей сознательно отвергающих простые и удобные инструменты в пользу каких-то кадаврический мозголомных порождений хаоса, вроде хаскеля, где за освоение только терминологии можно медаль давать, и аргументируется сей выбор какой-то обкуренной философией, что вообще ничего общего не имеет с задачей инженера решать задачи согласно ТЗ.

А го хороший, в нём нет непонятный вещей.

ты там выше утверждал, что пример кода показывает что «главное - читабельный и понятный.» вот этому утверждению я возразил.

кроме того, я спорю с широко распространенным мнением (ты этого не говорил, действительно), что голанг - это, якобы, хороший язык, и он, якобы хорошо приспособлен для конкурентного программирования.

я не писал ни строчки на нем, но утверждаю, что это убогий язык с кривым дизайном, плохо приспособленный для конкурентного программирования. голанг не просто «не хороший», он может даже взять планку достигнутую до него другими «простыми языками».

Существует теорема, которая утверждает, что для перемножения двух чисел n разрядов, нужно не менее 2n разрядов. Отсюда следует, что даже умножение целых чисел с произвольной точностью не реализуемо в условиях аппаратных ограничений.

Скажите пожалуйста, видите ли вы тут какую-то проблему или же всё в порядке?

Ты сменил тему. Вопрос был не про наличие погрешностей при преобразовании десятичных дробей в двоичные, а в наличии бага в стандарте IEEE 754:

какой баг в стандарте IEEE 754?

Никто никакого бага в стандарте в этом ITT-треде пока не привёл.

Детсадовское нытьё про расхождения с вычислениями в десятичных дробях даже обсуждать нет смысла.

У вас с оппонентом терминологические расхождения относительно понятия «баг». Он считает, что баг стандарта, это если используя стандарт можно выстрелить себе в ногу, вы считаете что если выстрел а ногу документирован, это не баг. Договоритесь о терминах, что вы как эти

когда ЯП создается для людей.

Для индусов. С конкретным менталитетом «Do you understand? Yes. (он не андерстенд)»

Go буквально не даёт выстрелить себе в ногу (ладно, даёт, но ограничено).

О, спасибо, именно это и имел ввиду.

возьмем три строчки из того файла:

ln.mu.Lock()
ln.channels = appendIfNotExists(ln.channels, channels...)
ln.mu.Unlock()

1. почему в языке якобы хорошо приспособленном для конкурентного программирования, лок захватывается вручную? в языке нет синкронайзед блоков? нет синкронайзед методов? ок, они так решили. но чем это лучше в сравнении с prior art в лице банальной джавы, сишарпа? ничем. чем это «понятнее»? ничем.

2. почему в языке якобы хорошо приспособленном для конкурентного программирования, лок отпускается вручную? все те же вопросы из пунка 1. этот язык слишком прогрессивен чтобы делать как принято в индустрии? язык слишком особенный?

3. кто отпустит блокировку если вызов appendIfNotExists привет к панике или как там оно у них называется? ну раз синкронайзед блоки не хотят, то может быть тогда try-with-resource/context-managers? ок, возможно в голанге какая-то своя магия, но может быть тогда блок finally? в языке есть блок finally? лок-то кто отпустит?

4. далее мы видим проверку ошибки из каменного века и понимаем, что паника из appendIfNotExists() рассматривается автором как невозможная в принципе. наверное этот голанг как-то это гарантирует (он же язык прогрессивный), и автор об этом знает откуда-то, хорошо, ок. но я бы не сказал, что это «читабельный и понятный» язык.

5. после проверки видим return и тут возникает догадка (всего лишь догадка!), что блокировку автор отпустил сразу же после вызова не только потому что он молодец и старается ее долго не держать, а потому, что нет механизма ее автоматического снятия (и плюс синтаксического воплощения этого механизма). и если он не снимет ее сразу, то он либо ошибочно забудет ее, либо ошибочно снимет дважды, либо таки соорудит что-то в духе goto на хвост функции (всё новое - это хорошо забытое…). возможно я не прав, и всё тут совсем не так работает и вообще по другому развивается, но тогда за этим кодом стоит слишком много неявных, частных семантических аспектов или даже «магии». ну или может быть просто этот язык не взял планку, которую взяли очень многие, включая дубовую жаву.. лет так примерно 20 назад.

6. если бы между захватом и отпусканием менялось состояние доступное за пределами этой функции, то чтобы его можно было корректно прочесть, нужны SA. и вероятно здесь они лок/анлок.  
    
   далее я вынужден признать, что буду говорить на основании полузабытых и возможно ошибочных воспоминаний.  
    
   как-то я пытался этот вопрос относительно голанга выяснить, и обнаружил, что у голанга вместо модели памяти документ, суть которого сводиться к «ничему». то есть если жава годами над этим билась и смогла, и по сей день тратит ресурсы на это, то голанг считает, что он особенный. нет, не по техническим причинам, а просто потому что они сами для себя сделали исключение. ну действительно зачем ее формулировать, потом гарантировать ее соблюдение, тратить деньги на это, да еще и на нескольких платформах. пусть будет всё через гонку, пусть программы будут потенциально сломаны или сегодня корректны, а завтра сломаны. там в тексте конечно не так было написано, но по итогу-то оставалось именно это.

это убогий язык, который сильно не соответствует своему имиджу, авторы которого сделали говно и предпочитают не признавать ошибки и не решать проблемы, а забалтывать их, убеждать программистов в том, что это не проблемы вовсе. проект в значительной степени обязанный своему успеху маркетингу, хайпу, зомбированию и intellectual dishonesty - не редкость вовсе, просто в данном случае это не фреймворк какой-нибудь, а аж целый язык программирования.

Ну конечно же именно это. Никаких сомнений. Зато какой портрет выразительный получился. %)

я уязвим для атак тупостью - проф деформация.

С кем не бывает. Крупный, огромный, выдающийся примат — мастер арифметики и численных методов. И крошечный, малюсенький, ничтожный бамболео, который даже никто не замеил.%)

насколько я понимаю, в голанге, как в си. нет исключений, а ошибка обрабатывается ручками. и функция или гарантировано вернется, или все упадет намертво с необходимостью перезапуска процесса.

впрочем в голанге есть довольно костыльный defer - то есть оператор отложенных действий.

серьезно достает отсутствие таймаутов у средств синхронизации. потому что без таймаутов просто невозможно написать устойчивый код.

да я не против. я только за языки которые на себя берут сложность, всё проверяют, облегчают труд и т.п. проблема в том что почти всё что говорят о го - это маркетинг или вообще ложь, он не берет планку достигнутую десятилетие до него и ничего не упрощает. это если даже не говорить о сломаном дизайне обработки ошибок. откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга? что они вообще лучше работают на практике и их дизайн удачен? что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ? откуда идея о том, что проблемы конкуррентного исполнения на мнопроцессорной машине языку удалось скрыть при этом оставив программы корректными? кем это было доказано? они придумали модель памяти которая проще для восприятия и чем джавовская и смогли сами ее соблюсти? этого нет. они изъяли из всех процессоров мира кеши, реордеринг, спекулятор?

Go создал Гугл для себя, тк тысячу

это маркетинговая болтовня не более. там еще была байка про автора голанга беседовавшего с коллегой, удивившегося очередному усложнению с++ и вдруг решившего создать голанг. групировки конкурируют, уничтожают друг-друга. всяким там вайспрезидентам или как их называют нужно усиливать свое влияние, интриги, разводить активность, выбивать деньги, больше подчиненных. голанг не создавался «гуглом для себя». голанг вообще не создавался чтобы быть хорошим языком или даже чтобы на нем писать код. не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать». голанг всего лишь наполнитель этой внутригугловской политической конкуренции. качество этого наполнителя, его полезность не сильно влияет на успех группировки. пытаются усилить свое влияние вероятно многие, наверное даже с хорошими проектами и полезными (но мы о них не узнаем). вот у этой группировки получилось, а в качестве проекта у них там рядом оказался голанг.

вы так и не поняли, у меня испанский стыд от вас все это время.

Точно не португальский или может, мексиканский. А то вдруг опять в терминологии случайно запутался.%)

всё что говорят о го - это маркетинг или вообще ложь

это хайп. точно также как хайп вокруг js/ts. Хорошие ли это языки? Да нет конечно. У них нет такой задачи, они массовые и простые.

Go создал Гугл для себя

это маркетинговая болтовня не более

Нет, Go создали сотрудники гугла, на деньги гугла и для решения проблемы гугла индусы vs C++. Весь хайп и маркетинг тоже за счёт гугла тк чем популярнее язык тем больше спецов на рынке его уже знают.

Гуглу давно не нужны творческие спецы, ему нужны обезьянки могущие работать с сетью и многопотоком чтобы потом все приложение не крашилась (потому Go).

Это подход когда тысячи макак пишут 100 проектов из которых один становится коммерчески успешным, после чего гугл его масштабирует и таким образом окупает 99 неудачных. Буквально - принцип посевного финансирования только в разработке По.

Это подход когда тысячи макак пишут 100 проектов из которых один становится коммерчески успешным, после чего гугл его масштабирует и таким образом окупает 99 неудачных. Буквально - принцип посевного финансирования только в разработке По.

Как это разительно отличается в худшую сторону от благословенной кложы, когда нет ни задач, ни проектов, ни финансирования, ни коммерческого успеха, ни тулинга вменяемого, зато есть гомоиконичность (да простит меня Говинда) и скобочки.

Чтобы потроллить меня вам надо бы сначала обсохнуть. Что довольно сложно будет сделать после всех ваших сообщений, так самого себя обдавать тугой струёй это надо уметь :)

У кложи своя ниша, Global Healthcare и все что с ним связано + немного финтеха. Вполне себе денежная и с вакансиями, но ессно не сравнимая с мейнстримными ЯП по количеству вакансий.

Кложа это не CL/SBCL где 0 вакансий.

Об этом наверное лучше расскажет кот, если захочет, а не обезьян.

Нет, Go создали сотрудники гугла, на деньги гугла и для решения проблемы гугла

работники да, на деньги, разумеется. но ты не понимаешь, перечитай сообщение. гуглу этот голанг никогда действительно нужен не был, гугл не считал решением каких-то своих проблем создание нового языка. такая идея не «витала в воздухе», а необходимость не «назревала». в гугле разного рода инициативных проектов сотни. этот проект продвигали вместе с продвижением идеи о его необходимости, продвигали имеющимся политическим весом (чтобы этот вес в конечном итоге умножить) выбивая под него деньги, там по-другому ничего не делается, всё как в обычной фирме.

это сильно не то же самое что «гугл делал для себя», чтобы решить какие-то там проблемы, это вообще общего ничего не имеет.

Об этом наверное лучше расскажет кот, если захочет, а не обезьян.

Да мне как бы и пофигу, если честно, меня замечательно вкусно и питательно кормит мейнстрим. Я как кит (в терминах обозначенного вами зоопарка), надо пожрать - рот открыл и еда сама засосалась. Поэтому я толстый и ленивый, ибо вершина пищевой цепочки. О чем там срется планктон, интерес чисто энтомологический, ну как бы дань вежливости в сторону питательной среды.

вы смогли прочитать и даже немного понять логику кода на го абсолютно не зная его :).

выводы ваши комментировать не буду. они лишены логики и смысла из-за отсутсвия знаний по этому ЯП.

PS: функция appendIfNotExists в том коде не может в принципе завершиться ошибкой или вызвать панику. поймете это, если познакомитесь с этим ЯП

метафорично сформулировано ))

такая идея не «витала в воздухе», а необходимость не «назревала»

У меня другая информация. Считайте как хотите, у меня нет цели вас переубедить.

Кит? Джаваскриптизер что-ли? :)

Он считает, что баг стандарта, это если используя стандарт можно выстрелить себе в ногу,

Ограничение на диапазон представимых чисел не может быть «выстрелом в ногу». При любом ограниченном количестве памяти диапазон представимых чисел ограничен. Это уровень математики в подготовительной группе детского сада, где на палочках считать учат. То есть, это некая базовое положение, которые мы принимаем как априорное, когда говорим о расчётах с использованием фиксированных объёмов компьютерной памяти. Поэтому оно не может быть «выстрелом в ногу» в ничьих глазах, кроме глаз полного наркомана.

Опровергнуть это можно только одним способом - представить способ хранения бесконечного диапазона значений в ограниченной памяти. Желал бы на это посмотреть.

Вы не делаете лучше.

Тут не Баг, тут концептуальный вопрос, насколько языки должны абстрагироваться от железа. Должна ли среда исполнения (интерпретатор) компенсировать работу ALU?

В калькуляторах не проблема, ведь у них 12 разрядный дисплей, double precision хранит 17 знаемых чисел, а значит 0.30000000000000004 там просто не увидеть, калькулятор округлит.

Инженерные/научные калькуляторы будут что-то хитрое использовать, проприетарное, от того бывают калькуляторы от разных производителей считают по разному (на youtube`е можно посмотреть). Наверняка кто-то просто считает на extended double precision АЛУ 80-битные циферки и округляет до количества отображаемых разрядов.

Знаю что в clojure из коробки доступны ratio числа, но кто сказал что рациональные числа важнее иррациональных? Все физические константы иррациональны, но человеку конечно удобнее с рациональными.

Текущее железо все считает степенью двойки, все цифры с плавающей запятой тоже с двойкой в основании. Например пресловутые 0.1 и 0.2 в бинарном представлении кодируются:

       1.<мантисса> * 
             2**<экспонента>
0.1 == 1.6 * 2**(-4)         == 1.6 * 1/(2*2*2*2) == 1.6 * 1/16
0.2 == 1.6 * 2**(-3)         == 1.6 * 1/(2*2*2)   == 1.6 * 1/8

И вот тут это самое .6 из мантиссы записывается в бинарном виде как 10011001100110011001101 потому что первый бит 0.5, а каждый следующий это половинка от предыдущего.
10011 это 0.5 + 0.0625 + 0.03125 + ... в общем получается приближение к 0.6

Если у кого есть java и желание поиграться можете использовать jshell

jshell> System.out.printf("%032d\n", new BigInteger(Long.toBinaryString(Float.floatToRawIntBits(1.5f))))
00111111110000000000000000000000

Есть еще формат decimal32 (о котором на ruwiki вы не найдете инфу) он кодирует числа близко к сайнс нотейшен и он теперь в стандарте IEEE 754-2008. Но у него свои проблемы, там числа не нормализованны, одинаковые числа в десятичной системе могут иметь множество бинарных представлений: 1000000 × 10−2=100000 × 10−1=10000 × 100=1000 × 101 all have the value 10000.

Я не понимаю наезд на текущее железо, все эти числодробилки общего назначения разрабатывались для максимальной производительности за вменяемые деньги, для игрушек, они двигатель торговли! Еслиб не они, не было бы шейдеров, а значит не было бы доступных SIMT вычислителей.
А если кому-то нужна хорошая математика то подключайте соответствующие либы для научных расчетов. К языкам тут может быть только одна претензия – отсутствие поддержки перезагрузки операторов.

Вообразите, что вы написали научную программу, которая долго долбила данные с телескопа или ускорителя и выдала результат, который тянет на нобелевскую премию. Обидно будет, если вместо премии вы получите помойное ведро на голову, т.к. «нобелевский результат» получился из-за набежавших ошибок в арифметике.

Про бухгалтерские программы вообще молчу. Там лучше сразу всё на сто домножить и считать данные в целых копейках.

Всё это очень хорошо. Но всё же хотелось бы узнать чему равняется сумма 0.1+0.2.

Ну вы бы хоть о вариантах округления что используется в стандарте почитали бы. Узнали бы о так называемом сдвиге (shift), происходящем при округлении положительных и отрицательных частей, о проблеме округления около нуля с обеих сторон к ближайшем честному и нечетному и прочих радостях засунутых в стандарт IEEE754.

Вы же вообще не понимаете что разговор вообще о другом.

Алгоритмы работы со значимой частью (мантиссой) в стандарте имеют косяки, поэтому внезапно при сведении баланса вылезшая лишняя копейка - это «норма».

Более того, если бы вы почитали стандарт то оказалось бы что по нему NaN - не только сортируемо с числами, хотя не число, но и является больше бесконечности в обе стороны, буквально:

−NaN < −Infinity; +Infinity < +NaN

И js, над которым все ржут как над недоязычком с его NaN внезапно оказывается просто соответствующим этому стандарту…

«Не число» сортируемо с числом и больше его. А чего буквы с числами не сравниваем? Они же тоже не числа.

Ладно, это все бестолку - не в коней корм.

При чём тут паскаль?

Наконец-то, человек понимающий тему появился.

Я не понимаю наезд на текущее железо

Ну, железо развилась так что мы пересели с 32 на 64 бита. Лично я считаю что оно также уже развилось до того чтобы подчистить всякое в стандарте и перейти на большую точность и меньшие ошибки округления по-умолчанию при прочих равных.

Я понимаю что это не быстрый процесс и скорее всего так и будет в каком-нибудь IEEE754-2029, но сейчас это похоже не очевидно никому на ЛОРе. А ещё вроде специалисты, тьфу.

К языкам тут может быть только одна претензия

К ним в этом плане нет претензий, тк правила игры (стандарт) придуманы не ими.

Go существует для неосиляторов Java и дело даже не в ООП.

Нормальный человек выберет C++/Rust/Java/Python под задачу, но не распиаренный недоязык.

Жду появление Golang-а на killedbygoogle.com.

P.S. Почему вместо Go не взлетел Kotlin - это для меня загадка.

Читаю wiki:

• The IBM 650 computer supported an 8-digit decimal floating-point format in 1953.
• Wang VS machine supported a 64-bit decimal floating-point format in 1977.
• Motorola 68881 supported a format with 17 digits of mantissa and 3 of exponent in 1984
• Motorola 68040 processor providing a compatible 96-bit decimal floating-point storage format in 1990
• IBM POWER6 and newer POWER processors include DFP in hardware
• Fujitsu also has 64-bit Sparc processors with DFP in hardware

Знаешь что всех их объединяет? Они в списке исчезнувших неудачников :) Intel и ARM решили не ходить туда.

Извините я вас не совсем понимаю. Вы что реально думаете что 1/10 это и есть 0.1?

Для кого то это магия ;)

>>> p = 0.1
>>> print('%.32f' % p)
0.10000000000000000555111512312578
>>> 

Вообразите, что вы написали научную программу, которая долго долбила данные с телескопа или ускорителя и выдала результат, который тянет на нобелевскую премию. Обидно будет, если вместо премии вы получите помойное ведро на голову, т.к. «нобелевский результат» получился из-за набежавших ошибок в арифметике.

Погрешности есть в любом процессе. И у телескопа датчики работают с погрешностями. И компьютер вычисляет с погрешностями. Любой адекватный учёный это всё учитывает. Основы этого даже студентам преподают.

Про бухгалтерские программы вообще молчу. Там лучше сразу всё на сто домножить и считать данные в целых копейках.

Бывает, что и доли копеек нужны. Код, связанный с деньгами, лучше программировать на BigDecimal-ах, с явной спецификацией округлений во всех случаях, где это надо (деление и тд), причём это округление должно быть письменно согласовано с ответственными лицами, т.к. зачастую оно обусловлено законодательными требованиями.