По моему личному опыту, разработка CRUD на Rust (Actix Web, SqlX, Postgres) была в среднем равна по скорости разработке на Node.JS и Typescript (хотя и разрабатывал я его в одиночку). В однотипном (и достаточно простом, чего уж) коде, коим является CRUD, проблемы и ошибки достаточно однотипны, и сильной просадки по скорости разработки не было.
Ощущения от разработки на Rust, конечно, совершенно другие, чем от Typescript, почти нет мелких досадных ошибок типизации (хотя и на Тайпскрипте их не очень много, по сравнению с чистым Джаваскриптом, не представляю, как люди нем пишут), основные ошибки - в логике программы. Хотя код получается более объемным.
mysql -u root -p -h mysql-set-0.mysql.default.svc.cluster.local - вот эта строчка подключается напрямую к контейнеру? Или сервис создает "подсервисы" для каждого пода стейтфул сета?
Не знаю, насколько удобно разрабатывать веб в С++, но Раст обеспечивает сравнимое с асп.нет удобство (все же, несколько ниже - так как нету LINQ, но все же есть sqlx, который делает работу с базой не совсем ужасной, но ).
Вообще, имхо, Раст - сильно опережает другие варианты по сочетанию "скорость работы + скорость разработки"
Насколько я понимаю, для того, чтобы иметь (хотя бы теоретическую) возможность zero runtime, язык должен:
Не иметь неубираемых внешних зависимостей (например, интерпретатора или сборщика мусора). Тут возникает вопрос, считать ли отсутствием зависимостей случай статической линковки. В случае этой статьи, очевидно, автор под zero runtime имеет ввиду возможность близкой к 1:1 трансляции в ассемблер. Это, на мой взгляд, не совсем верно, но ладно.
Не иметь добавляемого библиотечного кода, т.е. иметь так называемые zero-cost abstractions. Тоже спорно, но ладно, автор так решил.
Третье условие - языком должно быть возможно пользоваться на этих условиях.
Итак, отвечает ли Раст этим условиям? Вроде отвечает. Обязан ли он быть в этих условиях более эффективным по машинному коду, чем С? Ну типа автор оригинальной статьи это подразумевает, но непонятно с какой стати. В таких условиях практически любой язык - это будет вариант С, только с другим синтаксисом + генерируемый или библиотечный код (типа тех же методов итераторов), который можно использовать или нет.
Почему циклы, ветвления, арифметические операции (хотя тут есть особенность из-за defined/undefined behaviour), вызовы функций должны отличаться сколько нибудь заметно? Настолько ли это важно, что прям из-за трех лишних байт в ассемблере в bare metal mode Раст должен прям умереть?
Удивляет, что у некоторых людей присутствует иррациональная ненависть к Расту. Я так понимаю, в основном это сишники и плюсеры. Казалось бы, не нравится - проходи мимо. Аналогичное явление я наблюдал у линуксоидов, НЕНАВИДЯЩИХ виндоуз.
Я с вами согласен, и во многом поддерживаю (особенно в плане дискомфортных условий для тренировок, я сам бегал и в -15, и в +35), но понимаю, что это ДАЛЕКО не для всех.
Вам повезло в том, что вам нравится преодолевать трудности, получая за это вознаграждение - сильное и красивое тело. (В теории-то это всем нравится, но на практике - единицам). Но обычному человеку (в том числе и мне, но я себя заставляю) хочется делать поменьше, а получать побольше, и такие условия тренировок, как у вас, отобьют желание тренироваться на годы вперед.
Мужчины воспринимают знаки внимания от женщин в основном положительно (даже от тех, с которыми заведомо не согласны на секс), женщины - в основном отрицательно, вплоть до резко отрицательного. Я думаю, это связано с тем, что женщина подсознательно воспринимает мужчину как источник опасности, в то время как мужчина женщину - нет.
Просто мы разные, как и говорит автор, не знаю, что в этом плохого видят женщины.
Это самый большой недостаток дешевых кресел - подлокотники не отодвигаются назад достаточно сильно, чтобы можно было подвинуться к столу и одновременно оставить подлокотники на высоте стола
Мне кажется, вас немного зацепило слово "автоматизация"? Я его употребил в широком значении, как написание продукта в какой-то области вне абстрактного программирования.
Ну например, из моей практики, писал систему управления инвестициями пенсионных накоплений одной европейской страны. Частная компания, люди туда обращаются, чтобы вложить накопительную часть пенсии в какие-то акции.
Звонит заказчик, говорит: "число в отчете считается неправильно, надо исправить". Чтобы исправить, надо понимать (а чтобы понимать - разобраться), как это все считается, действительно ли оно неправильно, тк заказчик не всегда помнит и учитывает все возможные варианты данных.
Изучаешь, как компания рассчитывает доходность портфеля акций, как выбирает рекомендации и так далее. Разбираешься, оказывается, что считается правильно, но для некоторых пользователей не хватает данных (и это нормально).
Дальше вместе с заказчиком (который финансист, а не программист) ищете решение, и вам нужно говорить на одном языке, а для этого нужно понимать, о чем ты говоришь, владеть темой на каком-то уровне.
Зависит от уровня, джуны - почти никогда (и зря, кстати), тк в основном получают простые задания, не требующие понимания ни предметной области, ни структуры программы. Синьоры - почти постоянно, тк требования, даже если они есть и сформированы, а не получены от заказчика напрямую, надо их анализировать, дополнять, просчитывать крайние случаи, и интегрировать в существующую архитектуру. И без понимания автоматизируемых процессов качественно это сделать невозможно.
Ну и еще, конечно, очень зависит от области. Во фронтенде этого почти нет (тк там особо не принципиально, от чего этот скрин), в бекенде - очень часто.
ПС Автоматизация - это разработка приложения, в данном случае
Очевидно, потому, что это не одно и то же
Абсолютно ничего. Детская порнография запрещена из-за того, что происходит при ее производстве. Кто страдает при производстве игр?
Что аморального в "убийстве" пикселей?
По моему личному опыту, разработка CRUD на Rust (Actix Web, SqlX, Postgres) была в среднем равна по скорости разработке на Node.JS и Typescript (хотя и разрабатывал я его в одиночку). В однотипном (и достаточно простом, чего уж) коде, коим является CRUD, проблемы и ошибки достаточно однотипны, и сильной просадки по скорости разработки не было.
Ощущения от разработки на Rust, конечно, совершенно другие, чем от Typescript, почти нет мелких досадных ошибок типизации (хотя и на Тайпскрипте их не очень много, по сравнению с чистым Джаваскриптом, не представляю, как люди нем пишут), основные ошибки - в логике программы. Хотя код получается более объемным.
mysql -u root -p -h mysql-set-0.mysql.default.svc.cluster.local - вот эта строчка подключается напрямую к контейнеру? Или сервис создает "подсервисы" для каждого пода стейтфул сета?
Помимо скорости, важно и удобство разработки.
Не знаю, насколько удобно разрабатывать веб в С++, но Раст обеспечивает сравнимое с асп.нет удобство (все же, несколько ниже - так как нету LINQ, но все же есть sqlx, который делает работу с базой не совсем ужасной, но ).
Вообще, имхо, Раст - сильно опережает другие варианты по сочетанию "скорость работы + скорость разработки"
Насколько я понимаю, для того, чтобы иметь (хотя бы теоретическую) возможность zero runtime, язык должен:
Не иметь неубираемых внешних зависимостей (например, интерпретатора или сборщика мусора). Тут возникает вопрос, считать ли отсутствием зависимостей случай статической линковки. В случае этой статьи, очевидно, автор под zero runtime имеет ввиду возможность близкой к 1:1 трансляции в ассемблер. Это, на мой взгляд, не совсем верно, но ладно.
Не иметь добавляемого библиотечного кода, т.е. иметь так называемые zero-cost abstractions. Тоже спорно, но ладно, автор так решил.
Третье условие - языком должно быть возможно пользоваться на этих условиях.
Итак, отвечает ли Раст этим условиям? Вроде отвечает. Обязан ли он быть в этих условиях более эффективным по машинному коду, чем С? Ну типа автор оригинальной статьи это подразумевает, но непонятно с какой стати. В таких условиях практически любой язык - это будет вариант С, только с другим синтаксисом + генерируемый или библиотечный код (типа тех же методов итераторов), который можно использовать или нет.
Почему циклы, ветвления, арифметические операции (хотя тут есть особенность из-за defined/undefined behaviour), вызовы функций должны отличаться сколько нибудь заметно? Настолько ли это важно, что прям из-за трех лишних байт в ассемблере в bare metal mode Раст должен прям умереть?
Удивляет, что у некоторых людей присутствует иррациональная ненависть к Расту. Я так понимаю, в основном это сишники и плюсеры. Казалось бы, не нравится - проходи мимо. Аналогичное явление я наблюдал у линуксоидов, НЕНАВИДЯЩИХ виндоуз.
Я с вами согласен, и во многом поддерживаю (особенно в плане дискомфортных условий для тренировок, я сам бегал и в -15, и в +35), но понимаю, что это ДАЛЕКО не для всех.
Вам повезло в том, что вам нравится преодолевать трудности, получая за это вознаграждение - сильное и красивое тело. (В теории-то это всем нравится, но на практике - единицам). Но обычному человеку (в том числе и мне, но я себя заставляю) хочется делать поменьше, а получать побольше, и такие условия тренировок, как у вас, отобьют желание тренироваться на годы вперед.
Даже если у тебя длинные ноги - ты не обязательно быстро бегаешь
Мужчины воспринимают знаки внимания от женщин в основном положительно (даже от тех, с которыми заведомо не согласны на секс), женщины - в основном отрицательно, вплоть до резко отрицательного. Я думаю, это связано с тем, что женщина подсознательно воспринимает мужчину как источник опасности, в то время как мужчина женщину - нет.
Просто мы разные, как и говорит автор, не знаю, что в этом плохого видят женщины.
Можно сказать так - что женщину бесит, когда к ней пристает тот, кто ей не нравится, или не пристает тот, кто нравится.
Надо загрызть гранит науки
Каждый пишет о важном для себя (никаких негативных коннотаций и осуждений, просто такая особенность у людей)
Перейду, если будет Type-C
Это самый большой недостаток дешевых кресел - подлокотники не отодвигаются назад достаточно сильно, чтобы можно было подвинуться к столу и одновременно оставить подлокотники на высоте стола
Мне кажется, вас немного зацепило слово "автоматизация"? Я его употребил в широком значении, как написание продукта в какой-то области вне абстрактного программирования.
Ну например, из моей практики, писал систему управления инвестициями пенсионных накоплений одной европейской страны. Частная компания, люди туда обращаются, чтобы вложить накопительную часть пенсии в какие-то акции.
Звонит заказчик, говорит: "число в отчете считается неправильно, надо исправить". Чтобы исправить, надо понимать (а чтобы понимать - разобраться), как это все считается, действительно ли оно неправильно, тк заказчик не всегда помнит и учитывает все возможные варианты данных.
Изучаешь, как компания рассчитывает доходность портфеля акций, как выбирает рекомендации и так далее. Разбираешься, оказывается, что считается правильно, но для некоторых пользователей не хватает данных (и это нормально).
Дальше вместе с заказчиком (который финансист, а не программист) ищете решение, и вам нужно говорить на одном языке, а для этого нужно понимать, о чем ты говоришь, владеть темой на каком-то уровне.
Зависит от уровня, джуны - почти никогда (и зря, кстати), тк в основном получают простые задания, не требующие понимания ни предметной области, ни структуры программы. Синьоры - почти постоянно, тк требования, даже если они есть и сформированы, а не получены от заказчика напрямую, надо их анализировать, дополнять, просчитывать крайние случаи, и интегрировать в существующую архитектуру. И без понимания автоматизируемых процессов качественно это сделать невозможно.
Ну и еще, конечно, очень зависит от области. Во фронтенде этого почти нет (тк там особо не принципиально, от чего этот скрин), в бекенде - очень часто.
ПС Автоматизация - это разработка приложения, в данном случае
Доберман милашка