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

ты не лучший объяснитель вещей

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

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

Остальные давно поняли о чем речь и перестали спорить, копнув вопрос.

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

Мы говорим о проблеме float-ов в стандарте IEEE-754. Один из двух оставшихся хомо эректусов на голубом глазу пытается подсунуть from decimal import *.

то что есть софт/библиотеки/типы которые интовыми инструкциями всё могут посчитать это и так всем понятно

этот пример ничего не доказывает, как и следующий и int

jshell> (2147483647 * 2) / 2
$21 ==> -1

jshell> 2147483647 * (2 / 2)
$22 ==> 2147483647

как впрочем и контр-примеры, очевидно не использующие float

C-style arbitrary precision calculator (version 2.15.0.6)
; (0.1 + 0.2 - 0.3) * 10**17
	0

Кроме нашего хвостатого друга - он утверждал прямо обратное.

Мы говорим о проблеме float-ов в стандарте IEEE-754.

И за 150+ постов мы пока нашли только одну проблему - ты слишком туп, чтобы понять, как они работают.

я тешил себя надеждой что вы поняли что речь о float.

если я правильно понял, он изначально говорил о float, чтобы считать процессором. ты же понимаешь, что несмотря на то, что «проблемы» такой нет - просто не используй float а считай «программно» (в SQL есть, даже в php есть, C# это вообще встроенный value type), всё же например C код считающий через какой-нибудь gmp (хотя я не сравнивал) может оказаться медленнее такового на float/double, особенно если последний векторизовался. а тут нам говорят, что тот же код якобы на самом деле мог бы считать точнее.

да и дефолтом в большинстве языков является не decimal или arbitrary precision библиотека, а float: литерал 1.5 - в большинстве языков это float. вроде в lua вообще все нумерические литералы это float (и еще в каком-то языке так же сделано)

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

По существу моего примера вам возразить нечего ведь я наглядно показал проблему float-ов в стандарте которые на текущем уровне развития оборудования уже заметно так улучшив добавив проверок в граничных диапазонах. Причем - эта проблема известна с момента принятия первой версии стандарта и не была исправлена на тот момент из-за недостаточной скорости работы ALU. Такой баланс скорость-точность вычислений на тот момент считался оправданным, в наше время - уже нет.

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

Обезъян желает вам эволюционировать. Обнял, покружил, поставил на место.

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

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

Я привел максимально наглядный и известный пример. Можно привести еще бесконечное количество подобных. Думал, что начав гуглить (0.1+0.2-0.3) люди сразу найдут о чем речь и успокоятся, но нет, позориться - так до конца.

Им теперь только пароль выкладывать после такого.

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

я например тупой и сам не смогу за пределами совсем простого «вынеси за скобки» как в том примере. то есть если там и можно вероятность проблемы снизить, то я могу надеяться только что gcc/jvm за меня это сделает (и что не сделает наоборот). но оно не сможет, потому что даже видя «формулу» не знает, что там будет в рантайме.

у меня был код на C где разница типа 0 / 5.5511 повлияла бы по крайней мере на визуальный результат (возможно та программа работает неправильно, но конкретно в ней ничего критичного). причем программа считала два часа на питоне и после переноса функции в С стала считать 30 секунд, то есть decimal/gmp там «не канает». от любой дополнительной точности float (за небольшую цену) в той программе я бы точно не отказался

Вы в очередной раз проигнорировали ключевой момент:

разумеется, мы все ожидаем, что ты говоришь о числах в формате IEEE 754, а не распечатке в ASCII хрен пойми откуда взятых десятичных дробей

Пожалуйста, продемонстрируйте над какими величинами в формате IEEE 754 производятся вычисления в этих выражениях, а затем покажите почему вы считаете эти две последовательности вычислений тождественными.

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

Я рад что вы поняли, но мне казалось что вы поняли это сразу или практически сразу, судя по вашим ответам.

у меня был код на C

у меня тоже, в том числе и тот который через CUDA работает на видеокартах и где порядки, бывает, доходят до 2^256 со всякими реализациями BIG NUMBERS. При таких расчетах появление значений «около нуля» интервал (0,1) приводит к лавинообразному накоплению ошибки. Приходится стараться разделять примерно как вы описали, но это не всегда возможно. Если тема вам интересна, могу предложить ознакомиться с вот этим.

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

Я с вами закончил. Перечитывайте тему сначала до полного просветления.

если я правильно понял, он изначально говорил о float, чтобы считать процессором.

Это не существенно.

(0.1 + 0.2 - 0.3)
Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

а следовательно нет мотивов чистить мусор в младших разрядах при его превращении в десятичную строку.

Проблема в непонимании простейшей школьной математики, уже всё сказано раз два.

При преобразовании любой "обычной" по одному основанию дроби в дробь по другому основанию, будет вероятность получения бесконечной дроби. И тут "точность" расчётов (про которую тут распинается наш хвостатый друг) не имеет вообще никакого значения. Сколько бы битов ты не насыпал, в конечном итоге дробь придётся округлить на последнем знаке. Соответственно гарантировать, что расчёты в дробях по одному основанию дадут идентичные результаты после конвертации в дроби с другим основанием в принципе нельзя. Ни основания дробей, ни размерность чисел значения не имеют.

Именно это происходит с конвертацией десятичного 0.1 в дробь по основанию 2.

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

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

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

Вынос за скобки и прочие алгебраические преобразования вообще тут не при чём. Алгебраическими преобразованиями можно вообще много чего сделать, но это (пока) не задача арифмометра.

(0.1 + 0.2 - 0.3)

Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

Не надо извращать мои слова.

Обезъян пытался объяснить что давно пора добавить доп проверки которые проверяют появление слишком отличающейся разрядности (вверх, вида 10^17 или вниз, в ситуации наоборот) в ряду операндов около нуля и преобразует выражение замедляя! таким образом накопление ошибки.

Для замедления накопления ошибки в 2008м году добавили FMA (fused multiply-add) и обозвали обновленный стандарт: IEEE754-2008 Это позволило снизить накопление ошибки. В будущем стандарте будут еще подобные улучшения и проверки.

Ну прочитайте хоть про FMA, ну нельзя быть такой бестолочью. Ай все, нафиг.

Вы так резво сыпете демагогическими уловками, что приходится уже отгадывать, какой же из выдвинутых вами тезисов вы сейчас пытаетесь отстоять:

• вы знаете некие «баги» в стандарте IEEE-754

• эти «баги», мешающие получению достаточной точности арифметических вычислений, никаким ЯП не победить

Пока что ничего убедительного представлено не было.

Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

Не надо извращать мои слова.

Чувак - это литерально цитата тебя буква в букву.

давно пора добавить доп проверки

Нет, не пора. Потому что тогда воспроизводимость арифметики полетит к чёрту. Загугли, зачем в жаве ключевое слово strictfp.

которые проверяют появление слишком отличающейся разрядности

И каков будет численный критерий «слишком»? На глазок? Примерно так почувствовать?

Не высокая точность операций между находящимися на разных по порядку концах представимого спектра чисел будет проблемой в любой размерности системах с плавающей точкой - это арифметическое свойство самой системы. Совершенно не понятно, с какого хрена вот прям именно сейчас её ВНЕЗАПНО надо почему-то "решать".

и преобразует выражение

А разложение суммы квадратов еще, случайно, делать не надо?

Ну и да, ловко ты переобуваешься с тезиса на тезис по ходу пьесы.

он не берет планку достигнутую десятилетие до него и ничего не упрощает

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

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части, дисциплина обработки ошибок сведена к бюрократии.

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

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

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

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

они придумали модель памяти которая проще для восприятия и чем джавовская и смогли сами ее соблюсти?

Что не так с моделью памяти? https://go.dev/ref/mem

[«Go создал Гугл для себя»] это маркетинговая болтовня не более

…

голанг вообще не создавался чтобы быть хорошим языком или даже чтобы на нем писать код

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

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

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

gcc -fanalyzer

Недавно общался с разрабом, он работал в Яндексе, Ozon. В целом неплохо отзывался о Go, пишет в основном на нем. Рассказывал про фишку что можно Go запустить и без сборщика мусора. Это может быть полезно, если ваше приложение живет какое-то определенное количество часов каждый день (биржа какая-нибудь) и память за это время вся не успевает забиться. Работать сервис будет быстрее, потому что такты ЦПУ не будут тратиться на сборщик мусора. Но в большинстве случаев наверное это трэш)