У многих компаний есть свои карты компетенций, где расписано на какой грейд какие технологии нужны. К сожалению, эти карты от компании к компании сильно отличаются, как и предлагаемая зп.
Потому что все это субъективщина.
Так или иначе нужен инструмент, который бы усреднял требования и давал представление о ситуации.
Вопрос в том кому нужен? Работодателям очевидно не нужен так как никто в этом направлении как не чесался так и не чешется особо.
Ну окей, нужен инструмент, как будем строить систему грейдов? По "стандартной лестнице: Junior, Middle, Senior" ? Ну ок, джун - тот кто еще не самостоятельный а мид тот кто уже самостоятельный а сеньор это вообще кто? Абстрактный опытный разработчик? Ну ок. А мид который еще не сеньор но уже не простой рядовой разработчик это кто? Сеньор с 5 годами опыта и с 10 годами это одни и тот же грейд или нужно делить еще на 3-5 подгрейдов? Итого получим 6-10 грейдов. Дальше выясняется что обычно с уровня условного сеньора идет специализация, когда одни хорошо разбирается в БД, другой в DevOps, третий в многопоточности, четвертый проектирует неплохо а пятый просто решала. Как эти критерии рассчитывать, делать сетку навыков под каждую возможную специализацию? А как оценивать пересечение специализаций когда человек несколько специальностей знает? А как оценить специалиста с хорошей базой и гибким мышлением, который по новой технологии доки за вечер прочитает и на коленке сделает? Ну и наконец, будут ли оцениваться навыки вызывающие споры? Ну например, у кого-то есть навыки в продвинутом ООП, DDD SOLID, чистых архитектурах и прочем а кто-то считает это бесполезным и даже вредным. Есть еще функциональное программирования. Как такое оценивать, чтобы привести всех к общему знаменателю? Кто-то гордится что он чистый код пишет а кто-то пишет эффективный. Как быть?
Вердикт: Грейд — это ваша способность управлять сложностью, а не стаж в трудовой книжке.
Грейд - это ваша способность зарабатывать деньги.
Можно долго пытаться убеждать себя что в грейдах есть какой то смысл, корреляция с опытом, управлением какой-то сложностью и прочее. Но на деле грейд - это не более чем навык подстраиваться под хотелки конкретной компании, такие как: умение хорошо собеседоваться, умение дружить с руководством и иметь своих людей на правильных позициях, умение подстраиваться под внутренние требования, какими бы абсурдными они не были, для того чтобы получать больше денег.
Да хотелось бы чтобы корреляция с опытом была но нет в современных компаниях этого нет уже давно.
А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования.
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось. Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.
А если у вас более сложная архитектура?
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
Классный ответ, правда и ошибки С++, это тоже "проблемы разработчика, а не языка".
Проблема Rust в том, что он в принципе не может реализовать некоторые алгоритмы без вставок unsafe кода.
У Вас такое развлечение, носиться из статьи в статью с одними и теми же заезженными до дыр тезисами, о том что если язык не гарантирует вам абсолютную безопасность во всем то он ничем не лучше языка который при любом неловком движении отстреливает вам конечности?
Проблема такого подхода в том что если в Rust все это появится то Вы начнете жаловаться на то что на льду поскользнулись при этом пишете на Rust а он плохой такой вроде бы вам безопасность гарантировал.
И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно".
Чисто для интереса. Вот Вы так сокрушаетесь что людей не переубедить. А Вам никогда не приходила мысль, хотя бы на долю секунды, что чисто гипотетически Вы можете быть не правы?
Поэтому я решил попробовать доказать вам, что принципы разработки (почти как законы физики)
А если ли у этих принципов явные и понятные всем а главное однозначные формулировки? Ну например что такое ответственность а как ее рассчитать для конкретного случая? Есть ли доказательства эффективности применимости данных принципов отличные от субъективного восприятия? Или основной показатель эффективности - это "я считаю оно работает у меня а значит работает у всех"?
Для дрели: кнопка под указательным пальцем должна управлять только оборотами. Нельзя на неё вешать переключение на перфорацию.
Не скажу за дрель, но в схожих условиях в оружии, спусковой крючок часто используют и для стрельбы и для переключения ведения режимов огня и как предохранитель и ничего.
L - Liskov Substitution Principle (Принцип подстановки Барбары Лисков). Классы-наследники не должны противоречить базовому классу.
Советую изучать лучше данный принцип. Там нет ничего про классы.
А теперь вопрос - сколько ещё будут держаться эти принципы? Через сколько лет вы захотите чтобы производители дрелей перестали этого придерживаться?
И очень хорошо, что инженеры когда проектируют различные решения, не забивают себе голову такими глупостями и догмами а проектируют реализацию исходя из требований и собственной смекалки.
Яркий пример из Второй мировой - зенитная артиллерия. Эта та которая по самолетам стреляет. Вместо того чтобы всякие единственные ответственности соблюдать, инженеры сделали орудие которое может стрелять и по земле а более того были сделаны противотанковые снаряды. И более того, впоследствии оказалось что зенитное орудие едва ли не лучшее противотанковое средство. После чего в Германии и СССР стали ставить слегка модифицированные зенитные орудия на танки. А вот если бы знали про SOLID не страдали бы видиом фигней и делали зенитные орудия которые могут стрелять только по самолетам.
Имхо, гораздо легче воспринимать и читать код, когда разработчик позаботился о том, чтобы завернуть его в класс.
Гораздо проще читать код, когда в нем нет ничего лишнего, например класса, который используется не по прямому назначению а только для того чтобы в него что-то завернуть.
кстати, эту же идею Вы можете обнаружить в книге "Чистый Код" от Роберта Мартина
Лучше, вместо того чтобы читать старые книги сомнительного содержания, почитать свежий блог автора этой книги. Откроете для себя много нового, например что у него сейчас любимый язык на котором он пишет это Clojure, и что он за минималистичность простоту и про прочее за все хорошего против всего плохого.
У Вас одна публичная функция а значит для любого пользователя класса - у Вас только одна функция. То что Вы написали внутри 10-20 приватных для своего удобства это никак не меняет семантики - можете все скомпоновать в одну или разбирать на 1000, для пользователя класса ничего не измениться. Более того, если Вы перепишите класс на обычную функцию которая будет вызывать вспомогательные функции, по большей части ничего не измениться, потому что никакие особые свойства объектов не используете.
Единственный публичный метод. Вся работа с сервисом ведётся через метод call. Избавляемся от проблемы когда разработчики начинают придумывать run-ы, execute-ы, process-ы и т.д.
Спасибо за комментарий! Возможно, тут возникло недопонимание - в классе может быть несколько методов, просто публичный - только один - и это метод call.
Вы можете сделать хоть тысячу маленьких функций, а можете собрать все воедино и результат у вас будет один и тот же и изменится не может, потому что функция на самом деле одна а так как все остальные функции приватные то для пользователя Вашего класса их нет и быть не может.
Объект - это история про некое состояние, про применение методов к этому состоянию для его изменения или создания новых. У Вас, класс(объект) - это просто банка с одной функцией. Если Вы вытащите функцию из банки - ничего не поменяется но станет чуть чуть проще так как останеться разделение на простые функции и простые данные. Подход - в функцию передается и возвращается DTO сильно проще чем Ваш, не нужно объяснять кому-то что это вроде бы сервис но на самом деле команда с состоянием, а еще там может быть только одна функция и она должна быть такой то, не нужно объяснять не нужно следить за таким стилем чтобы никто не начал еще функции публичные писать, не нужно никого учить и объяснять почему класс должен имитировать функцию. Будьте проще - просто используйте функции и не нужно будет ничего объяснять и проверять.
Единая ответственность. Каждый сервис реализует законченный кусок бизнес-логики — от простого создания объекта до комплексных операций с вызовами других сервисов или внешних API.
Единственный публичный метод. Вся работа с сервисом ведётся через метод call. Избавляемся от проблемы когда разработчики начинают придумывать run-ы, execute-ы, process-ы и т.д.
Вы определенно двигаетесь в правильном направлении. Позвольте, сэкономлю Вам немного времени. У Вас не сервис а команда и она Вам не нужна. Если Вам нужен класс с одной функцией - это значит что класс здесь в принципе не нужен. Выкиньте ненужное, оставьте старую добрую функцию и все еще упроститься.
Наверное, вы уже слышали о runtime async, даже есть отличная статья на Хабре. Если коротко, это позволит создавать легковесные асинхронные задачи, как горутины в Go, управление которыми ляжет на рантайм, без нагрузки на потоки ОС.
Боюсь Вы не до конца поняли как статью так и механику.
В указанной Вами статье:
Для реализации Async2 были рассмотрены два подхода: размотка стека (tasklets, stack unwindind) и JIT-сгенерированные машины состояний (continuations, JIT State Machine). Подход на основе JIT оказался предпочтительным благодаря лучшей совместимости с текущей инфраструктурой .NET, меньшим накладным расходам и более высокой производительности в большинстве сценариев. Размотка стека, хотя и поддерживает сложные конструкции, такие как byref и span, оказалась менее практичной из-за увеличения времени пауз сборки мусора и сложности реализации.
указано что как раз был выбран путь не как в Go. Если сильно упростить - останеться та жа стейт-машина но создаваться и поддерживаться она будет на уровне рантайма.
Без преувеличения, самая ожидаемая фича, которая позволит C# выбить главный козырь из рукава Go.
Ничего никто выбивать не пытаеться, у .Net итак все очень хорошо и никаких козырей у Go нет. В .Net, JVM и Go у каждого свой подход к решению проблемы, со своими плюсами и минусами.
К примеру для виртуальных потоков Java главная задача была - это безболезненно мигрировать огромное количество проектов. Для Go - создать шайтан машину которое позволит разработчикам вообще не грузить голову по поводу управления задачами в среднем по больнице. Для C# - это - наглядность и управляемость.
Прошу прощения, а нестандартные задачи это проходы по деревьям, задачи на бин поиск, интервалы там и прочие стандартные алгоритмические задачи, решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения?
Если нет, зачем вообще проводить собеседование, можно же просто отбирать призеров олимпиад и турниров, не тратя время на собесы?
А можно поинтересоватся, какая связь между IQ, решением алгоритмических задач на собеседованиях и решением задач реальных, и как это должно выявлять сильных кандидатов?
Если ужать все в одно предложение - мы создали копию Idea чтобы занять место JetBrains.
Единственный плюс - не зависеть от прихоти негодяев из JB. Это да. В остальном.
OpenIDE, напротив, полностью локален. Мы не передаём исходный код за границу и не отправляем телеметрию в сторонние облачные сервисы. Для компаний, особенно крупных, это вопрос доверия и информационной безопасности.
Где гарантии что завтра вы сами не станете это делать как только наберете достаточную базу пользователей?
OpenIDE Pro будет коммерческим продуктом. Это ответ на запросы рынка, которых получили немало, и закономерное решение: корпоративная поддержка требует реальных ресурсов — инженеров, времени на тестирование, инфраструктуры и процессов по SLA.
Предположу что вы изначально делали проект не из альтруизма но оно и понятно.
Проблема в другом. Что нового вы привнесете с этим продуктом помимо независимости от редисок из JB?
Да это не на Ваш комментарий ответ а на то что выше, а ответил Вам скорей в контексте эликсира. Специально написал "Это я в контексте прошлого комментария." Признаю, сформулировать получилось неудачно.
Я не поклоняюсь Rust, для меня это не более чем отвертка для решения ряда задач, как и любой другой ЯП.
Я не понимаю претензий вида Rust не совершенен - я в нем разочаровался, и это еще на фоне таких "совершенных" языков как C++. Есть один инструмент который одной делает хорошо а другое - плохо и другой который имеет обратные характеристики. Мы все ждем идеальный инструментов, но что-то пока не завезли. Когда завезут то что во всем будет лучше и решать большинство проблем, мне вот честно нафиг тогда не нужно будет копятся во временах жизни. Но это когда-то и возможно. А пока что есть то есть.
Я (внимание! лично я! это частное мнение! не претендующее на объективность!) не вижу архитектурных проблем в эликсире.
Во первых, вопрос не про архитектурные проблемы(что бы это не значило) а скорее глобальные, а они есть у всех. В данном контексте - проблема управления памятью, которая не решена нигде.
Мы имеем либо: - просто и безопасно но не быстро(GC языки) - просто и быстро но не безопасно(C/C++, все остальные виды C с бантиками) - быстро и безопасно но не просто(Rust)
Я не знаю сейчас более менее живых языков, которые решают одновременно три эти проблемы. В этом контексте я не понимаю претензии к Rust. Разработчики сделали ставку на скорость и безопасность решая конкретную проблему - сделать быстрый язык без отстрела себе ног, это имело свои последствия в виде сложности. За все нужно платить. Можно было лучше? Наверное. Но где те идеальные инструменты где все и быстро и надежно и просто? Очевидно нигде. Когда появиться такое то уже будет интересно сравнить или действительно прийти к выводу что Rust не торт. А сравнивать с самострелами в контексте простоты наглухо закрывая глаза на отстреленные конечности такое себе.
Это я в контексте прошлого комментария.
По поводу Эликсира, в данном контексте его проблемой была бы производительность.
Я бросил раньше, видя глобальные проблемы. Правда я начал уже "зная брод".
Можете поделиться, в какой альтернативе нет глобальных проблем?
- я ранее наткнулся и переводил статью Александреску касательно Раста
Почитал. Целых две и обе невероятно объективные.
Первая - почему Rust, разработчики которого поставили цель сделать язык безопасным управлением памятью и высокой производительностью, вместо этого не сделали еще один Си с бантиком.
Вторая - "Чуждый синтаксис. Это раздражает людей, пришедших из языков семейства Algol’а". Ну это по мне стыд и позор такие претензии предъявлять, что-то на уровне, язык плохой потому что у него маскот - краб.
Тестировать приватные функции, сиречь — дентали реализации, — самый страшный грех разработчика (после плохих имен и некорректной инвалидации кэша).
Вынужден с Вам не сгогласится. Звучит красиво и я сам раньше в это верил, но реальность такова что часто мы встречаем код вполне понятный, вполне компактный но чертовский неудобный и сложный для тестирования, и вот на него нужно написать тесты. И тогда перед нами ставят четыре стула:
декомпозировать сложную логику на несколько более простых публичных частей. Грех, потому как мы начинает подстраивать код под тестирование а не под задачи, возможно эти публичные функции никому не нужны или даже недопустимы для публичного пространства, плюс код сразу усложняется, превращаясь из местечкового в раздробленный.
не заморачиваться с инкапсуляцией и сделать все функции публичными. Думаю комментировать не нужно.
писать супер сложные и адски неудобные тесты с проверкой все возможных комбинаций всех инвариантов этой слогики. Но для этого лучше уже подойдут интеграционные или более реалистичные тесты.
писать на тесты на части приватной логики. Да местами прибиваем гвоздями детали реализации, с другой стороны, unit тесты это и есть история про прибивание гвоздями реализации в том или ином виде. Зато можно написать компактный хороший и простой код с закрытой реализацией и удобным тестированием.
Лично пришел к выводу что последнее меньшее из зол. Судя по тому что во многих языках есть такая возможность, не я один.
Потому что все это субъективщина.
Вопрос в том кому нужен? Работодателям очевидно не нужен так как никто в этом направлении как не чесался так и не чешется особо.
Ну окей, нужен инструмент, как будем строить систему грейдов? По "стандартной лестнице: Junior, Middle, Senior" ? Ну ок, джун - тот кто еще не самостоятельный а мид тот кто уже самостоятельный а сеньор это вообще кто? Абстрактный опытный разработчик? Ну ок. А мид который еще не сеньор но уже не простой рядовой разработчик это кто? Сеньор с 5 годами опыта и с 10 годами это одни и тот же грейд или нужно делить еще на 3-5 подгрейдов? Итого получим 6-10 грейдов. Дальше выясняется что обычно с уровня условного сеньора идет специализация, когда одни хорошо разбирается в БД, другой в DevOps, третий в многопоточности, четвертый проектирует неплохо а пятый просто решала. Как эти критерии рассчитывать, делать сетку навыков под каждую возможную специализацию? А как оценивать пересечение специализаций когда человек несколько специальностей знает? А как оценить специалиста с хорошей базой и гибким мышлением, который по новой технологии доки за вечер прочитает и на коленке сделает? Ну и наконец, будут ли оцениваться навыки вызывающие споры? Ну например, у кого-то есть навыки в продвинутом ООП, DDD SOLID, чистых архитектурах и прочем а кто-то считает это бесполезным и даже вредным. Есть еще функциональное программирования. Как такое оценивать, чтобы привести всех к общему знаменателю? Кто-то гордится что он чистый код пишет а кто-то пишет эффективный. Как быть?
Грейд - это ваша способность зарабатывать деньги.
Можно долго пытаться убеждать себя что в грейдах есть какой то смысл, корреляция с опытом, управлением какой-то сложностью и прочее. Но на деле грейд - это не более чем навык подстраиваться под хотелки конкретной компании, такие как: умение хорошо собеседоваться, умение дружить с руководством и иметь своих людей на правильных позициях, умение подстраиваться под внутренние требования, какими бы абсурдными они не были, для того чтобы получать больше денег.
Да хотелось бы чтобы корреляция с опытом была но нет в современных компаниях этого нет уже давно.
Надеюсь в резюме у себя Вы такое не указываете
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось.
Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
У Вас такое развлечение, носиться из статьи в статью с одними и теми же заезженными до дыр тезисами, о том что если язык не гарантирует вам абсолютную безопасность во всем то он ничем не лучше языка который при любом неловком движении отстреливает вам конечности?
Проблема такого подхода в том что если в Rust все это появится то Вы начнете жаловаться на то что на льду поскользнулись при этом пишете на Rust а он плохой такой вроде бы вам безопасность гарантировал.
Чисто для интереса. Вот Вы так сокрушаетесь что людей не переубедить. А Вам никогда не приходила мысль, хотя бы на долю секунды, что чисто гипотетически Вы можете быть не правы?
А если ли у этих принципов явные и понятные всем а главное однозначные формулировки? Ну например что такое ответственность а как ее рассчитать для конкретного случая? Есть ли доказательства эффективности применимости данных принципов отличные от субъективного восприятия? Или основной показатель эффективности - это "я считаю оно работает у меня а значит работает у всех"?
Не скажу за дрель, но в схожих условиях в оружии, спусковой крючок часто используют и для стрельбы и для переключения ведения режимов огня и как предохранитель и ничего.
Советую изучать лучше данный принцип. Там нет ничего про классы.
И очень хорошо, что инженеры когда проектируют различные решения, не забивают себе голову такими глупостями и догмами а проектируют реализацию исходя из требований и собственной смекалки.
Яркий пример из Второй мировой - зенитная артиллерия. Эта та которая по самолетам стреляет. Вместо того чтобы всякие единственные ответственности соблюдать, инженеры сделали орудие которое может стрелять и по земле а более того были сделаны противотанковые снаряды. И более того, впоследствии оказалось что зенитное орудие едва ли не лучшее противотанковое средство. После чего в Германии и СССР стали ставить слегка модифицированные зенитные орудия на танки. А вот если бы знали про SOLID не страдали бы видиом фигней и делали зенитные орудия которые могут стрелять только по самолетам.
Гораздо проще читать код, когда в нем нет ничего лишнего, например класса, который используется не по прямому назначению а только для того чтобы в него что-то завернуть.
Лучше, вместо того чтобы читать старые книги сомнительного содержания, почитать свежий блог автора этой книги. Откроете для себя много нового, например что у него сейчас любимый язык на котором он пишет это Clojure, и что он за минималистичность простоту и про прочее за все хорошего против всего плохого.
У Вас одна публичная функция а значит для любого пользователя класса - у Вас только одна функция. То что Вы написали внутри 10-20 приватных для своего удобства это никак не меняет семантики - можете все скомпоновать в одну или разбирать на 1000, для пользователя класса ничего не измениться. Более того, если Вы перепишите класс на обычную функцию которая будет вызывать вспомогательные функции, по большей части ничего не измениться, потому что никакие особые свойства объектов не используете.
Вы можете сделать хоть тысячу маленьких функций, а можете собрать все воедино и результат у вас будет один и тот же и изменится не может, потому что функция на самом деле одна а так как все остальные функции приватные то для пользователя Вашего класса их нет и быть не может.
Объект - это история про некое состояние, про применение методов к этому состоянию для его изменения или создания новых. У Вас, класс(объект) - это просто банка с одной функцией. Если Вы вытащите функцию из банки - ничего не поменяется но станет чуть чуть проще так как останеться разделение на простые функции и простые данные. Подход - в функцию передается и возвращается DTO сильно проще чем Ваш, не нужно объяснять кому-то что это вроде бы сервис но на самом деле команда с состоянием, а еще там может быть только одна функция и она должна быть такой то, не нужно объяснять не нужно следить за таким стилем чтобы никто не начал еще функции публичные писать, не нужно никого учить и объяснять почему класс должен имитировать функцию. Будьте проще - просто используйте функции и не нужно будет ничего объяснять и проверять.
Вы определенно двигаетесь в правильном направлении. Позвольте, сэкономлю Вам немного времени.
У Вас не сервис а команда и она Вам не нужна. Если Вам нужен класс с одной функцией
- это значит что класс здесь в принципе не нужен. Выкиньте ненужное, оставьте старую добрую функцию и все еще упроститься.
Боюсь Вы не до конца поняли как статью так и механику.
В указанной Вами статье:
указано что как раз был выбран путь не как в Go. Если сильно упростить - останеться та жа стейт-машина но создаваться и поддерживаться она будет на уровне рантайма.
Ничего никто выбивать не пытаеться, у .Net итак все очень хорошо и никаких козырей у Go нет. В .Net, JVM и Go у каждого свой подход к решению проблемы, со своими плюсами и минусами.
К примеру для виртуальных потоков Java главная задача была - это безболезненно мигрировать огромное количество проектов. Для Go - создать шайтан машину которое позволит разработчикам вообще не грузить голову по поводу управления задачами в среднем по больнице. Для C# - это - наглядность и управляемость.
Остается надеяться что самая темная ночь перед рассветом
Прошу прощения, а нестандартные задачи это проходы по деревьям, задачи на бин поиск, интервалы там и прочие стандартные алгоритмические задачи, решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения?
Если нет, зачем вообще проводить собеседование, можно же просто отбирать призеров олимпиад и турниров, не тратя время на собесы?
А можно поинтересоватся, какая связь между IQ, решением алгоритмических задач на собеседованиях и решением задач реальных, и как это должно выявлять сильных кандидатов?
Если ужать все в одно предложение - мы создали копию Idea чтобы занять место JetBrains.
Единственный плюс - не зависеть от прихоти негодяев из JB. Это да. В остальном.
Где гарантии что завтра вы сами не станете это делать как только наберете достаточную базу пользователей?
Предположу что вы изначально делали проект не из альтруизма но оно и понятно.
Проблема в другом. Что нового вы привнесете с этим продуктом помимо независимости от редисок из JB?
Да это не на Ваш комментарий ответ а на то что выше, а ответил Вам скорей в контексте эликсира. Специально написал "Это я в контексте прошлого комментария." Признаю, сформулировать получилось неудачно.
Я не поклоняюсь Rust, для меня это не более чем отвертка для решения ряда задач, как и любой другой ЯП.
Я не понимаю претензий вида Rust не совершенен - я в нем разочаровался, и это еще на фоне таких "совершенных" языков как C++.
Есть один инструмент который одной делает хорошо а другое - плохо и другой который имеет обратные характеристики. Мы все ждем идеальный инструментов, но что-то пока не завезли. Когда завезут то что во всем будет лучше и решать большинство проблем, мне вот честно нафиг тогда не нужно будет копятся во временах жизни. Но это когда-то и возможно. А пока что есть то есть.
Во первых, вопрос не про архитектурные проблемы(что бы это не значило) а скорее глобальные, а они есть у всех. В данном контексте - проблема управления памятью, которая не решена нигде.
Мы имеем либо:
- просто и безопасно но не быстро(GC языки)
- просто и быстро но не безопасно(C/C++, все остальные виды C с бантиками)
- быстро и безопасно но не просто(Rust)
Я не знаю сейчас более менее живых языков, которые решают одновременно три эти проблемы. В этом контексте я не понимаю претензии к Rust. Разработчики сделали ставку на скорость и безопасность решая конкретную проблему - сделать быстрый язык без отстрела себе ног, это имело свои последствия в виде сложности. За все нужно платить. Можно было лучше? Наверное. Но где те идеальные инструменты где все и быстро и надежно и просто? Очевидно нигде. Когда появиться такое то уже будет интересно сравнить или действительно прийти к выводу что Rust не торт. А сравнивать с самострелами в контексте простоты наглухо закрывая глаза на отстреленные конечности такое себе.
Это я в контексте прошлого комментария.
По поводу Эликсира, в данном контексте его проблемой была бы производительность.
Можете поделиться, в какой альтернативе нет глобальных проблем?
Почитал. Целых две и обе невероятно объективные.
Первая - почему Rust, разработчики которого поставили цель сделать язык безопасным управлением памятью и высокой производительностью, вместо этого не сделали еще один Си с бантиком.
Вторая - "Чуждый синтаксис. Это раздражает людей, пришедших из языков семейства Algol’а". Ну это по мне стыд и позор такие претензии предъявлять, что-то на уровне, язык плохой потому что у него маскот - краб.
Вынужден с Вам не сгогласится. Звучит красиво и я сам раньше в это верил, но реальность такова что часто мы встречаем код вполне понятный, вполне компактный но чертовский неудобный и сложный для тестирования, и вот на него нужно написать тесты. И тогда перед нами ставят четыре стула:
декомпозировать сложную логику на несколько более простых публичных частей. Грех, потому как мы начинает подстраивать код под тестирование а не под задачи, возможно эти публичные функции никому не нужны или даже недопустимы для публичного пространства, плюс код сразу усложняется, превращаясь из местечкового в раздробленный.
не заморачиваться с инкапсуляцией и сделать все функции публичными. Думаю комментировать не нужно.
писать супер сложные и адски неудобные тесты с проверкой все возможных комбинаций всех инвариантов этой слогики. Но для этого лучше уже подойдут интеграционные или более реалистичные тесты.
писать на тесты на части приватной логики. Да местами прибиваем гвоздями детали реализации, с другой стороны, unit тесты это и есть история про прибивание гвоздями реализации в том или ином виде. Зато можно написать компактный хороший и простой код с закрытой реализацией и удобным тестированием.
Лично пришел к выводу что последнее меньшее из зол. Судя по тому что во многих языках есть такая возможность, не я один.