The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Microsoft наймёт разработчиков для переписывания сервисов с C# на Rust, opennews (??), 01-Фев-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


44. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +6 +/–
Сообщение от Аноним (38), 01-Фев-24, 10:32 
Неужели C# работает с адресной арифметикой, выходит за пределы буферов, что захотелось переписать на БезопасТный? По моему скромному мнению, поскольку C# managed язык, то он побезопасней Раста.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

52. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +4 +/–
Сообщение от Аноним (-), 01-Фев-24, 10:48 
Думаю он просто медленнее.
Как раз за счет garbage collector.
И для особо нагруженных мест, его имеет смысл заменять на язык с ручным управлением памяти.
Но сишка и плюсы дырявые и добовляют много ошибко и попоболи для разработчиков.
Ответить | Правка | Наверх | Cообщить модератору

59. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +3 +/–
Сообщение от anonymous (??), 01-Фев-24, 11:09 
А раст с наркоманским синтаксисом и вечным мозготрахом с борроу чекером не добавляет попоболи для разработчиков.
Ответить | Правка | Наверх | Cообщить модератору

66. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +4 +/–
Сообщение от Аноним (-), 01-Фев-24, 11:35 
Просто так и скажи "я неосилятор, я не могу запомнить еще пару добавленных символов, я не могу просто исправить то, на что борровчерек в консоль жалуется"
и я спокойно поверю)

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

Ответить | Правка | Наверх | Cообщить модератору

99. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –1 +/–
Сообщение от User (??), 01-Фев-24, 12:36 
readability counts(С)
Непонимание этого факта несет за собой много-много проблем. А гордится приобретенным стокгольмским синдромом... ну, такоэ в общем.
Ответить | Правка | Наверх | Cообщить модератору

116. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –1 +/–
Сообщение от Аноним (-), 01-Фев-24, 13:07 
> readability counts(С)

Полностью согласен, и готов посмотреть на пример сишного кода.
Например uint32_t x = (*(struct foo *)NULL)->x из дыряшки просто забанили на АРМ процессорах)

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

>  А гордится приобретенным стокгольмским синдромом... ну, такоэ в общем.

Но именно этим и занимаются разработчики на дыряшке!
Вместо того чтобы перейти на инструмент без "типичных ошибок", UB и отсутсвием нормальных инструметов (типа enum'ов) они гордятся тем, что они используют кривое старье.
Типа "я смог из овна и палок слепить велосипед!", "я работаю только тупым каменным топором, зато смог срубить кривую избушку".

Ответить | Правка | Наверх | Cообщить модератору

125. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –1 +/–
Сообщение от User (??), 01-Фев-24, 13:28 
> А вот иллюзия простоты - это абсолютное зло.
> Когда код вроде понятный, но в нем 100500 UB и особенностей, которые
> работают по разному в зависиммости от компилятора, фазы луны и псиихческого
> здоровья разработчика.

Так ложная же дихотомия. "Что за беда, коль в огороде лебеда? Вот, у них церква горят - ничего не говорят!" - насыплю-ка я еще два ведра палочек-с-закорючками, раз воооон у тех - нигров вешаютъ...

> Но именно этим и занимаются разработчики на дыряшке!
> Вместо того чтобы перейти на инструмент без "типичных ошибок", UB и отсутсвием
> нормальных инструметов (типа enum'ов) они гордятся тем, что они используют кривое
> старье.
> Типа "я смог из овна и палок слепить велосипед!", "я работаю только
> тупым каменным топором, зато смог срубить кривую избушку".

Оба хуже(Ц).
Почему-то желающих перейти на иероглифическую письменность со всеми её невдолбенными преимуществами (К-краткость! В-выразительность!) окрест не наблюдается - но ЯП "этадругое!!!111"

Ответить | Правка | Наверх | Cообщить модератору

134. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –1 +/–
Сообщение от Аноним (38), 01-Фев-24, 13:55 
>которые работают по разному в зависиммости от компилятора

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

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

148. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 01-Фев-24, 15:02 
Оу-оу, а не прифигели ли вы? Сишка это не только ваш линукс!
Это и бсд, и макось, и даже немного винда. И даже другие, менее распростаненные оси.
Я молчу про тонны прикладного софта, который можно запустить везде где скомпилишь.

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

Ответить | Правка | Наверх | Cообщить модератору

157. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Аноним (157), 01-Фев-24, 16:06 
> И пришлось тратить сотни человекочасов чтобы заставить это компилиться действительно свободным компилятором.

Это ты про MSVC?

Ответить | Правка | Наверх | Cообщить модератору

158. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 01-Фев-24, 16:15 
> Это ты про MSVC?

Это про Clang/LLVM.
Собрать ядро при помощи MSVC, насколько я не знаю, (еще) нельзя.
А Clang собирает ядра для все андроидов.

Ответить | Правка | Наверх | Cообщить модератору

346. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Александр (??), 03-Фев-24, 01:21 
Кстати, не особый любитель clang, но отмечу, что эти товарищи не только gcc расширения поддержали, но ещё и borland c++. Вообще появлялась мысль взять clang и скрестить с VCL из Lazarus. Получился бы такой, кроссплатформенный borland c++
Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

187. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Советский инженер (ok), 01-Фев-24, 17:15 
>>которые работают по разному в зависиммости от компилятора
>А нехер было тащить в экосистему Линукса яблочный компилятор.

а какже стандарт 🤣 ?

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

190. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Аноним (-), 01-Фев-24, 17:35 
> а какже стандарт 🤣 ?

А что стандарт? Прекрасный стандарт! Целый (с придыханием) Международный ИСО!

У вас некоторый софт не компилится? А какой-то компилится, но работает по разному...
Так это дело житейское, главное что оно работает по разному ПО СТАНДАРТУ!
Не то что во всяких языках, где есть всего один компилятор и все работает одинаково, но нет стандарта!


Ответить | Правка | Наверх | Cообщить модератору

347. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Александр (??), 03-Фев-24, 01:25 
Достаточно молодой язык, поэтому и один компиль. Если даже для python имплементаций наплодили, то для системно-ориентированного подавно наплодят
Ответить | Правка | Наверх | Cообщить модератору

424. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Минона (ok), 05-Фев-24, 10:52 
> Достаточно молодой язык, поэтому и один компиль. Если даже для python имплементаций
> наплодили, то для системно-ориентированного подавно наплодят

Неа.
Один язык, один компилятор, один путь!
😏

Ответить | Правка | Наверх | Cообщить модератору

128. Скрыто модератором  –1 +/–
Сообщение от fff (??), 01-Фев-24, 13:41 
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

254. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +3 +/–
Сообщение от C00l_ni66a (ok), 01-Фев-24, 22:53 
>Но сишка и плюсы дырявые и добовляют много ошибко и попоболи для разработчиков.

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

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

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

67. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –2 +/–
Сообщение от Аноним (-), 01-Фев-24, 11:35 
> наркоманским синтаксисом

Смешно как неосиляторы продолжают пованивать про синтаксис))

> вечным мозготрахом

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

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

170. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Аноним (189), 01-Фев-24, 16:49 
Лол, вот мы и дожили до момента когда хрустики заявляют "Просто писать нужно нормально и сразу думать что чем владеет." "Это не C, повторяю, это Rust, не C!"
Ответить | Правка | Наверх | Cообщить модератору

217. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +2 +/–
Сообщение от Аноним (-), 01-Фев-24, 19:31 
Так рустики никогда этого и не отрицали!
Просто если ты напишешь фигню - тебе компилятор по рукчкам-кривучкам настучит.
И будешь ты исправлять, пока думать не научишься. Раст в этом смысле очень дисциплинирует.

А в си компилятор это все схавает, а потом еще 10 лет CVE выгребать будут.

Ответить | Правка | Наверх | Cообщить модератору

275. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (269), 02-Фев-24, 04:13 
Если нормально программировать не научился, никакой Раст не поможет, как подпорка для мозга которого нет ))  
А если научился, то и без Раста можно прекрасно обойтись. "Просто программируйте нормально" (c) Растаманы
Ответить | Правка | Наверх | Cообщить модератору

324. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 02-Фев-24, 13:55 
Судя по количеству CVE, которые находят в коде на Си, за 50 (или сколько там?) лет существования этого языка, на нем НИКТО не научился программировать.
Ответить | Правка | Наверх | Cообщить модератору

348. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Александр (??), 03-Фев-24, 01:28 
Будто в rust коде cve не находят. Просто баги на уровень выше поднялись, вот и всё
Ответить | Правка | Наверх | Cообщить модератору

374. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 14:19 
Находят. Но это уже баги из другой, менее распространённой категории ошибок программирования. Так что не вот и всё. Баги будут всегда в сложном ПО. Вопрос в их количестве.
Ответить | Правка | Наверх | Cообщить модератору

399. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Александр (??), 04-Фев-24, 01:41 
А вы серьёзно уверены, что их станет меньше? Я думаю нет, просто, как говорил, станут другими. Ничего особо не имею против rust и современных тенденций безопасности, но такой путь на каждом шагу рождает ложное чувство безопасности в низких уровнях. Чтобы лучше донести мысль, разделим кодовую базу на условные слои: операции с памятью, алгоритмы, локальная архитектура (в духе шаблонов банды четырёх), общая архитектура программы и т.д. Вот пусть мы на каком-нибудь си фокусируем внимание на уровне алгоритмов, и выше, а на управление памятью меньше. От сюда ошибки. Ок, rust закрыл необходимость фокусировать внимание на уровне управления памятью, при этом фокусировка "сдвинулась" на уровень локальной архитектуры и выше. Таким образом, ошибки будут появляться на уровне алгоритмов. С другой стороны, фокусировка на нижних слоях не оставляет возможности фокусироваться на более верхних. Или просто делает их плохо читаемыми (почему на си не так часто пишут большое ПО), rust скорее всего позволит "захватить" какой-нибудь из верхних уровней. Так что по сути, просто сдвигается "кадр фокуса". Но это моя мысль, гипотеза. Посмотрим, что будет.
Ответить | Правка | Наверх | Cообщить модератору

91. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от НяшМяш (ok), 01-Фев-24, 12:12 
> штука помогающая писать правильный код
> мозготрах

вся суть местных онанимусов

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

173. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  –1 +/–
Сообщение от Аноним (189), 01-Фев-24, 16:53 
> статические анализаторы не нужны, не помогут и т.д.
> статический анализатор встроен в компилятор - о дайте десять!!!
Ответить | Правка | Наверх | Cообщить модератору

343. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 01:00 
А ты разницу совсем не понимаешь между сторонним инструментом и встроенным, и между статическим анализатором и гарантиями, которые предоставляет компилятор?
Ответить | Правка | Наверх | Cообщить модератору

84. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +2 +/–
Сообщение от n00by (ok), 01-Фев-24, 12:06 
> Думаю он просто медленнее.

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

> Как раз за счет garbage collector.

В ряде случаев быстрее ручного управления.

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

110. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (106), 01-Фев-24, 13:00 
Как писали весь требовательный софт на c/c++, так и пишут. ЯП с GC радикально тормознее при одинаковых ресурсах.
Ответить | Правка | Наверх | Cообщить модератору

114. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от n00by (ok), 01-Фев-24, 13:04 
Если кто не в курсе - подсчёт ссылок это одна из стратегий сборки мусора. Про алгоритмическую сложность free() не спрашиваю.
Ответить | Правка | Наверх | Cообщить модератору

319. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 02-Фев-24, 13:18 
> Как писали весь требовательный софт на c/c++, так и пишут. ЯП с
> GC радикально тормознее при одинаковых ресурсах.

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

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

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

113. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (106), 01-Фев-24, 13:03 
> В ряде случаев быстрее ручного управления.

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

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

115. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 01-Фев-24, 13:07 
А если не знать про разницу пропускных способностей ОЗУ и кеша, и о способности уплотняющего сборщика располагать коррелирующие данные рядом, можно и не то нафантазировать.
Ответить | Правка | Наверх | Cообщить модератору

344. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 01:02 
Самое главное, что надо знать про сборщик мусора - это то, что он непредсказуем.
Ответить | Правка | Наверх | Cообщить модератору

361. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 03-Фев-24, 07:49 
Я знаю, когда вызывается сборщик мусора, который я написал. Если кто-то не может почитать документацию к остальным - не стоит об этом заявлять с таким апломбом.
Ответить | Правка | Наверх | Cообщить модератору

376. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 14:23 
То, что ты знаешь, когда он вызывается, не означает, что ты знаешь, сколько времени уйдёт на его работу. Именно по этой причине языки с GC для ОС реального времени не используются. И нет, это не апломб, а горькая правда жизни. Лично я ничего против не имею против языков с GC в тех областях, которые лучше для них подходят.
Ответить | Правка | Наверх | Cообщить модератору

409. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 04-Фев-24, 11:07 
> То, что ты знаешь, когда он вызывается, не означает, что ты знаешь,
> сколько времени уйдёт на его работу.

Ещё я не знаю, сколько времени уйдет на работу free(). А кто "знает", пусть посмотрит реализацию.

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

Действительно, горькая. Windows не является ОС реального времени.

Ответить | Правка | Наверх | Cообщить модератору

389. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Аноним (366), 03-Фев-24, 18:50 
> Я знаю, когда вызывается сборщик мусора, который я написал.

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

И если не дай боже прога была интенсивно нагруженная - одному ктулху известно как это будет взаиможействовать, так что после выпуска новой версии или выхода нового нета 50/50 что саппорт разорвут на части злые кастомеры у которых все фигакнулось когда серваки стали в аут по памяти уходить. В этом грабля вон того GC и состоит. А если вон те начинают блеять что можно дескать мануально вызывать... ну пля, тогда возможно проще было бы мануально памятью рулить, раз пошла такая пьянка?! А то получилось то же самое по сложности - но куда хреновее по предсказуемости. И вот зачем оно такое в результате?

Ответить | Правка | К родителю #361 | Наверх | Cообщить модератору

410. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 04-Фев-24, 11:15 
>> Я знаю, когда вызывается сборщик мусора, который я написал.
> А в дотнете - его писал не ты. А какие-то индусы.

Это аргумент. Потому и Микрософт всё, что считает нужным, либо покупает, либо переписывает. Чего с Rust пока не произошло.

Ответить | Правка | Наверх | Cообщить модератору

432. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 07-Фев-24, 19:12 
> Это аргумент. Потому и Микрософт всё, что считает нужным, либо покупает, либо
> переписывает. Чего с Rust пока не произошло.

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

Ответить | Правка | Наверх | Cообщить модератору

438. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 08-Фев-24, 08:43 
>> Это аргумент. Потому и Микрософт всё, что считает нужным, либо покупает, либо
>> переписывает. Чего с Rust пока не произошло.
> ...но в совет директоров "независимой" фаундации - втерлись. Там еще правда гугл
> и амазон, на троих сообразят. Ворон ворону глаз не выклюет.

Да, там ещё Google, которая своими Chromebook-ами немножко Microsoft с рынка двигает. В такой компании только успевай следить, как бы чего в стакан не подсыпали.

Ответить | Правка | Наверх | Cообщить модератору

233. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от ptr (??), 01-Фев-24, 20:32 
Отсутствие наследования тоже не мало добавляет "попоболи". Про костыли я в курсе, но они всех проблем не закрывают. Если на входе уже рабочий ООП код, то малой кровью переписать его на Rust уже не выйдет.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

259. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (259), 01-Фев-24, 23:54 
Отсутствие наследования добавляет боли только тем, кто ни бельмеса не смыслит в программировании. В Расте нет совершенно никаких преград для ООП. Вообще никаких. Проблема не в языке, а в том, что ты знаешь ровно одну ООП-модель, популяризованную Sun в конце девяностых. Неудивительно, что всё, что не укладывается в эту парадигму кажется проблемными костылями.
Ответить | Правка | Наверх | Cообщить модератору

278. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (269), 02-Фев-24, 04:26 
Так и в Си тоже нет преград для ООП, да и в любом другом языке общего назначения. Но есть базовые ООП конструкции которые всем известны и полезность их отрицается только совсем уж упоротыми, и в Расте этих конструкций нет, факт.
Ответить | Правка | Наверх | Cообщить модератору

312. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 02-Фев-24, 10:58 
> ни бельмеса не смыслит в программировании
> ты знаешь ровно одну

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

> одну ООП-модель, популяризованную Sun в конце девяностых

Я как раз и указал, что весь существующий код на C# реализован именно в этой ООП модели. Потому и переписать уже рабочий код на Rust будет очень больно и малой кровью не обойтись.
Слишком много потребуется копипастить. Не зря уже десять лет открыт https://github.com/rust-lang/rfcs/issues/349
Костылями я называю подобные вещи: https://crates.io/crates/ambassador

Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

333. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (259), 02-Фев-24, 19:17 
> Я как раз и указал, что весь существующий код на C# реализован именно в этой ООП модели. Потому и переписать уже рабочий код на Rust будет очень больно и малой кровью не обойтись.

Как я и сказал: в программировании не смыслишь, за пределами одной ООП-модели ничего не знаешь. В грамотно спроектированном приложении — а в том, что МС проектирует грамотно я не сомневаюсь — концептуальная архитектура слабо связана с имплементацией. Проблемный домен не изменился, ограничения остались те же, алгоритмы вообще абстрактны и от языка реализации не зависят, разве что не любой алгоритм можно эффективно реализовать на любом языке, но это такие мелочи, с которыми даже миддл разберётся без подсказок. Так что из старого кода если что и нужно, то только «магические константы», если они там вообще есть.

> Не зря уже десять лет открыт https://github.com/rust-lang/rfcs/issues/349

«Сделайте нам как в C++». Будет открыт ещё 20 лет. С++ уже есть, второй C++ не нужен.

> Костылями я называю подобные вещи: https://crates.io/crates/ambassador

Где костыль-то? Кто-то реализовал паттерн из gang of four (кстати, помеченный в индексе как «C++ idiom», такой вот юмор). Но вообще я согласен, паттерны — это дистиллированные костыли, но тут ничего не попишешь. Приличные макросы есть только в лиспах и окресностях.

Ответить | Правка | Наверх | Cообщить модератору

340. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 02-Фев-24, 23:27 
> Как я и сказал: в программировании не смыслишь,

Ешё раз спасибо, что начинаете сообщения с перехода на личности, признавая себя демагогом!

> я не сомневаюсь

И спасибо, за демонстрацию своей подростковой самоуверенности!

Я то со структурой классов .Net.Core не первый десяток лет работаю. Ещё отдельный вопрос, что на Rust собираются делать с повсеместно используемой в .Net.Core рефлексией. Вплоть до генерации и компиляции на лету Action.

Ответить | Правка | Наверх | Cообщить модератору

345. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 01:21 
> что на Rust собираются делать с повсеместно используемой в .Net.Core рефлексией. Вплоть до генерации и компиляции на лету Action.

Я не большой знаток ни Rust, ни .Net. Но припоминаю, что лет примерно двадцать назад шли яростные споры между сторонниками Java и C#. Дошло до сравнения производительности в лоб. Java тогда при первом сравнении проиграла, сильно отстав от соперника в выполнении тестов. Но потом пришли java-гуру, проанализировали код и увидели, что там использовалось очень много рефлексии. Когда всё это было вычищено, оказалось, что проигрыш Java был уже не таким существенным, как в первый раз. К чему это я? К тому, что использование рефлексии, получается, это плохая практика там, где нужна высокая производительность. Подозреваю, что разработчики Microsoft об этом знают и не используют рефлексию в своём высоконагруженном софте.

Далее. Что мешает эмулировать ту же рефлексию с помощью метаданных, динамической диспетчеризации?
Ну и вот: https://docs.rs/reflect/latest/reflect/

Ответить | Правка | Наверх | Cообщить модератору

350. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Александр (??), 03-Фев-24, 01:44 
Тут больше спор не о том, что в майкрософт решили что-то переписать на rust. Не исключено, что переписывают то, что высоконагруженное и при этом легко переписывается. Но учитывая любовь майкрософта к большим и весёлым абстракциям (вспоминаем тот же COM, .Net), не думаю что у них шибко много кода, который они без боли могут переписать на rust.
Ответить | Правка | Наверх | Cообщить модератору

378. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 14:33 
CoPilot им в помощь. Это же их продукт, вроде как.
Ответить | Правка | Наверх | Cообщить модератору

365. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 03-Фев-24, 08:45 
> использование рефлексии, получается, это плохая практика там, где нужна высокая производительность

Любым инструментом можно как принести пользу, так и навредить. Вообще то рефлексия как раз и позволяет добиться высокой производительности. Например, компиляция Action для схем метаданных у нас дала двукратный прирост производительности при массовых конвертациях данных из одного бинарного представления в другое.

> разработчики Microsoft об этом знают и не используют рефлексию в своём высоконагруженном софте

Так даже в .Net.Core её полно.

> Что мешает эмулировать ту же рефлексию с помощью метаданных, динамической диспетчеризации?

Потому что рефлексия это не только динамическая диспетчеризация, но и динамическая компиляция кода.

Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

377. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 14:31 
> Вообще то рефлексия как раз и позволяет добиться высокой производительности.

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

> Потому что рефлексия это не только динамическая диспетчеризация, но и динамическая компиляция кода.

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

Ответить | Правка | Наверх | Cообщить модератору

392. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 03-Фев-24, 20:31 
> В Си тоже ведь нет никакой рефлексии.

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

Я в C рефлексией, генерируя машинный код, пользовался неоднократно. Для STM8L в PowerSaving-Run-Mode это вообще штатный прием, так как в этом режиме flash обесточивается и переключиться в этот режим можно только передав управление в RAM, на код, который предварительно там был сформирован. А если речь не про МК с очень ограниченными ресурсами, то удобней LLVM.

> Код же в итоге не остаётся динамичным, он компилируется и превращается в статичный.

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

> Проблема решаема, хотя и с большими трудозатратами.

Именно это я и указал. В Rust есть unsafe, поддерживающий механизмы необходимые для низкоуровневой рефлексии. Но это куда более трудоемко, чем в CLR, и потребует использования, например, того же LLVM.

Ответить | Правка | Наверх | Cообщить модератору

393. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Прохожий (??), 03-Фев-24, 21:07 
> Именно так работает любой дебаггер.

В инфраструктуре Rust тоже есть дебаггер.

> Как это не остается?

Инструкции ЦПУ уже не меняются, когда обрабатываются им непосредственно. Это не электрон в суперпозиции. Я об этом.

> Именно это я и указал. В Rust есть unsafe, поддерживающий механизмы необходимые для низкоуровневой рефлексии. Но это куда более трудоемко, чем в CLR, и потребует использования, например, того же LLVM.

Кто мешает из низкоуровневой рефлексии сделать высокоуровневую?

Ответить | Правка | Наверх | Cообщить модератору

407. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 04-Фев-24, 09:59 
>> нужна информация об исходном коде, переменных, функциях и параметрах, то в отладочных данных это все есть
> В инфраструктуре Rust тоже есть дебаггер.

Зачем Вам "информация об исходном коде, переменных, функциях и параметрах" для рефлексии в целях повышения производительности путем генерации кода и его компиляции в ходе выполения программы. Или Вы что-то своё обсуждаете?

> Инструкции ЦПУ уже не меняются, когда обрабатываются им непосредственно.

Они меняются в процессе работы программы. Этого более чем достаточно. Разделение на основе времени или дистанции в стеке генерации кода и его использования выглядит совершенно натянутым.

> Кто мешает из низкоуровневой рефлексии сделать высокоуровневую?

По кругу ходим. Ничто не мешает, но это будет уже не безопасный Rust, а сплошной unsafe. И намного безопасней тогда будет CLR, JVM или V8. Причем не факт, что медленней.

Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

402. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (366), 04-Фев-24, 05:24 
> В C вообще нет ограничений. Можно передать управление по любому адресу.
> Компилятору без разницы, что там размещено и откуда там машинный код взялся.

Ну это где как. Какой-нибудь AVR в этом смысле весьма кривая штука. Гарвард да на сишечке - вы поняли.

> Для STM8L в PowerSaving-Run-Mode это вообще штатный прием, так как в этом
> режиме flash обесточивается

А там разве не выбираемо? В 32L1 - флеха включается-отключается программно. Ессно выключить ее под работающим кодом - не того. Но она там мало жрет, и вон то излишне.

> А если речь не про МК с очень ограниченными ресурсами, то удобней LLVM.

Мне gcc больше зашел, поддерживает намного больше архитектур, ARM плотно впрягается в выпуск релизов для своих камней, тулчейн прям из дистро вполне норм. А LLVM де факто делается парой корпов - которые от эмбедовки страшно далеки, и им похрен на проблемы эмбедеров на самом деле.

> Но это куда более трудоемко, чем в CLR, и потребует использования, например, того же LLVM.

Rust некоторые господа уже натягивают на мк и прочие бутлоадеры и кернелы. Попробуйте так с вашим CLR... а универсальный реюзабельный в разных ситуациях тул это так то - хорошо. Сишка на этом и выехал. У хруста есть некий шанс на этот счет пожалуй. По примерно тем же причинам.

Ответить | Правка | Наверх | Cообщить модератору

408. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 04-Фев-24, 10:33 
> Гарвард да на сишечке

Это никак нельзя назвать ограничением языка.

> А там разве не выбираемо?

Что выбираемо? Установка REGOFF в CLK_REGCSR допускается только после отключения флеша. А отключить флеш можно только сформировав в RAM код и передав туда управление.

> В 32L1 - флеха включается-отключается программно.

Там с этим меньше проблем, благодаря наличию кеша инструкций в Cortex-M.

> Мне gcc больше зашел

В случае LLVM код можно генерировать сразу на IR, а JIT есть из коробки, что позволяет иметь достаточно легковесные контейнеры. А в случае GCC - это уже намного более тяжеловесное решение, требующего наличия всего GCC в контейнерах.

> Rust некоторые господа уже натягивают на мк и прочие бутлоадеры и кернелы. Попробуйте так с вашим CLR.

Бутлоадер и сервисы MS Office 365 - это совершенно разные области применения. И меня если использование Rust в Linux Kernel меня не удивляет, то использование его в MS Office смутило.
Я понимаю, что Excel можно и на ассемблере написать. Но зачем?

Ответить | Правка | К родителю #402 | Наверх | Cообщить модератору

414. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 04-Фев-24, 12:54 
> Это никак нельзя назвать ограничением языка.

А чем это назвать? Указатели в си подразумевают фоннеймана. Остальное если и делается, то через костыли, AVR видный представитель ЭТОГО.

> Что выбираемо? Установка REGOFF в CLK_REGCSR допускается только после отключения флеша.

А, понятно. Я думал там uncore похожий, некоторые железки STM8 напоминают STM32, но - нет, не оно. У 32L1 и т.п. регуль можно в low power режим заогнать, он при этом меньше жрет но выдает лимитированый ток. И единственный критерий - не жрать больше энного. А флеш или что - не важно.

> А отключить флеш можно только сформировав в RAM код и передав туда управление.

Это то логично. В STM32 примерно такое ограниение на страничную запись флехи например. А понемногу, таки, могет - просто паузит core на время записи если что-то с флехи надо, что тоже так то существенное ограничение для уравляющей штуки.

> Там с этим меньше проблем, благодаря наличию кеша инструкций в Cortex-M.

Где у 32L1 кеш то? Как максимум - пайплайн. Просто там флеху выключать для lowpower режима LDO не надо, может и из флеша ползать, главное чтобы суммарно ток не превышал лимиты lpRUN режима регуля.

>> Мне gcc больше зашел
> В случае LLVM код можно генерировать сразу на IR,

И что мне это дает в общем случае? Я ж не собираюсь с IR что-то делать. А их жирнолиба на чуть не 60 мегов вызывает вопросы что с ним таким будет если добавить больше архитектур и оптимизаций.

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

Мне JIT вообще не в кассу. Особенно в контейнерах. И хруст кроме всего прочего - нормальный компиляемый ЯП так то. Это его достоинство, имхо: не будет жрать ресурсы в проде на AOT/JIT.

> А в случае GCC - это уже намного более тяжеловесное решение, требующего наличия всего
> GCC в контейнерах.

А зачем мне что-то компилить в именно контейнерах? Ну и если легкота наше все - там Fabrice Bellard показал с его tcc как надо было. У него настолько легкое вышло - что в эмуле - в браузере - и то вот таки - после загрузки на ЭТОМ линуха - норм ползает для мелких прог.

> Бутлоадер и сервисы MS Office 365 - это совершенно разные области применения.

Да. Однако универсальность тула - это его очень крутое достоинство. И почему бы я не должен его упомянуть сравнивая хруст с дотнетом?

> И меня если использование Rust в Linux Kernel меня не удивляет,
> то использование его в MS Office смутило.

Я видел некоторые продакшны с нетом - и думаю что MS таки сам себя завонял до состояния когда с его раджами - нанюхался. И готов достаточно радикально что-то делать для повышения предсказуемости и стабильности прода. Потому что дотнет VS прод это не сказать что беспроблемная штука. Особенно в нагруженной среде.

> Я понимаю, что Excel можно и на ассемблере написать. Но зачем?

В данном случае видимо - потому что GC, JIT, AOT и ко под нагрузкой могут такой user experience устроить - и при том рандомно и малопредсказуемо - что - возможно проще с ноля писать уже БЕЗ этой граблины. Ну вот не дружит GC с хайлоадом в общем случае.

Ответить | Правка | К родителю #408 | Наверх | Cообщить модератору

416. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от ptr (??), 04-Фев-24, 14:23 
> А чем это назвать?

Ограничением архитектуры, но уж никак не языка.
Ведь в том же AVR32 вполне возможно запускать код из RAM, несмотря на его Гарвардскую архитектуру. https://ww1.microchip.com/downloads/en/Appnotes/doc32160.pdf

> Где у 32L1 кеш то?

В 32L5 его добавили для решения этой проблемы.

> И что мне это дает в общем случае? Я ж не собираюсь с IR что-то делать.

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

> Мне JIT вообще не в кассу. Особенно в контейнерах. И хруст кроме всего прочего - нормальный компиляемый ЯП так то. Это его достоинство, имхо: не будет жрать ресурсы в проде на AOT/JIT.

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

> А зачем мне что-то компилить в именно контейнерах?

Чтобы не останавливать продуктивную систему для того, чтобы пересобирать и деплоить сотню сервисов из-за изменившихся метаданных. Например, protobuf в Kafka или gRPC можно парсить динамически, но это очень медленно. А можно скомпилировать обработчики для схем, что ускорит обработку почти на порядок. И тут выбор. Или компилировать в CI/CD, что заметно снижает доступность системы, или компилировать на лету, как только сервис обнаруживает сообщение с новой схемой или новой версией схемы.

> Однако универсальность тула - это его очень крутое достоинство.

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

А на данный момент, имеем грандиозную иерархию классов в .Net.Core, на которой базируется Office 365 и не имеем возможности ее просто конвертировать в Rust, так как её идеология наследования в Rust не поддерживается. Необходимо разрабатывать свою систему структур, типажей и макросов для создания чего-то подобного.

> Потому что дотнет VS прод это не сказать что беспроблемная штука. Особенно в нагруженной среде.

Там проблемы те же самые, что и в любом языке с GC и проистекают они именно из GC. Если включать мозги и максимально использовать стек, то проблемы решаемы.
Ну и следует понимать, когда лучше использовать среду с JIT (CLR, JVM, V8), а когда лучше компиляцию в машинный код.
Лично я против Rust ничего не имею. Сам использую plrust на PostgreSQL. Но он там совершенно не заменяет plpgsql, а лишь дополняет его. Но при этом высоконагруженные функции все равно пишу на C. Потому что на C можно напрямую работать со страницами PostgreSQL, что на Rust слишком сложно и все равно unsafe. А gRPC сервис, продьюсер или консьюмер к Kafka и т.п. - как раз задача для C#.

> Ну вот не дружит GC с хайлоадом в общем случае.

Надо уметь его готовить. Естественно, если нахреначить в каждом методе сотню переменных не в стеке - GC под нагрузкой не будет успевать их собирать. Как я писал выше, нужно понимать, где выиграешь больше: за счет динамической компиляции или за счет издержек GC. Иногда перевешивет одно, иногда другое. Что лишь подтверждает то, что "золотого молотка" не бывает и для каждой задачи следует подбирать свой инструмент.

Ответить | Правка | К родителю #414 | Наверх | Cообщить модератору

433. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 07-Фев-24, 20:01 
> Ограничением архитектуры, но уж никак не языка.

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

> Ведь в том же AVR32 вполне возможно запускать код из RAM

Насколько я помню AVR32 - успешно сдох. Нишмог в конкуренцию с армами, ни мк ни апликушники.

>> Где у 32L1 кеш то?
> В 32L5 его добавили для решения этой проблемы.

Это разные классы чипов. И той проблемы - как таковой нет. Кеш делает чип намного более быстрым и намного менее предсказуемым по jitter, что для МК - аргумент.

Более того - в сях штатно нет контроля над кешом и вы никак не можете контролировать запросит ли код I или D из кешированого региона или некешированого. При записи в флеху он, соответственно, поймает якорь. Семантическая корректность при единичной записи будет обеспечена - контролер флехи может запаузить ядро сигналом на шине пока не будет готов отдать ему что оно там хотело. Но времянки будут продолбаны, для управляющих систем это важно.

Одна из причин по которым до сих пор порой для настроек ставят 24Cxx в МКшные штуки, запись туда точно не якорит core, хоть как. Это про потерю управления на энное время.

> А почему нет? Я же делаю. Само собой, на основе ранее скомпиленного
> из языка высокого уровня шаблона.

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

> А как тогда делать рефлексию, динамически формируя оптимальный код для
> изменившихся метаданных?

С небольшой потерей оптимальности - наверное нечто такое можно изобразить указателем на функцию. И в принципе даже сгенерить кастомный вариант в RAM и на него указатель поставить.

Но Кента с вот этим - послали из ядра, он там пытался код генерить. Пришлось урезать осетра. И были правы. Ибо W^X violation и вообще, "premature optimization is a root of all evil" (c).

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

Линух без всего этого ворочает еще и не столько пакетов интернета запросто. Значит серебряные пули несколько переоценены...

> Компиляция в Rust весьма тяжелая.

Ну вот тут фиг поспоришь. Анализ видимо навороченный получается. Но и результат по своему приколен, нет оверхеда VM и рантайм проверок, а некие гарантии выживают. И well defined behavior. При всей хайповости, несколько вещей они сделали правильно.

> А вызов динамически скомпилированного кода - вообще целое приключение в unsafe.

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

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

Ну так компилят обычно на билдферме, а продакшн так то обычно умеет в graceful upgrade, при том нечто сравнимое даже нжинкс умел еще когда там.

> Например, protobuf в Kafka или gRPC можно парсить динамически, но это очень
> медленно. А можно скомпилировать обработчики для схем, что ускорит обработку
> почти на порядок. И тут выбор. Или компилировать в CI/CD, что заметно снижает
> доступность системы, или компилировать на лету, как только сервис обнаруживает
> сообщение с новой схемой или новой версией схемы.

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

>> Однако универсальность тула - это его очень крутое достоинство.
> Ассемблер еще более универсальней.

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

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

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

> Потому что специализированный инструмент удобней и работать им продуктивней.

А я то как баклан меняю биты в отвертке и шуруповерте... Если на кажлый размер Torx, Philips, Pozidriv, hex и slot взять по нескольку размеров, клад отверток вырисовывается. И это я еще pentalobe и что там еще более экзотичное не вспоминал, только повседневное.

> А на данный момент, имеем грандиозную иерархию классов в .Net.Core, на которой
> базируется Office 365 и не имеем возможности ее просто конвертировать в Rust,

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

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

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

Или к вопросу почему веб сейчас часто юзает "микросервисы". А вот чтоб с такими спагетти-монстрами дела не иметь. Мелкие гранулярные штуки проще адаптировать и намного меньше implementation constraints высосаных из пальца, типа вот этого вот бреда - для меня когда я вижу такие заявы, я понимаю насколько именно господа не умели в архитектуру продукта. Т.е. - вообще совсем. Увольте вашего архитекта: он не знал что делает и круто подставил вас.

> Там проблемы те же самые, что и в любом языке с GC

По этой причине хруст получает уникальный пойнт в нагруженном проде. Сюрприз!

> Ну и следует понимать, когда лучше использовать среду с JIT (CLR, JVM,
> V8), а когда лучше компиляцию в машинный код.

Для меня ответ по сути - "никогда". Ну может кроме JS, в фронтэнде.

> Лично я против Rust ничего не имею. Сам использую plrust на PostgreSQL.

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

У нормалных людей - да всем вообще ср@ть на чем микросервис написан. И так сильно проще постепенно менять это - без ломового отвала башки. А у дотнетчиков обычно получается страшенный макаронный монстр которого тронуть страшно. Потому и - переписать. С увольнением вон тех и архитекта за такую подставу нанимателю. Хреново когда в каком-то решении сложно переиграть решения. Это не достоинство дизайна.

> что на C можно напрямую работать со страницами PostgreSQL, что на
> Rust слишком сложно и все равно unsafe.

Rust вероятно задолбает в этом качестве.

> А gRPC сервис, продьюсер или консьюмер к Kafka и т.п. - как раз задача для C#.

Я от всего этого к счастью страшно далек.

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

Ну, кому надо - тот пусть и. А у меня нет желания греть мозг вот этой дрянью. Это анти-технологично и костыльно по максимуму. Особенно когда в новой версии могут логику изменить по желанию левой пятки, без предупреждения - и я таки видел что в результате получается! Еще вчера все было ЗБС. Сегодня кастомеры осадили саппорт, охренев от жора памяти. А весь офис жестко хардкорит в овертайм и выхи чтобы придумать хоть что-нибудь, соответственно.

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

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

Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

362. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от n00by (ok), 03-Фев-24, 07:54 
> отдельный вопрос, что на Rust собираются делать с повсеместно используемой в
> .Net.Core рефлексией. Вплоть до генерации и компиляции на лету Action.

Если кастомер захочет рефлексию на Rust, он арендует мощности на Azure. Вроде годный бизнес-план?

Ответить | Правка | К родителю #340 | Наверх | Cообщить модератору

349. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Александр (??), 03-Фев-24, 01:39 
Очень странно слышать про алгоритмы от "знающего" программирование. Не знаю, может вы специалист какой-то узкой направленности, и ваш код ограничивается алгоритмами и константами, но в реальных продуктах над этим всем есть ещё три тонны абстракций, которые и опираются на имеющуюся и наиболее популярную модель ООП.
Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

280. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от wyry (?), 02-Фев-24, 04:40 
В C# GC очень производительный и очень кастомизированный. Можно сделать так, чтобы вызывать его вообще вручную в нужные моменты, в таком случае производительность будет почти такой же, не говоря о том, что C# может работать с unsafe ресурсами, которые по понятным причинам нужно освобождать ручками и так никто не делает, если нет прямой необходимости.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

360. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от Аноним (-), 03-Фев-24, 06:18 
> В C# GC очень производительный и очень кастомизированный. Можно сделать так, чтобы
> вызывать его вообще вручную в нужные моменты, в таком случае производительность
> будет почти такой же, не говоря о том, что C# может работать с unsafe ресурсами,

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

Ответить | Правка | Наверх | Cообщить модератору

385. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +/–
Сообщение от wyry (?), 03-Фев-24, 15:31 
Как всегда дешёвый наброс. В своё время в моду вошла функциональщина (OCaml, Haskell, LISP, Microsoft даже свой F# запилили как один диалект ML). И более того, тогда обоснование было значительно умнее. Rust же использует идеи владения, которые, вообще говоря, появились ещё в C++98 и со временем были доработаны. Это НЕ инновация, а грубое и глупое переиначивание уже существующих идей, которые уродливо выглядят уже на этапе проектирования. Взять C (чистый C), когда он был разработан - он сразу же использовался для создания нового софта, причём довольно широко, при этом фактически не меняясь. Rust мало того что разрабатывается временами ломая обратную совместимость (что уже красный флаг, но простим), так на нём фактически за всё время было создано критически мало проектов и вы этим хотите похоронить жабу или C# или C++ или C чистый?
+Ладно бы всё это обсуждалось в США, где язык был создан, в России (а на деле и в остальном мире) своя "мода" на программирование. В РФ C++ уже клещами не вытащишь: одна из лучших в мире школ C++, множество идеологов и инженеров C++, ровно как и весь крупный бизнес. Так сложилось исторически и это не поменяется. То есть помимо спорной (назовём это так) конкуренции в инженерном поле, Rust точно проиграет в бизнес и политическом поле за пределами США и их ближайших деловых партнёров (при том что и там C и C++ в лидерах высокопроизводительных решений!), остальные же как писали на C++, так и будут до скончания времён.
Ответить | Правка | Наверх | Cообщить модератору

390. "Microsoft наймёт разработчиков для переписывания сервисов с ..."  +1 +/–
Сообщение от Аноним (366), 03-Фев-24, 19:13 
> Как всегда дешёвый наброс.

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

Хруст в этом смысле - мало чем хуже плюсов, на горе вон тех. Он компилтайм все и вся чекает, никаких виртуалок и GC нету, как и ктулху упаси, JIT и чего там еще. Get the facts, как говорится. Приятно майкрософтовским чувакам вернуть их методы и фразы, лол. Люблю симметрию.

> В своё время в моду вошла функциональщина (OCaml, Haskell, LISP,

Академигрушки. Широко известные в узких кругах. Практически значимых проектов на этом - ноль целых, фиг десятых. Если ЭТО завтра испарится, вместе с авторами - кто на этом глобусе вообще заметит разницу? Поезда не остановятся. Спутники не упадут. Компьютеры продолжат работать. И 99.9(9)% людей смогут делать все то же что и вчера.

> Microsoft даже свой F# запилили как один диалект ML).

И чего? Они и некое Singularity запилили. Или Windows Phone. И где оно все теперь? Крупные корпорации могут делать некоторое количество странной фигни. По принципу "не взлетит и черт с ним".

> И более того, тогда обоснование было значительно умнее. Rust же использует
> идеи владения, которые, вообще говоря, появились ещё в C++98 и со
> временем были доработаны. Это НЕ инновация, а грубое и глупое переиначивание

Возможно. Зато - довольно прагматичное. Комитет придурков уже в 99 году стал догадываться что сишные типы целых - оставляют желать и в C99 появился stdint.h с более вменяемо определенными типами. Но сделать это не через Ж их не хватило. И вот почти четверть века спустя UB в целых числах до сих пор не попускает. А вот хрустики почему-то смогли заморочиться этим топиком. Я не понимаю - в чем проблема явно сказать какого размера тип, и задефайнить что случается при его переполнении, дабы избежать тысяч и тысяч простреленных пяток. И в ++ весь этот идиотизм на месте. Из за одно только определение "int" надо уволить полным составом. Почти ни 1 программа не сможет столкнуться с краевыми случаями "int" и т.п. валидными по стандарту.

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

Ну вообще-то K&R C vs более поздние - отличается. А C99 с более вменяемыми типами для лично меня - граница водораздела. Я искренне ненавижу дефолтные сишные типы - они адовый источник проблем и CVE.

> Rust мало того что разрабатывается временами ломая обратную совместимость

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

Да блин, даже в C2X вон грозятся покилять bool. Черт его знает зачем. Но на 100% это не будет совместимо по сорцу.

> критически мало проектов и вы этим хотите похоронить жабу или C# или C++ или C чистый?

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

> программирование. В РФ C++ уже клещами не вытащишь: одна из лучших в мире школ C++,

Не сказал бы - половина делают "си с классами" а то и вовсе CPP обзывают ради коментов //. А реально - гольный си. На память о том что майки за ...цать лет C99 нишмагли.

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

> Rust точно проиграет в бизнес и политическом поле за пределами США

Ему будет достаточно выиграть там - ибо 90% ПО там и создается. Остальных никто и спрашивать не будет. И куда индейцы денутся...? Сами все напишут? ORLY?

> остальные же как писали на C++, так и будут до скончания времён.

Ну вот нужда именно убежденному мощному плюсеру ломиться на хруст - да, там можно поспорить. Особенно если этот плюсер понмает что делать с UB и проблемами аллокации.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру