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