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

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2809r1.html

Вот тут предложение убрать это поведение из С++. Оно пока не принято, насколько я понимаю. В нём подробно расписано, почему это UB со ссылками в стандарт.

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

Если встречается конструкция наподобие приведённой выше, то компилятор имеет право её выкинуть или ещё что-нибудь прикольное сделать.

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

но это совсем не прояснило что

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

Стандарт упомянутый ранее используется во всех современных системах и ЯП. Он и определяет как считать быстро, но не точно.

так это ошибка, какое же это UB если side-effects нет?

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

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

Вот эта программа печатает Hello, World!

#include <iostream>

int main() {
  while (true)
    ; 
}

void unreachable() {
  std::cout << "Hello world!" << std::endl;
}

Неужели ещё нужно что-то доказывать?

компилятор имеет право её выкинуть

так это UB компилятора, a не языка как такового. Сам код - не UB.

У меня мозг взорвался. Что такое UB компилятора? Это какой-то новый термин в C++? :)

Это совершенно другой код, кого вы пытаетесь обмануть?

Мы говорим о

int main(void) {
  while (true) {}
}

ммм, пробуйте думать, это больно поначалу, потом легче пойдёт.

Я не про панику, как таковую, а про неконсистентность и false advertisement.

Rust продают как самый самый самый, где компилятор бьёт всех по рукам, если одну и туже переменную 2 раза прочтёшь. И где вообще невозможно писать неправильный код. А на деле…

Возьмём для примера

    let v: [u8; 10] = [0u8; 10];
    let _x: u8 = v[100];

тут мы падаем уже при компиляции с

3 |     let _x: u8 = v[100];
  |                  ^^^^^^ index out of bounds: the length is 10 but the index is 100

И далее для сравнения

    let v: Vec<u8> = vec![0u8, 10];
    let _x: u8 = v[100];

а тут мы уже падаем аж в ран-тайм

thread 'main' panicked at src/main.rs:3:19:
index out of bounds: the len is 2 but the index is 100

Хотя как в первом примере, всё везде константы. Всё везде известно.

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

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

Но так и не могу уяснить связь с

Языков без багов не существуют

PS: маленькая очепятка – во втором примере хотел показать vec![0u8; 10], но это сути не меняет.

Всё везде известно.

вы троллите что-ли? Это же вектор, у него неконстантная длина, она НЕ известна на этапе компиляции.

И где вообще невозможно писать неправильный код.

сам сочинил, сам опроверг

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

Если и там не поймёте объяснение на русском, то обезьян бессилен помочь.

Это тоже. Бесят все эти where, которые приходится вешать на все методы, потому что trait в структуру не засунуть. Но скорее всего это я готовить не умею.

impl<B, RS, RW, E> DrawTarget for Display<B, RS, RW, E>
where
    B: OutputBus<Word = u8>,
    RS: OutputPin,
    RW: OutputPin,
    E: OutputPin,
{
    type Color = BinaryColor;
    type Error = core::convert::Infallible;
    fn draw_iter<I>(&mut self, pixels: I) -> Result<(), Self::Error>
    where
        I: IntoIterator<Item = Pixel<Self::Color>>,
    {
        for Pixel(_coord, _color) in pixels.into_iter() {}
        Ok(())
    }
}

impl<B, RS, RW, E> OriginDimensions for Display<B, RS, RW, E>
where
    B: OutputBus<Word = u8>,
    RS: OutputPin,
    RW: OutputPin,
    E: OutputPin,
{
    fn size(&self) -> Size {
        Size::new(128, 64)
    }
}

Но скорее всего это я готовить не умею.

Проблема не в вас, это точно.

Так с числами разобрались же вроде, благодарю вас за помощь.

Не объяснённым остался момент

Языков без багов не существуют

а на голанге как этот код будет выглядеть?

это не его достоинства, а скорее пороки конкурентов

популярность никак не связана ни с качеством объекта популярности ни с качеством альтернатив

Не объяснённым остался момент

Языков без багов не существуют

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

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

так это ошибка, какое же это UB если side-effects нет?

это UB в их понимании. хотя сайд эффекты таки есть. часики-то тикают!

Языки оперируют числами используя стандарт с багами

Объясните пожалуйста, какой баг в стандарте IEEE 754?

хотя сайд эффекты таки есть. часики-то тикают!

Так какой же это сайд эффект если это именно то для чего код запускался?

Все-таки зря в технических ВУЗах основы логики не преподают.

Объясните пожалуйста, какой баг в стандарте IEEE 754?

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

В 2008году его подкорректировали тк уже было просто неприлично тянуть. Затем в 2019м. С тех пор прошло 6 лет и необходимость корректировки опять назрела. Так понятнее?

Так понятнее

Нет, из этого сообщения мне не удаётся понять о каких багах в стандарте IEEE 754 вы ведёте речь.

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

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

Из этого сообщения мне не удаётся понять о каких багах в стандарте IEEE 754 вы ведёте речь.

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

Если и так непонятно, то извините, мы не можем быть вместе, не расстраивайтесь, дело во мне, а не в вас. Я не люблю атаки тупостью.

чисто голанговские концепты (говнорутины, каналы или что там еще они выдумали)

С каких это пор корутины и каналы это чисто голанговские концепты? С кем я сижу на одной борде? (с)

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

я не выбирал, его выбрал за меня концорциум производителей оборудования.

Вы выбрали оборудование, которое оперирует числами с плавающей точкой, определёнными стандартом IEEE 754. Вопрос остался открытым. В чём баг?

Другого оборудования нет, не существует. Выбора нет.

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

корутины и каналы

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

Я согласен, что все эти where очень многословны, но если ты откроешь проект на TypeScript или питоне с аннотациями типов, то там абсолютно все тоже самое и даже хуже, т.к. в конечном итоге это вообще не обеспечивает типобезопасность) На счет того, что Trait в структуру не засунуть, тебе случайно не Box<dyn Trait> нужен?

Ну а баги стандарта IEEE 754 в чём?

недостаточной точности двоичной арифметики описанной стандартом

возможно ли располагая тем же числом разрядов обеспечить представление чисел с большей точностью и более точные вычисления над ними?

PHP <-> Go <-> Clojure

На практике бывает и так: Go -> Java -> нет, всё-таки Go.

Вообще, меня удивляет как вроде бы специалисты на серьёзных щщах могут рекомендовать языки без сборщика мусора а-ля rust для работы в режиме микросервисов 24/7/365.

Микросервис в контейнере. Как только он выжирает память, то перезапускается. Вот и всё. Сборка мусора с долгим циклом. Нужно просто ограничить ресурс поду (= настроить сборщик мусора).

Объясните пожалуйста, какой баг в стандарте IEEE 754?

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

С тех пор прошло 6 лет и необходимость корректировки опять назрела. Так понятнее?

Нет, по-прежнему ничего не понятно.

недостаточной точности двоичной арифметики описанной стандартом

IEEE 754 quadruple-precision binary floating-point format: binary128
The IEEE 754 standard specifies a binary128 as having:

Sign bit: 1 bit
Exponent width: 15 bits
Significand precision: 113 bits (112 explicitly stored)

На что конкретно тебе не хватает 128 бит плавающей точки?

С тех пор вычислительные мощности немного выросли так сказать.

Вычислительных мощностей хватало еще в прошлом тысячелетии:

IEEE quadruple precision was added to the IBM System/390 G5 in 1998, and is supported in hardware in subsequent z/Architecture processors. The IBM POWER9 CPU (Power ISA 3.0) has native 128-bit hardware support.

Но человечество решило «нафик-нафик».

Микросервис в контейнере. Как только он выжирает память,

У него был прямо противположный поинт:

языки без сборщика мусора

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

Афигеть, сейчас бы говорить про «устаревание» стандарта и недостатки точности, когда теперь вход пошил fp16 и даже bf16 (который гарантирует точность двух значимых чисел) =)

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

Как вы озаботились задачей образовывать меня. Очень приятно, но такой просьбы не было. Был вопрос, о каких багах стандарта IEEE 754 вы так настойчиво толкуете?

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

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

Горутины это легковесные потоки (LWP) которые ещё в System V были. Они же зелёные потоки в JVM.

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

Вы там походу в каком-то одном языке стагнируете раз для вас это какие-то новинки.

Вы атакуете тупостью, ответ вам дан, что главные ошибки в стандарте связаны с ошибками округления. Вы ответ не понимаете, я ответил более развёрнуто, с ссылками. Вы опять не поняли, ну F тогда.

На этом я с вами закончил. Возвращайтесь как эволюционируете.

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

Афигеть, сейчас бы говорить про «устаревание» стандарта и недостатки точности, когда теперь вход пошил fp16 и даже bf16 (который гарантирует точность двух значимых чисел) =)

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

Обучают по прежнему с нормальной точностью. Короче, исключение подтверждающие правило.

Нет, не ответили. И, похоже, очень расстроились.

Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1 + 0.2
0.30000000000000004
>>>

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