Но почему то в одном надо рассматривать ситуацию, когда какой-то недотепа допускает глупую ошибку, но в другом можно на это не обращать внимание, ведь там есть слово, которое его ТОЧНО остановит.
Потому что ситуации разные. В Расте можно не писать unsafe, и определенные ошибки будет контролировать компилятор. В Си ошибку можно получить в обычном коде, неудачно выполнив небольшое изменение.
Язык программирования Аргентум -- это язык со сборкой мусора? Или объект хранит в себе список невладеющих ссылок? Иначе как убедится, что при удалении объекта невладеющая ссылка станет невалидной?
Так то и в Rust можно сделать, правда, с небезопасным кодом, абсолютно аналогично, ссылки ("владеющие" в вашей терминологии) на дочерние контролы, и указатели везде в других местах. Да, это можно инкапсулировать, и это тоже будет "работать само" прямо как в языке программирования Аргентум, но это все будет на совести разработчика библиотеки.
В общем случае нельзя хранить две ссылки на объект и иметь гарантии их валидности при удалении (не ну можно, конечно, хранить список всех слабых ссылок, но производительность будет под вопросом). Собственно, поэтому в Rust такие сложности с циклическими структурами данных.
Си не прост. Прост только синтаксис Си, но не написание и рефакторинг программ, которые очень сложны. У Раста сложнее синтаксис, и сложные правила заимствования, однако это не выдуманная сложность, и ограничения, которые накладывает борроу чекер не искусственные. То, что делает борроу чекер в Расте, по-хорошему, программист на Си должен делать руками. Понятно, что большинство не делает, и оно как-то работает.
Собственно, вариантов несколько, и хороших среди них нет.
Встречный вопрос: а как это сделать на Си или на плюсах? Очевидный ответ (везде хранить указатели на контролы) не совсем правильный, потому что приводит к потенциальным use after free сценариями (собственно, поэтому на Расте это не сделать без ансейф).
Я бы сделал список или словарь контролов отдельно, и везде в дереве, подписках и accessibility метках хранил бы идентификатор контрола.
После C# писал на Rust, и немного расстроился от того, сколько ошибок многопоточности было в моем коде на C#/
Для бизнес приложений (например, джсон апишек) Rust менее удобен, чем C#, только отсутствием LINQ (ну и невозможностью рефлекшена в рантайме, но это нужно гораздо реже).
Rust выбрал стратегию определенного поведения, которая может добавлять дополнительные инструкции. Однако, там есть возможность выполнять и "сырые" операции.
Для нормального программиста видеть в коде любые числа и цифры, отличные от нуля - это ну прям кринж кринжовый.
У этого же есть причина, если что, чтобы менять в одном месте и где-то случайно не забыть. Разве такая задача стоит для типов данных? (Если стоит -- всегда можно сделать алиас типа).
Открываем любой код на Rust - и он прям густо густо обвешан ну очень ценными цифрами 8, 32, 64, которые:
а) никакой полезной и нужной информации (как цифры) на самом деле не несут
Чем это принципиально отличается от int/ long / short ?
Нету. Пусть будет вместо Джавы Пайтон, суть моего комментария не в этом. Раст -- это разумный компромисс между скоростью и удобством (при условии, что человек в состоянии на нем писать).
Да, плюсы быстрее (а си еще быстрее), да, Пайтон проще, но Раст -- это возможность получить удобство, соизмеримое с Пайтоном и скорость, приближающуюся к плюсам.
Непонятно, почему Расту надо быть быстрее С++, чтобы быть лучше? Там достаточно преимуществ при сравнимой скорости. Пусть даже Раст будет в три раза медленнее плюсов -- он все равно в десятки раз быстрее джавы или пайтона.
Rust по производительности намного ближе к плюсам, чем к джаве. Если взять плюсы за единицу, то Раст будет, условно, в два раза медленнее, а Джава, условно, -- в пятьдесят.
Только вот неписание на плюсах там отчего-то практически не помогает.
Не помогает от чего? Например, от получения доступа к серверу путем выполнения какого-то HTTP запроса помогает.
Но от ошибок в логике не помогает, да.
Вы везде мешаете одно с другим, по принципу "сгорел сарай -- гори и хата": если уж ни один язык не застрахован от логических ошибок, то нету смысла в защите от ошибок в работе с памятью.
Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"
Формализация договоренностей - это, собственно, и есть написание кода. И описание тикета всегда условно, и всегда содержит много неявных условий. Поэтому не выйдет.
Если мы обсуждаем Зеланда, то насколько я понимаю, есть разные уровни, точки зрения на что-то, и чем "выше смотришь", тем меньше вещей являются действительно важными.
В данном случае, когда вы идете на первое свидание к незнакомой девушке, то результат этого свидания по большому счету неважен: вы ее первый раз видите, даже если пройдет все плохо -- ну и что, на вашу жизнь это глобально не повлияет.
Слабее == хуже?
Потому что ситуации разные. В Расте можно не писать unsafe, и определенные ошибки будет контролировать компилятор. В Си ошибку можно получить в обычном коде, неудачно выполнив небольшое изменение.
Тогда, скорее всего, можно сделать аналогично и в Rust: хранить дерево контролов деревом Rc ссылок, а остальные связи - weak ссылками.
Язык программирования Аргентум -- это язык со сборкой мусора? Или объект хранит в себе список невладеющих ссылок? Иначе как убедится, что при удалении объекта невладеющая ссылка станет невалидной?
Так то и в Rust можно сделать, правда, с небезопасным кодом, абсолютно аналогично, ссылки ("владеющие" в вашей терминологии) на дочерние контролы, и указатели везде в других местах. Да, это можно инкапсулировать, и это тоже будет "работать само" прямо как в языке программирования Аргентум, но это все будет на совести разработчика библиотеки.
В общем случае нельзя хранить две ссылки на объект и иметь гарантии их валидности при удалении (не ну можно, конечно, хранить список всех слабых ссылок, но производительность будет под вопросом). Собственно, поэтому в Rust такие сложности с циклическими структурами данных.
Ну, может вы просто умеете работать с многопоточностью :)
Я в Раст использовал sqlx -- удобно, пока не нужен аналог query builder (IQueryable<T>)
Си не прост. Прост только синтаксис Си, но не написание и рефакторинг программ, которые очень сложны. У Раста сложнее синтаксис, и сложные правила заимствования, однако это не выдуманная сложность, и ограничения, которые накладывает борроу чекер не искусственные. То, что делает борроу чекер в Расте, по-хорошему, программист на Си должен делать руками. Понятно, что большинство не делает, и оно как-то работает.
Собственно, вариантов несколько, и хороших среди них нет.
Встречный вопрос: а как это сделать на Си или на плюсах? Очевидный ответ (везде хранить указатели на контролы) не совсем правильный, потому что приводит к потенциальным use after free сценариями (собственно, поэтому на Расте это не сделать без ансейф).
Я бы сделал список или словарь контролов отдельно, и везде в дереве, подписках и accessibility метках хранил бы идентификатор контрола.
После C# писал на Rust, и немного расстроился от того, сколько ошибок многопоточности было в моем коде на C#/
Для бизнес приложений (например, джсон апишек) Rust менее удобен, чем C#, только отсутствием LINQ (ну и невозможностью рефлекшена в рантайме, но это нужно гораздо реже).
Rust выбрал стратегию определенного поведения, которая может добавлять дополнительные инструкции. Однако, там есть возможность выполнять и "сырые" операции.
Какие ресурсы проедает, например, Rust?
У этого же есть причина, если что, чтобы менять в одном месте и где-то случайно не забыть. Разве такая задача стоит для типов данных? (Если стоит -- всегда можно сделать алиас типа).
Чем это принципиально отличается от
int/long/short?Тем, что он удобнее, избавляет от целого класса ошибок (которые все еще можно сделать в unsafe, да, я знаю), имеет современные средства в языке.
Нету. Пусть будет вместо Джавы Пайтон, суть моего комментария не в этом. Раст -- это разумный компромисс между скоростью и удобством (при условии, что человек в состоянии на нем писать).
Да, плюсы быстрее (а си еще быстрее), да, Пайтон проще, но Раст -- это возможность получить удобство, соизмеримое с Пайтоном и скорость, приближающуюся к плюсам.
Непонятно, почему Расту надо быть быстрее С++, чтобы быть лучше? Там достаточно преимуществ при сравнимой скорости. Пусть даже Раст будет в три раза медленнее плюсов -- он все равно в десятки раз быстрее джавы или пайтона.
Rust по производительности намного ближе к плюсам, чем к джаве. Если взять плюсы за единицу, то Раст будет, условно, в два раза медленнее, а Джава, условно, -- в пятьдесят.
Какое отношение особенности работы браузера имеют к серверным языкам?
Не помогает от чего? Например, от получения доступа к серверу путем выполнения какого-то HTTP запроса помогает.
Но от ошибок в логике не помогает, да.
Вы везде мешаете одно с другим, по принципу "сгорел сарай -- гори и хата": если уж ни один язык не застрахован от логических ошибок, то нету смысла в защите от ошибок в работе с памятью.
Формализация договоренностей - это, собственно, и есть написание кода. И описание тикета всегда условно, и всегда содержит много неявных условий. Поэтому не выйдет.
Если мы обсуждаем Зеланда, то насколько я понимаю, есть разные уровни, точки зрения на что-то, и чем "выше смотришь", тем меньше вещей являются действительно важными.
В данном случае, когда вы идете на первое свидание к незнакомой девушке, то результат этого свидания по большому счету неважен: вы ее первый раз видите, даже если пройдет все плохо -- ну и что, на вашу жизнь это глобально не повлияет.
Пишет, ты сам ее себе придумываешь.
Зеланда в целом не одобряю, но чем менее важным является что-то, тем меньше от него стресса. Так что имеет смысл.