Mergiraf — новый движок разрешения конфликтов в коде

Тогда заключаем спор?

Не вижу в этом смысла.

Смысл – штука баксов. Если твоё мнение окажется верным, то ты получишь деньги. Если нет, их получу я. Разве этого мало?

Каждый человек здесь создает популярность и посещаемость.

Ну это еще как посмотреть. Его книги бесплатно раздаются? Т.е. мы создаем популярность и посещаемость а кто то пользуется этим плодами …

Смысл – штука баксов. Если твоё мнение окажется верным, то ты получишь деньги. Если нет, их получу я. Разве этого мало?

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

Всем, собственно, наиболее прямо транслируется в машинный код

Это явно ложь. Мы уже выше обсудили, как gcc транслирует switch-case в бинарный поиск, например. Хотя в коде никакого бинарного поиска нет.

потому что раст не доверяет программисту, считает себя умнее программиста…

Это тоже ложь. Rust себя никем не считает, это просто инструмент, который сишники не могут осилить и ноют.

Ты не ответил на вопрос: что тебе в типах Си не зашло, вот тут я не понял…?

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

Да какой смысл в деньгах?

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

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

То есть, твоё мнение настолько ничего не стоит, что ты не готов рискнуть? Понял, спасибо.

Но я отвечу: слабая типизация

Это ложь.

Но я отвечу: слабая типизация

Это ложь.

Нет. В Си есть автоматическое приведение типов, а значит слабая типизация.

Ты просто не знаешь Си.

То есть, твоё мнение настолько ничего не стоит, что ты не готов рискнуть?

Как раз наоборот, мое мнение важно для меня и мне интересно окажусь ли я прав. Но я не понимаю почему мое мнение вам тоже важно? Мне это непонятно так как ваше мнение меня вообще не интересует.

Ты просто не знаешь Си.

Так ты тоже не знаешь Си.

Так ты тоже не знаешь Си.

Лол «нет ты»

Лол «нет ты»

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

Но тут я согласен, это достаточно сложно и это трудно понять.

Это к чему? zig’и не было в нашем разговоре))))

Из настоящего линукса у меня только одноплатник, и расту там не место. Думал ты посмотришь со своими цифрами. Мой одноплатник-то, совсем другие цифры делает:

$ hyperfine ./testc
Benchmark 1: ./testc
  Time (mean ± σ):     12.305 s ±  0.034 s    [User: 12.288 s, System: 0.015 s]
  Range (min … max):   12.254 s … 12.345 s    10 runs

1$ hyperfine ./testzig
Benchmark 1: ./testzig
  Time (mean ± σ):      4.250 s ±  0.004 s    [User: 4.237 s, System: 0.012 s]
  Range (min … max):    4.243 s …  4.256 s    10 runs

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

Можно увидеть этот код? Пожааааалуйстаааааааа!

нет.

P.S. Я против руста имею только один его недостаток (который важен для меня, может остальным это пофигу) синтаксис для дебилов. В остальном по фигу как то.

Единственно что меня заинтересовало, то когда Раст только начинался я знакомился с этим языком и точно помню там классы, а тут узнал что классов в нем нет. Вот это меня как то напрягает, очень странный момент. Есть ощущение что язык не был спроектирован сразу и по мере его развития его сильно меняют … ну я не спец и это только мое мнение.

А теперь есть... ;) :)))))

нет.

То есть, его не существует?

Автоматическое приведение типов – это огромная подстава. В других языках со статической типизацией такого говна нет. Даже в C++ от этого постарались избавиться.

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

Ну так, повторюсь, это синтаксис от C++.

Есть ощущение что язык не был спроектирован сразу и по мере его развития его сильно меняют … ну я не спец и это только мое мнение.

Его меняли до выхода версии 1.0 (2015 год). С тех пор он обратно совместим и особо сильно не менялся.

Автоматическое приведение типов – это огромная подстава.

А можно пример этой подставы?

А можно пример этой подставы?

Ты серьёзно?

void f(short s) {
  (void) s;
}
int main(void) {
  int i = 123;
  f(i);
}

:( Да там при 2х байтах вообще одно и тоже.

Еще будет пример?

:( Да там при 2х байтах вообще одно и тоже.

Там потенциальный signed overflow, хотя компилятору никто не мешает выкинуть ошибку.

Еще будет пример?

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

Это явно ложь. Мы уже выше обсудили, как gcc транслирует switch-case в бинарный поиск, например. Хотя в коде никакого бинарного поиска нет.

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

Это тоже ложь. Rust себя никем не считает, это просто инструмент, который сишники не могут осилить и ноют.

Что его осваивать когда он Си-подобный - это раз. Два раст за тебя/без-твоего ведома делает оптимизации, заставляет писать что-то типа unsafe и т.д. - да там возни под капотом больше чем видно на первый взгляд собственно.

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

Ты сам написал что видишь проблемы в типизации - отсюда и вопрос: собственно, где? Слабая типизация - это как? типа let в расте? А на остальное ответ простой - Си накладывает ответственность на программиста (и типизация там Строгая! и приведение типов не такое уж неявное, особенно если уметь пользоваться настройками компилятора), т.к. доверяет ему по-умолчанию, а если кто-то не может в Си - значит пусть вон на питонах тренируется…

PS я смотрю это новый тренд, когда программисты - это «твою 7 8» А.С.Пушкины на языках программирования, а за железку никто понимать не умеет, радуйтесь, что деды (которые на С) еще что-то могут.

написан на языке Rust

Удачи им с поддержкой в долгосрочной перспективе.

То есть, его не существует?

Автоматическое приведение типов – это огромная подстава. В других языках со статической типизацией такого говна нет. Даже в C++ от этого постарались избавиться.

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

Rust появился на основе научной работы: как решить один конкретный класс ошибок в программах

Во-первых раст не решает проблемы с этими ошибками. Он не даёт программе запускаться, если такие ошибки есть. Это не значит что люди будут допускать меньше таких ошибок и что программировать станет проще. Наоборот, стало сложнее.

по этому параметру он превосходит остальные

Во-вторых, по этому параметру любой язык с GC лучше раста в 100500 раз.

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

лолчто

раст за тебя/без-твоего ведома делает оптимизации

Любой компилятор так делает. Опять же, смотри выше про бинарный поиск в switch-case.

Ты сам написал что видишь проблемы в типизации - отсюда и вопрос: собственно, где? Слабая типизация - это как?

Слабая типизация – это наличие автоматической конверсии значений между разными типами.

Си накладывает ответственность на программиста

Очень зря Си это делает. Программисты – те ещё безответственные ублюдки.

PS я смотрю это новый тренд, когда программисты - это «твою 7 8» А.С.Пушкины на языках программирования, а за железку никто понимать не умеет, радуйтесь, что деды (которые на С) еще что-то могут.

Только вчера патчил ведро, чтобы у меня wifi работал, потому что очередной говнокодер на Си допустил underflow в буфере.

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

Это всё не важно. Важно, что компилятор C++ может собрать большую часть сишного кода и что C++ можно применять в тех же областях, где применяется Си.

при правильном проектировании

Есть одна проблема. Никто не знает заранее что правильно, а что нет. Это не школьная задача, где есть правильный ответ. В конце концов, если бы все сразу всё писали правильно, то раст и не нужен. Просто пиши сразу правильно в Си и не мучай жопу.

лолчто

лол-то, свитч-кейс не для каждого

Любой компилятор так делает. Опять же, смотри выше про бинарный поиск в switch-case.

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

Слабая типизация – это наличие автоматической конверсии значений между разными типами.

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

Очень зря Си это делает. Программисты – те ещё безответственные ублюдки.

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

Только вчера патчил ведро, чтобы у меня wifi работал, потому что очередной говнокодер на Си допустил underflow в буфере.

Тут всяко бывает, может попался один из «новых программистов», которые не могут в Си.

Это всё не важно. Важно, что компилятор C++ может собрать большую часть сишного кода и что C++ можно применять в тех же областях, где применяется Си

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

Он не даёт программе запускаться, если такие ошибки есть.

Он не даёт программе скомпилироваться, если такие ошибки есть. FTFY

Во-вторых, по этому параметру любой язык с GC лучше раста в 100500 раз.

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

у GC есть свой комплекс проблем

Какие из этих проблем актуальны для обсуждаемой утилиты? По-моему никакие. А вот использование раста добавляет проблем с сопровождением и поддержкой. Даже если автор инопланетянин и считает что на расте писать проще чем на питоне, например.

Там потенциальный signed overflow, хотя компилятору никто не мешает выкинуть ошибку.

Не фига я вас не понимаю.

Добавил туда принтф, скомпилял. дал на вход 123 и int i = 2147483645;

выполнил, получил 2 результат и что?

начиная с нетривиального влияния на производительность

Если говорить в целом, то 99.9% проблем актуальны для реалтайма. В остальном, тот 0.1% настолько специфичен, что не относится даже к языку или GC как таковому, а скорее к конкретной ситуации и конкретной реализации. Такого рода проблемы будут возникать с любыми языками включая раст (например, самое банальное – компилятор генерит не самый эффективный код).

Тогда и Rust близок к ассемблеру. И Форт. И даже Лиспы.

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

не даёт программе скомпилироваться, если такие ошибки есть

Важно то, что в итоге у тебя нет работающей (хотя бы как-то) программы.

Во-первых, я не считаю что это решает проблему, т.к. данное «решение» иезуитское. На самом деле данную проблему решают языки с GC.

Во-вторых, такой подход не позволяет понять почему проблема возникла. Неправильно работающую программу на Си можно отлаживать и в динамике наблюдать. Это даёт понять проблему. В расте тебе просто сообщают что есть ошибка. Это сообщение всегда очень поверхностное и часто не даёт понимания проблемы в общей логике работы программы. Особенно большой и сложной (а какой смысл писать на расте хеловорды?).

Можно возразить, что грамотный программист сообразит и додумает сам. Но возвращаюсь к комментарию который я уже дал другому: если бы все были абсолютно грамотные и всё знали и не делали ошибок, то раст был бы и не нужен. Возникает замкнутый круг. По-моему сама идея языка который не позволяет ошибок – ошибочна. Это плохой, негодный на практике язык. Такой подход хорош в математике, где дрочат на «доказательство корректности», а на практике это либо тривиально (для хэловордов), либо не имеет решающего значения (для большого продакшена).

С типизацией у многих проблем нет, т.к. они используют ЯП со строгой типизацией

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

чтоб быстро работало, нужно писать небезопасно (как собственно в Си)

Неправда, чаще всего не надо. Плюс, семантика языка в плане алиасинга позволяет компиляторам чаще применять оптимизации, чем в си/цпп.

Более в расте мне в глаза особо ничего не бросилось…

Борроу-чекер?

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

Это, конечно же, не так. Важно выравнивание, наличие/отсутствие знака, паддинг и прочие интересные нюансы.

Очень не зря Си накладывает ответственность на программиста, потому что в итоге компилятор Си написать для любой кастомной железки как два пальца об асфальт…

Компилятор какого Си? Описанного в стандарте? Нет.

Во-вторых, зачем его писать-то? Они уже написаны по многу раз, и актуальных платформ осталось примерно три штуки.

компилятор С++ сложнее чем у Си и в эмбдед это проблема, ты попадаешь на непредвиденные баги,

А не в эмбед непредвиденные баги не проблема?

вот когда компилятор раста будет присутствовать хотя бы для 20% устройств (микроконтроллеры с разной архитектурой и т.д.),

Уже присутствует. 95% новых железок – это x86, ARM и RISC-V.

Правильный подход, так и надо. Как вообще можно критиковать то, к чему не прикасался?

Шта, простите? Вчера по работе как раз обновлялся на 6.10

Ну kdiff3 вроде умеет разруливать некоторые случаи. Не все конечно.

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

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

Неправда, чаще всего не надо. Плюс, семантика языка в плане алиасинга позволяет компиляторам чаще применять оптимизации, чем в си/цпп.

Смотря какие задачи решаете, у меня как-то была задачка, развернуть общение по модбас на 370 байтах флеша и 260 байтах рам (15 холдинг регитстров и 6 инпут регистров - чтение/запись по одному регистру и по группе регистров), ядро кортекс-М0 (42 МГц) - на Си все получилось, даже 3 байта на флеше еще осталось свободных… В данном случае кучу проверок не понаделаете, соответственно, в вакууме, код вроде как и небезопасный выходит. Отдельно отмечу, что в Си «оптимизации» - дело добровольное и делаются они до сколь угодно большой глубины, но ручками…

Борроу-чекер?

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

Удачи им с поддержкой в долгосрочной перспективе.

А что с этим не так? Свойства языка позволяют лёгкий рефакторинг и отлавливание маленьких изменений в API библиотек.

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

Нет. Возникает некая недетерминированность поведения. Например, если у нас веб-сервис, то 90% запросов могут завершаться за 100мс, а 10% будут завершаться за 500 мс. И начинается борьба, а как именно на эти 10% повлиять.

В языке без GC отлаживать эту проблему проще: у нас 100% запросов выполняются за время X, оптимизируя код, убирая лишнее, я добиваюсь снижения времени для 100% же запросов. Выбросов не будет.

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

В расте тебе просто сообщают что есть ошибка. Это сообщение всегда очень поверхностное и часто не даёт понимания проблемы в общей логике работы программы.

А можно конкретный пример? Не встречался с такими ситуациями.

и не делали ошибок

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

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

Нет, в Rust компилятор сообщает, что, например, запись в переменную происходит в двух местах одновременно, или переменная используется после освобождения памяти.

Да, это иезуитство, но оно не какое-то там мистическое, а вполне детерминированное.

Это, конечно же, не так. Важно выравнивание, наличие/отсутствие знака, паддинг и прочие интересные нюансы.

Вот не пишите Вы на Си… Знак - это один бит как правило, либо число в доп.коде. Что касается укладки в памяти, у Си есть механизмы и на этот случай.

Компилятор какого Си? Описанного в стандарте? Нет.

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

Во-вторых, зачем его писать-то? Они уже написаны по многу раз, и актуальных платформ осталось примерно три штуки.

Все да не все еще написаны, вод завтра новая железка, а вы без компилятора. Можете при случае попробовать компилятор сделать сами на Си и на Расте, думаю, разницу должны понять.

А не в эмбед непредвиденные баги не проблема?

Не в эмбдет Вы многие проблемы и не увидите, ввиду того, что на ПК сегодня ресурсов много и кучу прослоек с траями есть (давно ли стек кончался у Вашего приложения…? Давно ли у Вас зависала программа в цикле вайл, из которого должны были выйти по поднятому флагу в прерывании, флаг поднимается, а из цикла не выходишь? и т.д.)

Уже присутствует. 95% новых железок – это x86, ARM и RISC-V.

Нужны коммерческие внедрения и примеры в ответственные сферы, а не факт наличия или умный пылесос… да и я имел ввиду не по количеству железок, а по типам: арм (такой, сякой), авр, дсп какой нить и т.д.

Вот не пишите Вы на Си… Знак - это один бит как правило, либо число в доп.коде.

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

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

Какому именно стандарту-то?

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

Как часто новые ISA появляются? Что-то ты гонишь, чувачок.

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

Ты сейчас хочешь сказать, что на ПК не бывает проблем синхронизации? Потому что это примерно 20-30% багов в софте на ПК. Т.е. те что не переполнение буферов и прочий просёр памяти.

Что ещё сломали?

токсично к альфам/ии/повестке/расту.
софтскиллс лессер вен ниидед, дислайн.

Ведь вот это всё к языку относится, так?

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

2. Из п.1 вытекает что чтение исходников на расте усложняется ошибками от неправильного понимания символов + беготнёй туда-сюда с попыткой понять куда там какой лайфтайм прописанный руками поехал.

3. Идиотская абсолютно идея выдавать ошибку в качестве ответа. Если её кто-то по дороге проглотил/потерял - ты получил UB на ровном месте. (да могут быть аргументы что исключение тоже можно проглотить, но это во-1 код нужен специальный, а во-2 его сразу видно, а потеряный result не видно).

4. Вытекающая из п.3 идея что вызов каждой абсолютно ф-ции надо оборачивать в проверки и не забывать на них реагировать. (в го тоже самое)

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

6. Исходя из п.5 ты изначально никак не можешь контроллировать версии зависимостей полностью и будешь иметь проблемы с безопасностью в результирующем коде.

PS: Безопасная работа с памятью это здорово, но она даже в С++ есть уже очень давно. Да, уровня runtime, а не compiletime, но одно другого не отменяет.

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

Идиотская абсолютно идея выдавать ошибку в качестве ответа.

Это отличная идея!

Если её кто-то по дороге проглотил/потерял - ты получил UB на ровном месте.

Нет, UB ты не получишь. Получишь панику (вызов panic!()).

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

Вытекающая из п.3 идея что вызов каждой абсолютно ф-ции надо оборачивать в проверки и не забывать на них реагировать.

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

Исходя из п.5 ты изначально никак не можешь контроллировать версии зависимостей полностью

Можешь.

Получишь панику (вызов panic!()).

Или не получишь:

call_something_that_returns_result();