Судя по описанию, он пытался обернуть АПИ в стиле "рандомные дескрипторы живут рандомное время". Т.е. когда у каждого объекта есть по факту неконтроллируемое количество неконтроллируемых точек доступа, в т.ч. на запись. Такое естественно не обернуть в статическую модель.
Моё личное мнение как человека, пишущего в основном на С++.
Короткие ключевые слова никаких проблем не доставляют, вопрос скорее привычки.
Java для сравнения вызывает у меня чувство необходимости "писать поэмы".
Знаков пунктуации в реальном коде получается ставнительно немного. В том же Go мне например хотелось бы их чуть побольше. Ну а с С++ вообще не сравнить.
Справедливости ради прикиньте, сколько человеколет и 20-футовых контейнеров денег вбухано в Qt — который начали разрабатывать в 91м, а первый релиз был в 95м. А для раста GUI сейчас пилится в основном энтузиастами по 1-2 человека.
У меня смутное ощущение, что команда разработки ядра просто послала МС нафиг и разошлась. А на их место взяли ребят откуда-нибудь из отдела разработки офиса.
Это те Atlassian, которые уже лет 10 не могут сделать для гита follow file move history в pull requests? Я честно говоря не могу себе представить использование bitbucket для git.
EDIT: Я к тому, что использование BitBucket теперь вообще теряет смысл. По фичам в плане поддержки Git он вчистую проигрывает конкурентам.
Проблема в том, что эта дрянь жрёт больше чем все игрушки вместе взятые, ради которых я её держу.
Семёрка же скорее всего использует hardlinks, которые были сделаны через такое специальное место разработчиков, что в отличие от линукса ими могут пользоваться только Избранные, а считать занимаемый объём мало кто умеет. Проводник например не умеет.
Windows Update не способен посчитать сколько места понадобится чтобы накатить апдейты. А вы о каких-то там ключевых блоках… Тут срочно надо ещё больше настроек выпилить чтобы бедные хомячки не порезались (а заодно эникейщики ничего не смогли сделать).
Как уже выше писали, секрет разработки хороших приложений под Electron — не использовать Electron вообще. Единственный виденный мною вменяемый представитель — VSCode. MS Teams, с которым имею несчастье работать — унылое, неудобное, кастрированное, лагающее и жрущее ресурсы гуано мамонта. Чатик, кушающий 400Мб оперативы в фоне и подгружающий историю сообщений на каждый чих — держать в памяти больше текущей видимой страницы он не способен в принципе.
Много "белых пятен".
Если это некий "кроссплатформенный ассемблер" (что вряд ли) — зачем здесь С++, язык с огромным числом сложностей?
Если это очередное "всеобъемлющее API" — опять же, каким боком С++ (другие языки за бортом)? И как это будет сочетаться с OS-specific API? Чем это лучше LLVM-like бэкендов? Как это будет совместимо с существующими решениями?
Для обозначения переменной нужно два ключевых слова let mut,
Наконец-то с первого взгляда видно, что это переменная. Иммутабельность по умолчанию я считаю скорее плюсом.
аналогично его должны иметь модифицируемые параметры функций.
Это такой же байндинг. Было бы лучше иметь несколько разных правил?
Примитивы все имеют явную разрядность, которую приходится держать в голове (неявного каста тут нет), даже если это не нужно.
Единственное, что может быть немного неудобно — отсутствие неяного апкаста к более ёмкого типа. Хотя — вам не хватает неявного апкаста bool->int и неявного подсчёта хеша так, как вы не ожидали? Да, эта проблема встретилась мне в С++. Но ноги растут из С. По поводу явной разрядности — вы никогда не портировали программу с win16 на win32? С резким разрастанием размера int?
Функции надо помечать ключевым словом, при этом все равно явно задавая возвращаемый тип.
default int сами же авторы С посчитали очень плохой идеей. unit return же указывать необязательно. Про явное ключевое слово fn — вы соскучились по most vexing parse rule? Я — нет.
Каждый match (здешний switch) должен обрабатывать все возможные области значений, необходимо таскать с собой пустую строку дефолта _ => {}.
И это прекрасно, я считаю.
При создании лямбд у разработчиков сломались клавиши скобок: let closure = |i: i32| -> i32 { i + 1 };.
Здесь уже вкусовщина. Мне такой синтаксис кажется вполне имеющим право на жизнь.
Возвращение значений из функций может быть явным и не- (просто последнее выражение без ;),
Expression-based language. Особенность, которую надо знать.
но выражения уже не умеют в return.
Вы вполне можете использовать блок как часть выражения. И делать из него return.
Из-за этого, кстати, код труднее не писать, но читать — без цветной пометки эти строчки на раз пропускаются, либо вводят в смущение.
Неявный return да, может быть неудобен или непривычен. В целом же после небольшой практики и благодаря гораздо более мощному тайпчекеру перестаёт быть проблемой.
В целом же, как человеку, пишущему на С++, мне ваши претензии кажутся сводящимися к "Этот язык не похож на привычный мне С". То, что множество языков скопировало этот синтаксис, не означает, что он лучший. Просто он более распространённый и привычный.
Эти знаки точно так же ставятся в любом другом языке. Всегда заранее известно, какие операции могут привести к какому результату, ЯП полностью детерменирован
Увы, нет. И С/С++ с их просто огромным количеством UB/ID тому вполне себе подтверждение. Вы не можете в С сказать "нулевые указатели у меня будут только здесь, в других местах их не пропускать". Так что программа на С/С++ будет представлять из себя здание с огромным ОСТОРОЖНО СВАРКА во весь фасад.
И да, я хочу чтобы компилятор бил меня по рукам за использование инвалидированных итераторов. Потому что я человек и периодически делаю глупые ошибки.
Я не вижу там в контрибьюторах хоть какие-то коммерческие компании. Подобный проект — это замечательно. Но он хорошо иллюстрирует проблему во многих областях. Ниша нарастила определённую массу, стабилизировалась и "окуклилась". С одной стороны — много зрелых инструментов. С другой — для захода в нишу жизненно необходимо интегрироваться с тем, что есть — C-based тулчейнами.
Я конкретно про embedded. Пока кроме проектов Japaric и ведомой им embedded working group не видно ничего. Думаю, если сравнить с тем, сколько вкладывается в поддержку С в тулчейнах, разница будет порядка на 3. Если не больше.
Как по мне, в этом и проблема. Все ждут пока кто-нибудь другой вложится в поддержку архитектуры или тулчейна. Никто не хочет инвестировать ресурсы, даже крупные компании. Получается замкнутый круг.
Жаль, что сюда не попали мои любимые Вангеры. Кроме абсолютно укуренного и тем замечательного мира там были мои любимые обвешанные оружием машинки. Следующими машинками был Ex Machina от Targem. Потом — тишина. Crossout — неоднозначный и онлайновый. Хотя сама идея сбора пепелаца из подвернувшегося под руку хлама шикарна.
Сюжетный же последователь "Периметр" хоть и самобытен, но просто не в моём вкусе.
Непременно! Предоставьте максимум информации, которая прзволит отправлять этот шлак В СПАМ не читая. Долой информационный мусор!
Судя по описанию, он пытался обернуть АПИ в стиле "рандомные дескрипторы живут рандомное время". Т.е. когда у каждого объекта есть по факту неконтроллируемое количество неконтроллируемых точек доступа, в т.ч. на запись. Такое естественно не обернуть в статическую модель.
Моё личное мнение как человека, пишущего в основном на С++.
Короткие ключевые слова никаких проблем не доставляют, вопрос скорее привычки.
Java для сравнения вызывает у меня чувство необходимости "писать поэмы".
Знаков пунктуации в реальном коде получается ставнительно немного. В том же Go мне например хотелось бы их чуть побольше. Ну а с С++ вообще не сравнить.
Справедливости ради прикиньте, сколько человеколет и 20-футовых контейнеров денег вбухано в Qt — который начали разрабатывать в 91м, а первый релиз был в 95м. А для раста GUI сейчас пилится в основном энтузиастами по 1-2 человека.
Прекрасно. Напомнило про алгоритм Шлемиэля в Windows Update. Ссылку уже, к сожалению, не найду.
(del)
У меня смутное ощущение, что команда разработки ядра просто послала МС нафиг и разошлась. А на их место взяли ребят откуда-нибудь из отдела разработки офиса.
Это те Atlassian, которые уже лет 10 не могут сделать для гита follow file move history в pull requests? Я честно говоря не могу себе представить использование bitbucket для git.
EDIT: Я к тому, что использование BitBucket теперь вообще теряет смысл. По фичам в плане поддержки Git он вчистую проигрывает конкурентам.
Проблема в том, что эта дрянь жрёт больше чем все игрушки вместе взятые, ради которых я её держу.
Семёрка же скорее всего использует hardlinks, которые были сделаны через такое специальное место разработчиков, что в отличие от линукса ими могут пользоваться только Избранные, а считать занимаемый объём мало кто умеет. Проводник например не умеет.
Windows Update не способен посчитать сколько места понадобится чтобы накатить апдейты. А вы о каких-то там ключевых блоках… Тут срочно надо ещё больше настроек выпилить чтобы бедные хомячки не порезались (а заодно эникейщики ничего не смогли сделать).
Как уже выше писали, секрет разработки хороших приложений под Electron — не использовать Electron вообще. Единственный виденный мною вменяемый представитель — VSCode. MS Teams, с которым имею несчастье работать — унылое, неудобное, кастрированное, лагающее и жрущее ресурсы гуано мамонта. Чатик, кушающий 400Мб оперативы в фоне и подгружающий историю сообщений на каждый чих — держать в памяти больше текущей видимой страницы он не способен в принципе.
Много "белых пятен".
Если это некий "кроссплатформенный ассемблер" (что вряд ли) — зачем здесь С++, язык с огромным числом сложностей?
Если это очередное "всеобъемлющее API" — опять же, каким боком С++ (другие языки за бортом)? И как это будет сочетаться с OS-specific API? Чем это лучше LLVM-like бэкендов? Как это будет совместимо с существующими решениями?
Наконец-то с первого взгляда видно, что это переменная. Иммутабельность по умолчанию я считаю скорее плюсом.
Это такой же байндинг. Было бы лучше иметь несколько разных правил?
Единственное, что может быть немного неудобно — отсутствие неяного апкаста к более ёмкого типа. Хотя — вам не хватает неявного апкаста bool->int и неявного подсчёта хеша так, как вы не ожидали? Да, эта проблема встретилась мне в С++. Но ноги растут из С. По поводу явной разрядности — вы никогда не портировали программу с win16 на win32? С резким разрастанием размера int?
default int сами же авторы С посчитали очень плохой идеей. unit return же указывать необязательно. Про явное ключевое слово fn — вы соскучились по most vexing parse rule? Я — нет.
И это прекрасно, я считаю.
Здесь уже вкусовщина. Мне такой синтаксис кажется вполне имеющим право на жизнь.
Expression-based language. Особенность, которую надо знать.
Вы вполне можете использовать блок как часть выражения. И делать из него return.
Неявный return да, может быть неудобен или непривычен. В целом же после небольшой практики и благодаря гораздо более мощному тайпчекеру перестаёт быть проблемой.
В целом же, как человеку, пишущему на С++, мне ваши претензии кажутся сводящимися к "Этот язык не похож на привычный мне С". То, что множество языков скопировало этот синтаксис, не означает, что он лучший. Просто он более распространённый и привычный.
Увы, нет. И С/С++ с их просто огромным количеством UB/ID тому вполне себе подтверждение. Вы не можете в С сказать "нулевые указатели у меня будут только здесь, в других местах их не пропускать". Так что программа на С/С++ будет представлять из себя здание с огромным ОСТОРОЖНО СВАРКА во весь фасад.
И да, я хочу чтобы компилятор бил меня по рукам за использование инвалидированных итераторов. Потому что я человек и периодически делаю глупые ошибки.
Ставим Visual Studio Build Tools и имеем всё недостающее. На страничке rustup это вроде было описано.
Я об этом и говорю. Требуется преодолеть гигантскую инерцию.
Я не вижу там в контрибьюторах хоть какие-то коммерческие компании. Подобный проект — это замечательно. Но он хорошо иллюстрирует проблему во многих областях. Ниша нарастила определённую массу, стабилизировалась и "окуклилась". С одной стороны — много зрелых инструментов. С другой — для захода в нишу жизненно необходимо интегрироваться с тем, что есть — C-based тулчейнами.
Я конкретно про embedded. Пока кроме проектов Japaric и ведомой им embedded working group не видно ничего. Думаю, если сравнить с тем, сколько вкладывается в поддержку С в тулчейнах, разница будет порядка на 3. Если не больше.
Как по мне, в этом и проблема. Все ждут пока кто-нибудь другой вложится в поддержку архитектуры или тулчейна. Никто не хочет инвестировать ресурсы, даже крупные компании. Получается замкнутый круг.
Жаль, что сюда не попали мои любимые Вангеры. Кроме абсолютно укуренного и тем замечательного мира там были мои любимые обвешанные оружием машинки. Следующими машинками был Ex Machina от Targem. Потом — тишина. Crossout — неоднозначный и онлайновый. Хотя сама идея сбора пепелаца из подвернувшегося под руку хлама шикарна.
Сюжетный же последователь "Периметр" хоть и самобытен, но просто не в моём вкусе.