Началось формирование и тестирование сборок движка Servo

они бы лучше в 47 версии рендеринг шрифтов починили.

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

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

Более того, так как уже заплатили тормозами GC/ARC за право не париться вопросами памяти, на этот вопрос забивают и в результате начинается форменная порнография.

А это просто фантазии. Люди прекрасно себе пишут на языках с GC/ARC, в то время как многие «парящиеся вопросами памяти» не могут оптимально и безопасно даже две строки сконкатенировать на С.

без изменения синтаксиса

Смысл? Обратной совместимости с Си всё равно не получится.

внедрения трейтов

А трейты-то тебе чем не угодили?

Смысл? Обратной совместимости с Си всё равно не получится.

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

А трейты-то тебе чем не угодили?

См. выше.

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

Синтаксис Си убог и провоцирует трудноуловимые ошибки.

у которых 100500 вариантов решения для одной и той же задачи

И чо?

Люди прекрасно себе пишут на языках с GC/ARC, в то время как многие «парящиеся вопросами памяти» не могут оптимально и безопасно даже две строки сконкатенировать на С.

Люди и на рубях прекрасно пишут.

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

//fixed

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

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

Синтаксис Си убог и провоцирует трудноуловимые ошибки.

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

И чо?

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

Авторы раста придумали же альтернативу синтаксису Си.

Адепты раста не знают откуда растут корни синтаксиса их языка? Впрочем, а чему тут удивляться.

Люди и на рубях прекрасно пишут.

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

В ведроид с китката тоже завезли, ART кличут.

А потом «косынки» на 8-ядерниках тормозят.

Ясно, сидят с кофеварки и плачутся.

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

А потом «косынки» на 8-ядерниках тормозят.

Я тебе по секрету скажу, что они и на 1024-ядерниках будут тормозить. Причем абсолютно так же.

Авторы раста придумали же альтернативу синтаксису Си.

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

«Трудноуловимая ошибка» это вероятно что-то из разряда «= вместо ==»?

Из разряда:

for (i = 0; i < size_v; i++)
    for (j = 0; j < size_h; i++)

Или, там, if (a) вместо if (*a).

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

И у тебя, конечно, есть примеры?

А то, что чем «навороченнее» код, тем труднее его читать и видеть все что он делает и цепляет.

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

У меня одного оно даже не запустилось? (ubuntu-16.04)

Из разряда:
for (i = 0; i < size_v; i++)
for (j = 0; j < size_h; i++)

И каким боком тут синтаксис?

И у тебя, конечно, есть примеры?

Например:

"Count: " - count

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

Не стоит путать алгоритм и его реализацию.

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

Я вообще в нем для себя не вижу особой потребности

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

---

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

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

Уже есть. http://www.hboehm.info/gc/

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

И красная тряпка тоже есть: применение malloc вместо GC_malloc!

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

Не приделали. Сборку мусора приделали, а memory safety - нет.

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

Я с этим и не спорил.

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

А зачем делать копипаст с костылями? Да, С вынуждает писать больше кода, но не запрещает выносить общий код в функции и макросы.

Адепты раста не знают откуда растут корни синтаксиса их языка?

Где я говорил что-то про корни, дебилко?

Авторы раста придумали же альтернативу синтаксису Си.
Где я говорил что-то про корни, дебилко?

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

О логических ошибках? В их отношении ведь раст не делает ничего нового.

А как же bounds checking и arithmetic overflow check?

Ну и я бы добавил настоятельное предложение использовать Option и Result, а не bool/int. Что сильно сокращает детские ошибки.

Но это всё, конечно же, относительно C/C++.

Это ты так итерацию по последовательности пишешь?

Но это всё, конечно же, относительно C/C++.

Option и Result, кстати, можно использовать и в Си++. Правда, их придется написать самому.

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

А как же bounds checking и arithmetic overflow check?

Во время выполнения? Зависимые типы-то пока в язык ещё не завезли, чтобы проверять статически.

Во время выполнения?

Да.

Я этого и не отрицал. Только в rust std они на каждом шагу, в C++ std одни bool/int.

Option и Result, кстати, можно использовать и в Си++. Правда, их придется написать самому.

Не обязательно, есть <experimental/optional>, который реализован в libstdc++.

Это пример говнокода в духе

for (i = 0; i < size_v; i++)
    for (j = 0; j < size_h; i++)

И иллюстрация на тему провокации «трудноуловимых» ошибок.

Option и Result, кстати, можно использовать и в Си++. Правда, их придется написать самому.

Не обязательно, есть <experimental/optional>

Обязательно. Но объяснять тебе смысла нет.

Это пример говнокода в духе

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

И каким боком тут синтаксис?

Таким, что в for i in 1..size_v такого не сделаешь.

«Count: » - count

И каким боком тут синтаксис? (с)

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

Не стоит путать алгоритм и его реализацию.

Дополнительные фичи при правильном использовании упрощают реализацию. Про случаи неправильного использования - см. выше. Вообще не понимаю, зачем ты приплёл системное программирование. Так бы сразу и сказал - «я неосилятор»/«меня окружают неосиляторы»/«люблю копипастить и генерить тонны бойлерплейта, попутно крича про ортогональность фич языка».

Одних функций мало, нужен ещё и полиморфизм (параметрический).

Для этих случаев есть подход как в qsort (да, костыль, но можно жить). Ну и надо отметить, что в идиоматическом сишном коде такие задачи встречаются реже.

Сишные макросы же вообще эталонный пример костыля.

Тоже не спорю. Я бы лично хотел бы в С string mixins из D, это, конечно, тоже костыль, но зато какой :)

Ты уж определись, «гений».

Давно определился, дебилко.

Так придумали или взяли чужие наработки?

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

Таким, что в for i in 1..size_v такого не сделаешь.

for i in 1..size_v {
  for i in 1..size_v {} 
}

Опс.

Тут проблема в прокладке между стулом и монитором.

Проблема всегда в ней, если уж так.

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

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

Во-первых, не все наработки чужие.

Перечисли свои наработки в Rust, быстро и решительно.

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

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

И в чём разница? Ты хочешь сказать, что конпелятор раста запретит мне писать это так?

И в сем разница?

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

что конпелятор раста запретит мне писать это так?

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

В том, что в Rust есть специальная конструкция для итерации по последовательностям

Мама дорохая!

если тебе хочется (а тебе явно хочется), ты сможешь.

А теперь представь себе, что за раст садится человек, который много лет писал на Си-подобных языках...

Что он будет делать?

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

А теперь представь себе, что за раст садится человек, который много лет писал на Си-подобных языках...

Что он будет делать?

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

Правильно

Неправильно. Вообще считать всех людей заскорузлыми дебилами - неправильно.

привычные инструменты, и среди них будет while.

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

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

Что забавно сам автор этого примера тут же и накосячил в коде на Rust:

for i in 1..size_v

Т.к. либо 1, либо .. тут явно не в тему.

А теперь представь себе, что за раст садится человек, который много лет писал на Си-подобных языках...

Вообще-то во всех них (кроме самого С) есть более удобный способ чем руками дергать счетчик.

Опс.

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

Проблема всегда в ней, если уж так.

Но Си умудряется входить в резонанс с её фундаментальными недостатками.

Я, если что, не пишу почти на С

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

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

Что забавно сам автор этого примера тут же и накосячил в коде на Rust:

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

Таким, что в for i in 1..size_v такого не сделаешь.

Окей, спросим у автора - нет ли тут ошибки с 1 или ..?