Да, всё это есть, и полгода занимает переключиться с стиля/формата/ревьюеров на предыдущем месте работы на новые. В примерно одинаковых проектах в двух биг-тек компаниях одни фигачат сервера на корутинах и вообще полный C++20, в другой сплошные коллбэки и исключения отключены по историческим причинам.
Две разницы объясняются тем, что одни языки придуманы оптимистами: "давайте дадим программистам удобные инструменты и они будут писать прекрасные программы", а другие - пессимистами: "если этим волю дать, они случайно или намеренно, но таких чудес наворотят". Я за вторых, я слишком хорошо себя знаю.
Нет. C++ в любых более-менее сложных проектах практически нечитаем без года работы именно с этой кодовой базой. Rust тоже не подарок, но всё-таки чуть более идиоматичен. К тому же у него единый стиль форматирования и clippy поддерживает хоть какие-то минимальные стандарты.
Мне тоже C++ проще читать чем другие языки, но это исключительно в силу того, что я с ним намного дольше работаю. К самому языку отношения не имеет, разве что в минус. Это особенно хорошо заметно, когда я натыкаюсь на код использующий непопулярные среди меня возможности языка, те же тяжёлые шаблоны - сразу всё выглядит как набор бессмысленных символов.
Автор почему-то думает, что в однопоточном коде он может безопасно лазить в глобальный стейт как хочет и ему ничего за это не будет. Хотя обратный пример "начал править стейт, вызвал функцию, в ней коллега ВНЕЗАПНО добавил чтение этого полуразобраного стейта" вполне тривиален.
Я понимаю, что геймдев, что даже AAA игры стоит покупать только после второго патча и т.д. Но есть разница между "пусть горит, не жалко" и "это безопасно".
Когда у вас сервис, который херачит газиллионы RPS и гигабит по всему миру, и если он начнёт течь или падать, то клиенты моментально уведут трафик к конкурентам вместе со своими десятками миллионов долларов (каждый), а если станет раздавать битые данные, то вообще хоть вешайся - тут компилятор, который лупит линейкой по пальцам прям очень приятный.
PS. Я работаю в их конкуренте. Наш аналог сделан на плюсах, и как ни украшай C++ ленточками, а всё равно рога торчат.
И ведь логично было бы поправить самые крупные косяки, но нет, все заплаточки аккуратно пришиваются сверху чтобы "не дай боже старая всем нужная библиотека не сломалась". Ну раз она старая и всем нужная, разве никто не проапгрейдит ее?
Проблема в том, что это не одна такая библиотека, а они примерно все такие. Переход на новый стандарт C++, временами даже на новую версию компилятора, это довольно нетривиальный процесс если у вас миллионы строк кода временами почтенного возраста. Если эти миллионы строк кода ещё и не у вас, а у пользователей вашего тулкита по всему миру, то становится ещё больнее и дороже.
Добавить сверху "а теперь мы выкидываем это древнее говно" - и вас уже могут просто поколотить.
Насколько я понял, авторы Tornado Cash упорно держали поднятым веб-интерфейс к этому контракту, даже когда сервис назвали средством отмывания денег. Если это так, то они очень напрашивались на посадку - и напросились. Игнорировать такие предупреждения можно только на свой страх и риск.
Может обслуживаться чем угодно, безусловно. Я даже вспомнил один довольно большой и успешный бэкенд на питоне, правда в нестандартной инкарнации: Eve Online, по состоянию на десять лет назад. Другой вопрос, что это очередной случай когда выбор простого инструмента позволил компании вообще не умереть вначале, но потом заставил тратить кучу денег на последствия этого решения. Два стула, так сказать.
Я в общем-то не спорю, что большая часть задач в IT может быть решена на самых разных языках, включая PHP и JS. Так же как большая часть автоперевозок может быть осуществлена на чём попало, и вообще большая часть чего угодно в любой отрасли может быть сделана из подручных материалов. Сарайчиков строится гораздо больше, чем небоскрёбов, и инструменты для них нужны разные.
Если бэкенд можно написать на питоне, то это не бэкенд а так, бэкендик. А я про настоящие :)
Или,в редких случаях, людям настолько нужен именно питон для специалистов в предметной области и прочих ресерчеров, что ради этого они готовы героически преодолевать и лишаться. Но это редкий вариант.
Ну так перекладывальщик JSON и не является целевой аудиторией Rust. Это язык для бэкенда, для ядра и т.д. И среди этой группы десяток гигабайт памяти уже не такая редкость. И пауза в 10ms, а если не повезёт то и в 100ms, тоже не только для HFT важна.
Будут технические проблемы из-за того что никто никогда не ставил цели "формально определить поведение".
Цели-то такие может и ставили, но вот достичь их оказалось невозможно: в комитете слишком много участников с несовпадающими интересами. Например, именно поэтому в стандарте C у мьютексов нет возможности проверить, захвачен он текущим потоком или нет. Между разработчиками FreeBSD и кем-то из комитетчиков был феерический срач на эту тему в какой-то рассылке.
"Почти нет" это в смысле что простому перекладывателю JSONов никогда не придётся их увидеть? Для бэкенда это не такие большие числа.
Десяток гигабайт памяти это всего десять тысяч параллельных запросов по мегабайту каждый. А мегабайт это вообще ни о чём сейчас: открываешь какой-нибудь facebook.com и первым же ответом прилетает полмегабайта, ещё до того как ресурсы грузиться начнут.
Если десять тысяч слишком страшно, то пусть будет тысяча по десять мегабайт, невелика разница.
Rust это язык специально сделаный для перфекционистов. С заметно большей практической жилкой, чем Haskell, но всё равно, "компилятор будет лупить тебя плёткой пока ты не сделаешь как положено" - это не проблема, это sales pitch.
Если с нуля писать, то не настроить, но писать с нуля совершенно необязательно. Берём mbedOS, например, и там всё чудесно инициализируется по умолчанию, а sleep_for() принимает аж литералы времени типа 5s
Или например моя самоделка вообще на Rust в качестве часов использует LPTIMER, и частота ядра ей для работы со временем вообще по барабану. Если PWM понадобится - тогда да, придётся считать.
Да, всё это есть, и полгода занимает переключиться с стиля/формата/ревьюеров на предыдущем месте работы на новые. В примерно одинаковых проектах в двух биг-тек компаниях одни фигачат сервера на корутинах и вообще полный C++20, в другой сплошные коллбэки и исключения отключены по историческим причинам.
Две разницы объясняются тем, что одни языки придуманы оптимистами: "давайте дадим программистам удобные инструменты и они будут писать прекрасные программы", а другие - пессимистами: "если этим волю дать, они случайно или намеренно, но таких чудес наворотят". Я за вторых, я слишком хорошо себя знаю.
Си с классами скорее всего переедет без проблем. Си с классами и std:: тоже переедет. Что-нибудь посложнее - и начинают лезть интересные нюансы.
Нет. C++ в любых более-менее сложных проектах практически нечитаем без года работы именно с этой кодовой базой. Rust тоже не подарок, но всё-таки чуть более идиоматичен. К тому же у него единый стиль форматирования и clippy поддерживает хоть какие-то минимальные стандарты.
Мне тоже C++ проще читать чем другие языки, но это исключительно в силу того, что я с ним намного дольше работаю. К самому языку отношения не имеет, разве что в минус. Это особенно хорошо заметно, когда я натыкаюсь на код использующий непопулярные среди меня возможности языка, те же тяжёлые шаблоны - сразу всё выглядит как набор бессмысленных символов.
Вы определитесь, пожалуйста: или https://habr.com/ru/articles/758566/comments/#comment_25935352
или Rust ужасный язык, потому что для идиотов.
Оба сразу - нельзя.
Автор почему-то думает, что в однопоточном коде он может безопасно лазить в глобальный стейт как хочет и ему ничего за это не будет. Хотя обратный пример "начал править стейт, вызвал функцию, в ней коллега ВНЕЗАПНО добавил чтение этого полуразобраного стейта" вполне тривиален.
Я понимаю, что геймдев, что даже AAA игры стоит покупать только после второго патча и т.д. Но есть разница между "пусть горит, не жалко" и "это безопасно".
Конечно. Вот, например: https://blog.cloudflare.com/introducing-oxy
Когда у вас сервис, который херачит газиллионы RPS и гигабит по всему миру, и если он начнёт течь или падать, то клиенты моментально уведут трафик к конкурентам вместе со своими десятками миллионов долларов (каждый), а если станет раздавать битые данные, то вообще хоть вешайся - тут компилятор, который лупит линейкой по пальцам прям очень приятный.
PS. Я работаю в их конкуренте. Наш аналог сделан на плюсах, и как ни украшай C++ ленточками, а всё равно рога торчат.
А, я думал вам от строковой константы надо. Если от динамического источника, то да, увы.
Проблема в том, что это не одна такая библиотека, а они примерно все такие. Переход на новый стандарт C++, временами даже на новую версию компилятора, это довольно нетривиальный процесс если у вас миллионы строк кода временами почтенного возраста. Если эти миллионы строк кода ещё и не у вас, а у пользователей вашего тулкита по всему миру, то становится ещё больнее и дороже.
Добавить сверху "а теперь мы выкидываем это древнее говно" - и вас уже могут просто поколотить.
shared immutable строки в C++ это разве не std::string_view?
Насколько я понял, авторы Tornado Cash упорно держали поднятым веб-интерфейс к этому контракту, даже когда сервис назвали средством отмывания денег. Если это так, то они очень напрашивались на посадку - и напросились. Игнорировать такие предупреждения можно только на свой страх и риск.
Может обслуживаться чем угодно, безусловно. Я даже вспомнил один довольно большой и успешный бэкенд на питоне, правда в нестандартной инкарнации: Eve Online, по состоянию на десять лет назад. Другой вопрос, что это очередной случай когда выбор простого инструмента позволил компании вообще не умереть вначале, но потом заставил тратить кучу денег на последствия этого решения. Два стула, так сказать.
Я в общем-то не спорю, что большая часть задач в IT может быть решена на самых разных языках, включая PHP и JS. Так же как большая часть автоперевозок может быть осуществлена на чём попало, и вообще большая часть чего угодно в любой отрасли может быть сделана из подручных материалов. Сарайчиков строится гораздо больше, чем небоскрёбов, и инструменты для них нужны разные.
Если бэкенд можно написать на питоне, то это не бэкенд а так, бэкендик. А я про настоящие :)
Или,в редких случаях, людям настолько нужен именно питон для специалистов в предметной области и прочих ресерчеров, что ради этого они готовы героически преодолевать и лишаться. Но это редкий вариант.
Ну так перекладывальщик JSON и не является целевой аудиторией Rust. Это язык для бэкенда, для ядра и т.д. И среди этой группы десяток гигабайт памяти уже не такая редкость. И пауза в 10ms, а если не повезёт то и в 100ms, тоже не только для HFT важна.
Цели-то такие может и ставили, но вот достичь их оказалось невозможно: в комитете слишком много участников с несовпадающими интересами. Например, именно поэтому в стандарте C у мьютексов нет возможности проверить, захвачен он текущим потоком или нет. Между разработчиками FreeBSD и кем-то из комитетчиков был феерический срач на эту тему в какой-то рассылке.
"Почти нет" это в смысле что простому перекладывателю JSONов никогда не придётся их увидеть? Для бэкенда это не такие большие числа.
Десяток гигабайт памяти это всего десять тысяч параллельных запросов по мегабайту каждый. А мегабайт это вообще ни о чём сейчас: открываешь какой-нибудь facebook.com и первым же ответом прилетает полмегабайта, ещё до того как ресурсы грузиться начнут.
Если десять тысяч слишком страшно, то пусть будет тысяча по десять мегабайт, невелика разница.
Rust это язык специально сделаный для перфекционистов. С заметно большей практической жилкой, чем Haskell, но всё равно, "компилятор будет лупить тебя плёткой пока ты не сделаешь как положено" - это не проблема, это sales pitch.
Если это трололо, то прекрасное. Если серьёзно, то лучше бы было трололо :)
"Посмотрите, как при помощи усердия и прилежания в языке X можно сделать то же самое, что в Y реализуется при помощи тайпчекера."
И ведь у C++ система типов довольно слабая, но даже она лучше, чем ничего.
Тем, кто хочет по-прежнему использовать mutex, но не нарываться на проблему "захватили не тот mutex" или "не захватили вообще", могу порекомендовать аннотации из Abseil для проверок во время компиляции: https://abseil.io/docs/cpp/guides/synchronization#thread-annotations
Если с нуля писать, то не настроить, но писать с нуля совершенно необязательно. Берём mbedOS, например, и там всё чудесно инициализируется по умолчанию, а sleep_for() принимает аж литералы времени типа
5sИли например моя самоделка вообще на Rust в качестве часов использует LPTIMER, и частота ядра ей для работы со временем вообще по барабану. Если PWM понадобится - тогда да, придётся считать.